Cloudflare's Agent Access Model: Zero Trust for Task-Scoped Agent Runs

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.

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#

• The Agent Access Model - Cloudflare Blog
• BeyondCorp: A New Approach to Enterprise Security - USENIX login
• OAuth 2.0 Token Exchange - RFC 8693
• OAuth 2.0 Demonstrating Proof of Possession (DPoP) - RFC 9449
• Model Context Protocol - specification and authorization