Live data from Hacker News

Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

llmgame.scalex.dev

121–130 of 200 posts

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#121
post #84

Earlier quoted context omitted.

I put mine in various aes encrypted file (like `~/.secrets.aes`) and then source it explicitly when needed with: . I have a handful of aliases/functions to make it more smooth, but that's the core.

Where are those aliases stored?

The AES encrypted file has some, plus a bunch of exported env vars. I do keep one function in my ~/.bashrc to make it simpler to invoke so I can do `source-secret ~/.secrets.aes`:

    source-secret()                                                                                                                                               
    {                                                                                                                                                             
      if [ -z "$1" ]; then                                                                                                                                        
        echo "Need filename to source"                                                                                                                            
      elif ! [ -f "$1" ]; then                                                                                                                                    
        echo "File '$1' does not exist"                                                                                                                           
      elif ! which aescrypt >/dev/null 2>&1; then                                                                                                                 
        echo "Could not find required dependency 'aescrypt'"                                                                                                      
      else                                                                                                                                                        
          . 

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#122
post #112

Earlier quoted context omitted.

Actually, the only secure default is to deny everything...how do you know that innocent command is actually innocent?

A strange game. The only winning move is not to play.

It’s the security mantra: the safest code is the one you never release. Code that never runs is the most secure code

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#123
post #52

Fun game, but it showed the lack of security hygiene employed by the game writer. It said `cat ~/.zshrc` was bad because it would share tokens and secrets, but I would never put secrets into my shell rc.

Where would you put them?

Another more secure pattern: have different shell profiles that just go dynamically inject secrets from a secrets manager. Nix is a good tool for this. You have various shell profiles configurations that call your password manager cli at bootstrap (eg new terminal tab). You auth and at bootstrap of the terminal time the secret is dynamically fetched from the password manager and injected into an env var. this has advantage over other approaches mentioned here in that the secret is never stored at rest on the end user’s machine only used in flight

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#125
post #60

Earlier quoted context omitted.

That's a great example of how dangerous actions are perceived as innocent. The entire model of approving specific commands is absolutely bonkers. npm run build = run an arbitrary shell command written in package.json Meanwhile the agent could have done any of the following without approval: - edited `package.json` to contain any arbitrary build command - planted malicious code in `build.js` (called by `npm run build`…

What would a better system look like?

Don’t rely on your non deterministic agent and its creators to secure your software. Design defense in depth and trust guardrails that don’t expect Anthropic to vibe good security into existence.

If you start by treating any autonomous actor in your system as an actor with the potential to go rogue the design starts to create itself

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#126
post #112

Earlier quoted context omitted.

A strange game. The only winning move is not to play.

It’s the security mantra: the safest code is the one you never release. Code that never runs is the most secure code

A computer is only secure if it remains powered off and airgapped.

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#127
Yeah, echoing the comments here. It's a good idea - kind of - but it is all about digging deeper when it is sus.

The tool assumes so much. That it is fine to kill a process itself versus just asking you to kill the process. That everyone MUST have passwords in their home directory. It's all meaningless without providing the thing it is running and so no activity is technically safe.

Why do people even get the agent to run the commands it asks to run? You can solve the entire threat vector by running it yourself and giving the agent the output. Claude practically only needs things like sed, awk, and grep. It's a pattern matcher. It's a waste of yours (and its) time to have it run your project.

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#129

Earlier quoted context omitted.

It’s the security mantra: the safest code is the one you never release. Code that never runs is the most secure code

A computer is only secure if it remains powered off and airgapped.

Turn off your computer and make sure it powers down

Drop it in a 43-foot hole in the ground

Bury it completely, rocks and boulders should be fine

Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue

#130
Love it. One nitpick.

>npm config set registry https://npm.internal

>Pointing npm to the company's internal registry mirror as required by onboarding docs

It claimed this is safe and I was 50/50 on it but eventually rejected it.

If this README is for a public / forked repo, and that https://npm.internal is actually https://npm.internal.somethinganexternaldnscanresolve.tld

This can go bad really quickly...

In 99% of cases you would have Artifactory / Nexus (or other mirror) already set by company policy. Having a README tell you to use a different package manager url is a big red flag and seconds away from disaster...

Post reply on HN