Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

llmgame.scalex.dev

Post reply on HN
Print view View original

111–120 of 200 posts

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

#111

Post by ericlevine »

This really hits the nail on the head. The current permissions models are totally broken IMO. You're either approving everything, restricting access and neutering your agent, or full YOLOing and, well, good luck. The right primitives are not in place yet, and there's no clearly correct answers.

I think the right primitive is "task-based authorization", where you review a high-level task and let an LLM judge decide whether the subsequent tool calls fall into the scope of that task. It's not perfect, but it distills dozens of approvals down to one and gives you risk-based signals of whether you should pay close attention or not.

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

#112

Post by ssl-3 »

smaudet wrote: post #109
Wirbelwind wrote: post #80

Earlier quoted context omitted.

Good catch, this has now been nerfed and this approach has gotten its own title

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.

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

#113

Post by atemerev »

kennywinker wrote: post #42
atemerev wrote: post #25

--dangerously-skip-permissions is the only way to fly. Of course your environment needs to be properly containerized and autobackup set up, so even rm -rf from your harness would do nothing. Life is too short to spend on replying to permissions requests.

Lol. Countdown til you get pwned starts today. Let me know how that works out for you in six months.

Well working like that for about a year already, starting at the earliest days of agents.

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

#114

Post by atemerev »

prerok wrote: post #43
atemerev wrote: post #25

--dangerously-skip-permissions is the only way to fly. Of course your environment needs to be properly containerized and autobackup set up, so even rm -rf from your harness would do nothing. Life is too short to spend on replying to permissions requests.

I've seen these suggestions but I am really curious about the set up because I just don't get it. If you want to work on the code then you need to have access to the repositories, so you need the github token. Then, to test the app, you may need your own backend token. And VPN. Of course, only to DEV, of course all tokens encrypted. So, only DEV and your branch of the code is in danger. In my view, even that is prett…

Git makes actions reversible. Containers and VMs allow the agent to access only the things you explicitly put inside. Okay, yes, an agent can corrupt a dev database. You need to make sure it can be easily restored anytime. Simple.

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

#115

Post by kennywinker »

atemerev wrote: post #113
kennywinker wrote: post #42

Earlier quoted context omitted.

Lol. Countdown til you get pwned starts today. Let me know how that works out for you in six months.

Well working like that for about a year already, starting at the earliest days of agents.

Wow a whole year! I guess it’ll never happen.

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

#118

Post by isityettime »

nish__ wrote: post #52
spurgelaurels wrote: post #49

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?

Anywhere else? Password managers have CLIs, operating systems have their own secure storage, and lots of command line apps can store secrets in the OS's secure storage (Windows Credential Store, Secrets Service or KWallet on Linux, macOS Keyring).

Project-specific secrets can be stored locally via something like SOPS or remotely with something like Hashicorp Vault or AWS SecretsManager.

Applications that have secrets to manage (e.g., Emacs) or are partly about secrets management (e.g., GnuPG, OpenSSH) all store their secrets somewhere else and have secure (not plaintext, sometimes not even on disk) storage options available.

There's no reason to store secrets in plain text in your shell configuration. Practically any choice you can think of is a better one. Even if you did, there's no reason you couldn't store them in a more specific file that ~/.zshrc sources, and let LLM agents read zshrc but block access to the file containing your secrets. (I wouldn't rely on permissions prompts for this, though, lol.)

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

#119

Post by trehalose »

I wish it the scoring readout at the end would display the LLM's descriptions of the commands I shouldn't have approved. I approved the rm -rf Projects command because I thought the LLM had correctly described that it would delete everything in the Projects folder. Clearly I misread that in my hurry to answer prompts (I knew what the command would do and I guess I hallucinated that the AI had explained it), but I'd like to see what it was that I misread.

Playing this game made me very glad I don't agentmaxx.

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

#120

Post by madrox »

cyanydeez wrote: post #110
madrox wrote: post #108

I've long held the current agent permission model is like playing a game of "Papers, Please" and most permission models engineers implement in their own AI products is more a measure of how trusting the user is with AI than an actual permission check. I'm of the view that future controls should be more about approving plans and rewinding durable workflows as models get better at avoiding egregious mistakes.

the models will never avoid egregious behavior. think of it like every "good intentions" morality tale. theres almost always some geniune context where that behavior is wanted. instead, the coding harness or determinative tool, will need hardcoded security features. in opencode, almost all the power comes from bash and all other permissions are just chrades. its powerful and insecure because of it. you can sand box t…

I think you're choosing to ignore what I said about the implication of durable workflows, because you seem to be inventing some stories about my comment.

I find that well documented plans do pretty well at aligning AI to what I want it to do, and if it does go astray, as you rightly point out it can still do, it would be sufficient if I can undo it with little pain. We do this kind of thing all the time in CI/CD pipelines.

Even humans can take down production. We have all kinds of guards in place to empower while also defending against the intern accidentally dropping the DB.

Post reply on HN