points by anuptalwalkar 2 days ago | 0 comments
The dogfooding example I read was basically agent asking for user to sign off on permissions, Nd taking over from that point on. It doesn’t exactly read any different than any other ‘AI went rogue stories.
I am saying it’s a slippery slope and OIDC was not necessarily designed for it.
So sure - it wasn't designed with agents directly in mind, but it's supported workload identity federation for a while (and is used in this manner for lots of big players - github, GCP, AWS, Azure, etc...)
This just seems to extend that concept slightly to allowing the workload identity to be generated on the fly based on user/agent combinations, with a HITL addition to approve the identity being generated and grant it a subset of permissions.
---
What you're saying here is different than what you implied in the first comment.
There is a real and meaningful difference between
1. A user can blame a rogue agent for actions they [the user] performed
2. An agent itself went rogue
So sure - #2 is still a risk, and one they'd have to mitigate with the security controls they talked about (minimal access, temporary grants, HITL, etc). Frankly - #2 is always a risk. That's what "agents" are (both the bot and the fleshy kind). It's also why we have logging and visibility tools that should be recording what was done, by whom, and for what reason, along with robust backups. You can't really close this hole, you accept it, monitor it, and hold the agent to account (and again - I'm with you on discussing culpability for bots and what that means in the legal sense. Ex - do we charge the person who introduced the bot, the company running it, the party that injected bad context, etc...?)
But #1 is not a thing a person can do - they can't take malicious actions and then blame a rogue agent.