Agent Access Model: Why AI Agents Need Task-Bound Authority, Not Smarter Prompts

TL;DR

• Cloudflare's Agent Access Model (AAM) argues that BeyondCorp's identity-and-device model, built for humans, does not transfer to software agents that act at machine speed and compose authority across tool calls.
• The human-shaped controls fail quietly: durable service-account credentials outlive short tasks, and prompt instructions cannot enforce a boundary against tool or network actions.
• AAM's core move: authorize every action against the task and its accumulated state, not against a standing identity. Credentials are short-lived, task-scoped, and sender-constrained; enforcement lives in the harness and the network, never in the prompt.
• The reference architecture names six components — an Identity Broker, a Task-Scoped Access Engine, a Mediation Layer, a Trust Ratchet, an Agent Activity Log, and a Grant Review Loop — and leans on existing standards (RFC 8693, RFC 9449, MCP authorization) rather than inventing new ones.
• Cloudflare is explicit that "multiplayer access control" — an agent serving several humans with different entitlements — is not solved end to end today, citing a benchmark reporting privacy-violation rates between 15.8% and 50.9% in simulated enterprise workflows.
• The practical starting point is deliberately small: one bounded agent, one system of record, short-lived authority, mediated actions, and an activity log before wider rollout.

The shift Cloudflare is describing

Cloudflare's paper starts from BeyondCorp's central claim: a request's origin should not decide whether it is trusted, but the identity and health of the device making it should. That model now sits underneath most Zero Trust deployments. The paper then points out what BeyondCorp assumed without saying so: the principal on the other end of the request is a human, logging in each morning, working at human speed, generating a "trickle of access decisions a system can reason about."

Agents don't have that shape. Cloudflare defines an agent as one task-scoped run, and introduces the term task execution graph for all the work belonging to that run under a single capability ceiling and trust level. A single instruction — reconcile these ledgers, triage the overnight alerts, open a pull request — can dispatch one or more of these graphs, each reaching into databases, source control, ticketing systems, or spreadsheets. The paper's framing is blunt about what happens when human-shaped controls meet this pattern: "The controls we built for humans do not fail loudly when we point them at agents. They fail quietly, by granting too much, seeing too little, and trusting for too long."

Why service accounts and prompts are the wrong controls

Cloudflare identifies four specific mismatches between human-oriented controls and agent execution, and each maps to a concrete failure mode.

Service-account credentials were built for long-lived software — a payroll job, a nightly batch — and typically carry broad scopes and rare rotation. Applied to a task that finishes in minutes, that same credential outlives its purpose and sits in memory or logs where it can be replayed. Anomaly detection and rate limits tuned for human activity are also too slow: an agent with a database connection and an outbound path can read a table and exfiltrate it before a human-tuned control finishes sampling, which is why the paper insists preventive controls "have to run inline, at the point of action."

The sharpest of the four is the claim that the prompt is not a perimeter. Telling an agent "do not access production" shapes behavior; it does not enforce anything, because a model can be manipulated by content injected into the data it reads, and an attacker can shape the same signal a risk model would use to infer intent. Cloudflare's line on this is one worth keeping intact: "A boundary you can talk your way past is not a boundary." Finally, agents compose authority across hops — one agent invoking a tool that invokes another agent that calls an API on a human's behalf — and existing delegation primitives, built for a single hop, lose track of who a downstream action is actually for.

The five principles behind the Agent Access Model

AAM's opening rule is stated directly: "Do not trust the run. Authorize every action against the task and its accumulated state." Where BeyondCorp removed implicit trust from the network, AAM removes it from the task execution graph — no action's authorization carries over to the next, and accumulated state (what the graph has already touched) can only shrink what it is still allowed to do.

Five principles follow. Credentials are short-lived and bound to the task, using sender-constrained tokens so a stolen token alone cannot be replayed without a harness-held proof key. Enforcement lives in the harness and the network, not the prompt — the prompt expresses intent, it never enforces a boundary. Human oversight is exceptional rather than constant, reserved for decisions that warrant it. Grants are reviewed from captured evidence rather than adjusted by guesswork, with approved changes applying only to future tasks, never the active one. And capability state moves in one direction: a mechanism the paper calls the Trust Ratchet removes capabilities across a task execution graph when a declared protected event occurs, and that authority returns only inside a newly authorized task.

Inside the reference architecture

Cloudflare grounds each principle in a named component rather than leaving the model abstract. The Agent Identity Broker issues a credential at dispatch that is task-scoped — encoding which agent, acting for which principal, doing which task — and sender-constrained, so the model itself never holds the proof key. This leans directly on two IETF standards rather than a proprietary format: OAuth 2.0 Token Exchange (RFC 8693), which narrows a token by audience, resource, or scope through a Security Token Service, and DPoP (RFC 9449), which binds a token to a client key and proves possession on each request — though only for the HTTP method and target URI, not the request body or tool arguments, which is why the harness still has to authorize the full request itself.

The Task-Scoped Access Engine decides, per request, whether a given identity may perform a given action against a given resource, using a task template — declared at dispatch, not negotiated by the agent at runtime — as the capability ceiling. The Mediation Layer covers two enforcement boundaries: the harness that brokers tool calls (where Cloudflare notes the Model Context Protocol standardizes transport and supplies an OAuth resource-server boundary, but leaves per-tool and per-argument policy to the harness itself) and the network layer governing egress. The Trust Ratchet is the mechanism for narrowing capability mid-task — for example, closing external destinations after a protected read — and Cloudflare specifies that any conflict, timeout, or missing acknowledgment during that transition "blocks the response," failing closed rather than open. Two supporting systems, the Agent Activity Log (an append-only record fed by every enforcement point, not by the model's own account of what it did) and the Grant Review Loop (which proposes revoking unused grants or widening under-permissioned ones based on evidence, never adjusting the active task), round out the six.

Cloudflare is careful to flag what standards don't yet cover: the Trust Ratchet, cross-layer mediation, and a common event contract across the Agent Activity Log remain architectural requirements, not existing protocols. AAuth (draft-hardt-oauth-aauth-protocol-09) is named as a work-in-progress that could realize part of the identity layer.

A concrete test case: the reconciliation agent

Cloudflare walks through a nightly reconciliation agent that reads a settlement report from a processor API, compares it against two production ledgers, and posts a summary to a messaging channel. The control worth naming is the output path: rather than letting the model construct a free-text message, a trusted adapter stores the structured result and returns an opaque identifier bound to the task, and the only posting tool available accepts that identifier and writes a fixed schema — status and numeric aggregates, size-limited, no free-text field. "The model cannot bind the identifier to arbitrary bytes." That's a specific illustration of the second principle: enforcement doesn't depend on the model behaving, because the tool surface never gives it the means to misbehave.

Why multiplayer access control stays unresolved

Cloudflare doesn't oversell the model's reach. The paper is explicit that the single-principal case — one human authorizing one task — has usable standards behind it, but a shared agent serving several people with different entitlements is a different, unsolved problem. If an agent has read data only one of two users can see and the other later asks a related question, answering from that data leaks across a boundary the organization drew deliberately; refusing everything either can't see collapses the agent to their common permission set. Cloudflare cites a recent benchmark, CI-Work, reporting privacy-violation rates of 15.8% to 50.9% and leakage up to 26.7% in simulated enterprise agent workflows, and states plainly: "We do not know of a widely deployed end-to-end system that closes the whole chain."

What this means for teams deploying agents now

The practical value of AAM is that it names failure modes teams are already living with — standing service-account keys handed to short-lived agents, prompt instructions mistaken for enforcement, approval fatigue from constant human-in-the-loop gates — and ties each to a specific, buildable control rather than a policy slogan. Cloudflare's own recommendation is narrow and testable: pick one bounded agent that touches a system of record, replace its standing key with a short-lived task-scoped credential, route its tool calls and outbound connections through mediation, and turn on activity logging before trying to generalize further. For organizations weighing where to start their own agent-governance work, that sequencing — one agent, real mediation, evidence before broader rollout — is a more defensible starting point than a platform-wide policy rewrite. Netics tracks this kind of infrastructure-security shift closely at neticslabs.com, where the same question keeps recurring: does the control live where the action actually happens, or does it live in a document nobody enforces.

The honest caveat in Cloudflare's own paper is worth repeating rather than smoothing over: AAM is a reference architecture, assembled partly from existing IETF and MCP standards and partly from components — the Trust Ratchet, the common event contract — that don't yet exist as shared protocols. Teams adopting the pattern today are building custom plumbing around a well-argued shape, not deploying an off-the-shelf product.

A practical next step

For a team starting this work, the sensible first boundary is one bounded agent touching one system of record. Replace its standing credential with a short-lived task-scoped credential, mediate its tool calls and outbound connections, and record the enforcement decisions. That is a small enough surface to test and a meaningful enough surface to expose where the policy is incomplete. Netics can help teams design this kind of bounded automation review.

Source: “The Agent Access Model” — Cloudflare Blog, 2026-08-27.