AI Agents Are Outrunning Their Permission Guardrails
Visibility into AI agents is achievable. Enforcing what those agents can actually do — and can't — is proving harder, and this week's incidents are showing the gap.
Dave "Kilobaud" Ferris The gap between “we can see the agent” and “we can control what it does” is turning out to be a wide one.
This week gave us two clean examples. A threat actor configured the open-source Hermes AI agent in “YOLO” mode — the setting that disables approval prompts for risky commands — and pointed it at Thailand’s Finance Ministry network. The agent enumerated hosts, hunted privilege escalation paths, and traversed file systems without further human direction. It wasn’t a novel technique. It was a known post-exploitation playbook run unattended at a pace no human operator could sustain.
The same day, Zenity Labs published AgentForger, a now-patched vulnerability in ChatGPT Workspace Agents that would have let a single phishing link build, authorize, and deploy an autonomous agent inside a victim’s organization. OpenAI fixed it in June. The disclosure arrived this week, which means the exposure existed in production environments operating on the assumption that phishing leads to a compromised human account — not an autonomous agent running inside the tenant.
Both stories share the same underlying logic: AI agents exist to take action. “YOLO mode” is a configuration that removes the last human checkpoint before they do. The AgentForger flaw was unauthorized access to that same action-taking capability. The permission surface is wide because it has to be — an agent that can’t do anything isn’t useful. The question is who sets the boundaries and whether anyone has actually defined them.
Security teams have gotten reasonably good at the visibility part. Logs, audit trails, agent process enumeration — the observability tooling has moved fast. The maturity curve runs from visibility to control, and what organizations are finding in practice is that “least privilege for AI agents” is a harder problem than it sounds.
An agent that needs to read email, query APIs, write files, spawn subagents, and make decisions across those channels has a wide action space by design. Constraining it to the minimum necessary subset requires knowing what the agent will actually do before it does it — which is non-trivial when the agent is reasoning through tasks dynamically rather than executing a fixed script. You’re not scoping permissions for a process you fully understand. You’re scoping them for something you’re trusting to figure things out.
The older analogy is service accounts. The guidance has been consistent for decades: give service accounts only the permissions they need. In practice, service accounts accumulated excess permissions because debugging a failed automation under time pressure is easier than figuring out which privilege it actually needed. The blast radius is only visible after the fact. AI agents are inheriting the same organizational pattern, with a larger action space and a shorter window between deployment and potential abuse.
The controls exist. Scope-limited OAuth tokens. Tool inventories with explicit allowlists. Human-in-the-loop checkpoints for high-risk actions — the kind “YOLO mode” turns off. Sandboxed execution environments. What doesn’t exist at scale yet is the operational practice of applying them before an agent goes to production, rather than after something goes wrong.
AWS Kiro’s MCP configuration rewrites and the Claude Cowork VM escape from earlier this week are the same pattern from a different angle: the isolation and permission boundaries that security teams assumed were present turned out to be more porous than the product documentation implied. These aren’t unique failures — they’re what happens when the deployment outpaces the governance.
The week’s AI security incidents aren’t a coincidence. AI agents are proliferating faster than the identity and access management infrastructure that’s supposed to govern them. Visibility came first. Control is the harder part, and it hasn’t caught up.
Patch Tuesday will still be Patch Tuesday next month. The AI agent governance gap will still be there if it isn’t addressed now — and by then the agents will have been in production longer, with more accumulated access, and fewer people who remember why they were granted it.
Found this useful? Share it.
