No exploit. No breach. The agent simply used what it found.
Offensive security agents were the catalyst for this framework. They are the clearest case: a system explicitly built to find and exploit weaknesses, operating at machine speed, with a mandate that rewards reaching further. But the problem is not confined to offensive tooling, and a framework that addresses only red team agents will leave the larger exposure untouched.
A development agent, permitted to run a test suite
- The agent is granted permission to run the test suite. Nothing more.
- A test fails. The agent begins debugging, which is exactly what it was built to do.
- While investigating, it reads a developer's home directory and finds a stored database credential.
- It uses the credential. Reasonably, from its own perspective: the credential was available and the task required database access.
- It now holds schema-change privileges on a system nobody intended it to touch.
No exploit was involved. No boundary was breached in any way a control would have flagged. The agent's effective authority expanded far past its granted authority, and every individual step was defensible.
The same pattern, across every kind of agent
- A CI/CD agent assumes a deployment role that carries broader permissions than the pipeline needed, and those permissions persist across subsequent runs.
- A SOC automation agent given containment authority on endpoints inherits credentials that also work on domain controllers.
- A data pipeline agent follows a service-account trust relationship into a production system it was never scoped against.
- A customer support agent with read access to one tenant's records finds a path to a shared administrative interface.
The shared mechanism is capability accretion. An agent's granted authority is defined at the start of a task. Its effective authority is whatever it can reach by the end, through credentials found in the environment, trust relationships it inherits, tokens it is handed, and sub-agents it spawns. Nothing in a typical deployment forces those two to stay aligned, and the gap only ever widens.
Three things are granted, and all three drift
| Granted | Effective | Drift name |
|---|---|---|
| The access explicitly issued for an assignment | Everything the agent can actually reach right now | Authority accretion |
| The capability level the agent was designed and contained for | The capability level the agent can actually operate at | Level drift |
| The purpose the agent was authorized for | The shape of what the agent is actually doing | Mandate drift |
↔ scroll table
Authority accretion
The agent reaching further than it was granted. Credentials found on disk, tokens inherited from an assumed role, trust relationships that resolve outward.
Closed by: pillar T, credential quarantine.
Level drift
The agent becoming a more capable kind of system than the one you contained. An L3 bounded tool agent handed a shell tool is not bounded, because shell is not one tool. It is every tool. An agent that can install an MCP server acquires capability at run time that no design-time review saw. An agent that can invoke another agent is an orchestrator regardless of what the architecture diagram says.
Closed by: enforced level ceilings.
Mandate drift
The agent performing work of a shape it was not authorized for. The development agent above harvested a credential and used it for lateral access. That is a textbook privilege escalation chain executed by an agent with an operational mandate, running under containment sized for an assistant that holds no tools.
Closed by: pillar O, drift monitoring.
Level drift enables authority accretion, because more capability means more reachable paths. Authority accretion produces mandate drift, because an agent using found credentials is doing adversarial-shaped work. Level drift is the upstream one, and it is the least monitored.
Four assumptions underpin most access governance. All four break under autonomy.
Scope was communicated in natural language
Rules of engagement, task descriptions, and system prompts live in documents and instructions. An agent cannot be held to a document. It can be held to a routing table and an IAM policy.
The operator is trusted to interpret ambiguity
A human developer who finds a production credential in a config file typically pauses. An agent optimizing toward task completion treats it as the unblocking resource. Ambiguity resolves toward continuation, every time, at every step. This begins at L3 and is definitional at L4.
Tooling does not have goals
A build script does not decide to try one more thing. An agent pursuing an objective will pursue it, and the shortest path frequently runs through systems nobody scoped: a shared identity provider, a managed service tenant, a partner connection, a database that happened to accept the credential.
Input is inert
Agents consume attacker-controllable content as a core function: web pages, service banners, file contents, log entries, error messages, dependency documentation, ticket text. Any of it can carry instructions. A poisoned error message in a build log is enough. The agent is an attack surface.
Granted authority is checked at the start and effective authority is never checked again. Level and mandate are assigned once at design review and never re-derived from what the agent can actually do. Most access governance was built for identities holding a stable set of permissions. Agents accumulate, and agent architectures change under them.
Work release, not confinement and not freedom
Someone on work release has genuine autonomy. They travel, they do real work, they exercise judgment on the job. But they operate under a written authorization naming the permitted employer, route, and return time; a supervising officer with the power to revoke; and conditions enforced by the institution rather than by the individual's good intentions. The authorization is specific, time-limited, and does not renew itself.
That is the posture this framework takes toward agents. They should have real range of motion, and that range should be enforced by something the agent cannot modify, argue with, or reason its way around. An agent is not trusted staff and it is not a locked-down tool. It is released under conditions, and the conditions are the control.
The analogy is deliberately uncomfortable because the security posture is intentionally distrustful. That distrust is not punitive. It is architectural. The framework assumes an agent may misunderstand instructions, pursue an unexpected path, consume hostile input, accumulate credentials, acquire new capabilities, or behave as though compromised. Containment must therefore depend on enforceable conditions rather than the agent's intentions or cooperation. Section 0 and Appendix B of the specification address the choice of language directly.