Cloudflare's Agent Access Model: Zero Trust for Task-Scoped Agent Runs
TL;DR
Cloudflare's Agent Access Model: short-lived task-scoped credentials, enforcement in the harness and network, and a Trust Ratchet that only narrows access.
Last updated: August 5, 2026
On August 5, day four of Cloudflare's Agents Week, Matt Silverlock published the Agent Access Model (AAM), a 26-minute-read paper that tries to do for agent authorization what BeyondCorp did for network security. BeyondCorp removed implicit trust from the network: a request's origin stopped deciding whether it was allowed. AAM removes implicit trust from the task execution graph, the paper's term for all work belonging to one agent run. Its core rule: "Do not trust the run. Authorize every action against the task and its accumulated state."
The paper is not a product announcement. It is a reference architecture with named components, a concrete example, and an honest line drawn between what can be built today and what cannot. That honesty is rare in the space, and it makes the paper worth reading in full.
What AAM proposes#
AAM's starting claim is that human-era controls fail on agents for four structural reasons. Agents are ephemeral while service-account credentials are durable, so credentials outlive the work they were minted for. Agents act at machine speed, so human-tuned anomaly detection is too slow; prevention must run inline. The prompt is not a perimeter: telling an agent "do not access production" shapes behavior but enforces nothing, and "a boundary you can talk your way past is not a boundary." Finally, authority composes across hops, and the answer to "who is this for, and what are they allowed to do" disappears through delegation chains.
Five principles follow, and the architecture is built around them:
- Short-lived, bound credentials. An Agent Identity Broker mints a credential scoped to the task at dispatch, encoding "agent X, acting for principal H, to do task T." It expires no later than the task. It is sender-constrained via DPoP-style proof keys, and the model never receives it.
- Enforcement in the harness and the network, never the prompt. Tool calls are checked against task policy by the Mediation Layer with a default-deny posture, and outbound traffic is forced through network egress control. The two layers fail independently.
- Human oversight is exceptional. Approvals are reserved for decisions that warrant them, on the grounds that approving every step creates reflexive clicking.
- Grants are reviewed from evidence. An Agent Activity Log feeds a Grant Review Loop that proposes narrowing task templates; changes apply to future tasks only.
- Capability state moves in one direction. The Trust Ratchet removes capabilities when declared protected events occur (for example, a sensitive read strips external destinations). Authority removed by the ratchet returns only in a newly authorized task. Trust can only narrow.
The unit of configuration is the task template, not the run: "reconciliation may read these three tables and post to this channel" is defined once and instantiated per dispatch, so policy count tracks task count, not run count. At dispatch, the Task-Scoped Access Engine intersects the template with the principal's authority to produce the capability ceiling. Undeclared actions are denied.
What this means for developers#
The most useful sentence in the paper is also the most obvious once stated: for a workforce of humans, least privilege is often a policy reviewed every quarter; for populations of short-lived agents, it is a system that runs in real time and leaves an audit trail. Every agent deployment already makes these decisions, usually implicitly. AAM's contribution is to make the boundaries explicit enough to enforce.
Two ideas here deserve more attention than they will get. First, the Trust Ratchet is the strongest formalization we have seen of the containment argument. We made the case in "AI Agent Containment Needs a Capability Ledger" that agent safety needs a monotonic, auditable record of granted capability; AAM names the same mechanism, makes it one-directional, and slots it into a concrete architecture. Second, the identity layer is where most teams are actually behind: our earlier take in "Agent Identity Is the Missing Security Layer for AI Workflows" argued that platforms issue tokens that cannot express per-task scope. AAM's broker is exactly the per-task token that argument was asking for, built from primitives that already exist: OAuth 2.0 Token Exchange (RFC 8693) and DPoP (RFC 9449). Notably, the paper says MCP's OAuth resource-server boundary (spec revision 2026-07-28) fits the model but does not define per-tool or per-argument policy, which connects directly to what we covered in "Zero-Touch OAuth for MCP."
The honest limits#
AAM is explicit about what is not solved. Multiplayer access control, the case of one agent serving Alice and Bob with different permissions in shared context, is called "an open systems problem" that the paper does not claim to solve. The evidence it cites is stark: CI-Work, a July 2026 benchmark of enterprise LLM agents, reports privacy-violation rates of 15.8% to 50.9% and leakage up to 26.7% in simulated workflows, and multi-user agent research reports unstable prioritization and rising privacy violations over multi-turn interaction. The paper's own line: "We do not know of a widely deployed end-to-end system that closes the whole chain." Cached answers computed under one principal's authority and served to another are called out as authorization bugs, not performance optimizations.
For a developer today, the actionable slice is the single-principal case: take one bounded agent, replace its standing key with a short-lived task-scoped credential, route tool calls through harness enforcement and egress through network enforcement, and keep an activity log. That is the same argument Cloudflare made on Monday about the Agent Development Lifecycle: the platform story arrives later, but the primitives and the discipline are available now. Read the paper for the full model, and watch which platform ships the Trust Ratchet first.
FAQ#
What is Cloudflare's Agent Access Model?#
The Agent Access Model (AAM) is a reference architecture Cloudflare published on August 5, 2026, during Agents Week. It is not a product announcement. It removes implicit trust from the task execution graph, the work belonging to one agent run, and its core rule is: "Do not trust the run. Authorize every action against the task and its accumulated state."
What is the Trust Ratchet in AAM?#
The Trust Ratchet removes capabilities when declared protected events occur, for example a sensitive read strips external destinations. Capability state moves in one direction only: authority removed by the ratchet returns only in a newly authorized task, so trust can only narrow.
How does AAM handle agent credentials?#
An Agent Identity Broker mints a short-lived credential scoped to the task at dispatch, encoding "agent X, acting for principal H, to do task T." It expires no later than the task, is sender-constrained via DPoP-style proof keys, and the model never receives it. The paper builds this from OAuth 2.0 Token Exchange (RFC 8693) and DPoP (RFC 9449).
Does the Agent Access Model solve multi-user agent access control?#
No. The paper calls multiplayer access control, one agent serving users with different permissions in shared context, "an open systems problem" that it does not claim to solve. The actionable slice today is the single-principal case.
Continue Reading#
- Agent Identity Is the Missing Security Layer for AI Workflows - why per-task identity is the gap in current agent platforms
- AI Agent Containment Needs a Capability Ledger - the monotonic capability model that the Trust Ratchet formalizes
- Zero-Touch OAuth for MCP: Enterprise Auth Gets Practical - the OAuth primitives AAM builds on, in the MCP context
- Cloudflare's Agent Development Lifecycle - the other half of Agents Week, agent observability as a platform product
Sources#
Get the next deep dive like this in your inbox
One email a week on News and the rest of the AI dev stack. Free.
Read next on AI coding tools
Agent Identity Is the Missing Security Layer for AI Workflows
Agent identity for AI workflows: what the Linux Foundation's Agent Name Service proposal means for verifiable identity, scoped capabilities and audit trails.
7 min readAI Agent Containment Needs a Capability Ledger
Anthropic's Claude containment writeup points to the next security layer for coding agents: deterministic capability ledgers, not another approval prompt.
9 min readZero-Touch OAuth Is the MCP Feature Enterprises Were Waiting For
MCP Enterprise-Managed Authorization explained: zero-touch OAuth moves agent tool access into the identity, policy and audit systems enterprises already run.
8 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.
