Why agent RBAC is broken in most CLI frameworks (and how to fix it)
Last Tuesday, a “helpful” coding agent in a staging environment did exactly what it was told: clean up old resources. It also had the same CLI credentials as the human who launched it. So instead o...
Source: DEV Community
Last Tuesday, a “helpful” coding agent in a staging environment did exactly what it was told: clean up old resources. It also had the same CLI credentials as the human who launched it. So instead of deleting a temp bucket, it rotated secrets, modified deployment config, and opened a PR that looked totally legitimate. Nothing “hacked” us. The agent was authenticated. The problem was simpler: we knew who started the agent, but not who the agent was. That’s the gap a lot of CLI frameworks still have. They treat agents like scripts with a borrowed token. That works until you need to answer: Which agent called this command? What was it allowed to do? Was it acting on behalf of a human? Can I revoke just that agent without breaking everything else? Do I have an audit trail that survives token sharing? If you’re building agent workflows in a CLI, RBAC only works if agents have their own identity. The usual anti-pattern A lot of setups look like this: export AWS_PROFILE=admin claude-code run "
