Nice game to aware the security.
Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
191–200 of 200 posts
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#192[flagged]
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#193--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.
It's true.
I think most people would be horrified about how I run. I just have a hook that blocks obviously unsafe commands (removals, reading secrets, etc) but other than that, the agent is free to do whatever it wants on my machine.
I used to run in a sandbox but for me personally I see these agents as fairly well aligned / intelligent and I am the one prompting them so the risk of injection is none. The hooks are just there to prevent them from getting too ambitious or crafty.
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#194I'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…
> we are looking for is a portal or protocol that has the model and harness and the actions tunneled, like ssh, to some fixed scoped and limited shell along side the assets then, the user and LLM can the negotiate assets and actions as needed via the protocol.
Take a look at a project I just finished this weekend: https://clawband.io
It's an agent permissioning platform that isolates your service connections and puts a granular permissioning layer on it. So rather than your agent getting full access to a service, they get a Clawband key that can be used to request actions then Clawband checks the parameters to see if it is allowed.
The classical example I have made is allowing your agent access to privacy.com. You may want it to be able to list your cards but not create one or you may want to allow creating cards but only a certain limit.
The plan is to make it open-source and allow self-hosting because security / sanity of users but still have a SaaS offering as a demo / ease of use.
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#195[flagged]
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#196Congrats on the launch! Product looks solid. Since you're in the launch phase, are you doing any PR or podcast outreach to get initial traction? We built an AI tool that completely automates this, might be useful for your current stage. Best of luck!
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#197[dead]
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#198[flagged]
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#199Hahah that was awesome, gave me flashbacks of my 9-5
Re: Show HN: Continue? Y/N: A 60-second game about AI agent permission fatigue
#200That's funny. It told me that blocking "npm run build" was the wrong answer. Maybe it doesn't really under The threat model.
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`…
The security layer needs to parse the full agent activity with the context. It watches everything, but only interrupts the human when it matters.
Commands that can run arbitrary code need to be treated differently and can't get escalated in this opaque way.
A large part of the solution should be to drastically reduce the amount of permission approval prompts a user gets. This ensures the ones he does get are evaluated with the same concentration a manager gives a new hire's most consequential decisions.
Most importantly, because we ask him rarely, when we do he feels the accountability. The yes is his.