Agent Failure of the Week #4: The Agent With Root
Over-permissioned agents turn a small bug into a company-wide incident
July 17, 2026 · 3 min read
The failure
To get the agent shipped before a deadline, someone gives it an admin credential, the same login the ops lead uses. It works immediately, which is exactly why nobody revisits it. A month later, a malformed instruction sends the agent down a path its author never anticipated, and because the credential can touch every object in the CRM, the agent rewrites a field across the entire customer base in seconds. The blast radius isn't one record. It's everything the credential could reach, which was everything.
Why is an over-permissioned agent more dangerous than an over-permissioned human?
A human with broad access is bounded by human behavior. They read one record at a time, they apply judgment, they have something to lose, and they're slow. Broad permissions on a person are a manageable risk.
An over-permissioned agent has none of those brakes. It acts at machine speed, without hesitation, and it will faithfully execute a flawed instruction across everything in scope before anyone can refresh a dashboard. The same access that's a manageable risk on a human is a loaded weapon on an agent, and "give it admin so it just works" quietly hands it that weapon on day one.
The test (how we score it)
Is agent access governed by role-based permissions, separate from human permissions?
- Green: Agent-specific permissions, scoped to least privilege. Each agent can touch only what its job requires.
- Yellow: Named service accounts with some limits, but not true least-privilege.
- Red: Admin credentials or shared logins. The agent can reach everything.
How do you scope permissions for AI agents?
- Give agents their own roles. Distinct from human roles, designed for what the agent does, not inherited from whoever set it up.
- Scope to least privilege. Each agent gets access to the specific objects and fields its task needs, and nothing more.
- Separate read from write. Most agents need far less write access than they're given. Grant it narrowly.
- Review the blast radius before you ship. Ask: if this agent did the worst possible thing with its current access, what's the damage? Shrink it until the answer is survivable.
The bigger point
This isn't an AI problem. It's access control and least privilege, security fundamentals, applied to an actor that exploits over-permissioning faster and more thoroughly than any human ever could. An agent with keys to the whole CRM is a bigger attack surface than any employee, and a bigger regulatory exposure too. Least privilege is the wall between a small bug and a company-wide data incident.
We test exactly this on the Agentic Workflow Readiness pillar of our AI Readiness Benchmark.
See where your stack stands → revenuegroundwork.com/benchmark Or book a free consultation → revenuegroundwork.com/contact
Next week, the finale, #5: an agent makes a bad bulk change, and there's no undo.