Cloudflare's Agent Access Model: Shrinking the Attack Surface for AI Agents

For over a decade, enterprise security has been built around a simple idea: don't trust the network, trust the user and their device. Google's BeyondCorp led this shift, and it became the foundation of Zero Trust. But that model assumed a human at a keyboard—someone who logs in, works at human speed, and generates a manageable stream of access requests. Now, organizations are deploying agents: software principals that can reason, act, and reach into systems autonomously. These agents are ephemeral, fast, and often operate with broad authority. The controls built for humans don't just fail when applied to agents—they fail quietly, granting too much, seeing too little, and trusting for too long.

Cloudflare's new paper, The Agent Access Model, proposes a different approach. Instead of making each access decision smarter, it makes the agent's capability smaller, so there's less to judge in the first place. The core principle: Do not trust the run. Authorize every action against the task and its accumulated state. This is BeyondCorp applied to the task execution graph, not the network.

Why the human model doesn't transfer

Agents look like service accounts or very fast users, but four properties make existing controls a poor fit:

• Ephemeral agents vs. durable credentials: Service accounts are long-lived, with keys that outlive the task. For agents, credentials should expire with the task—often in minutes.
• Machine speed: Anomaly detection and rate limits tuned for humans react too slowly. An agent can exfiltrate data before a human-tuned control even samples.
• The prompt is not a perimeter: Telling an agent "don't access production" is intent, not enforcement. Models can be manipulated via prompt injection, so boundaries must live in the harness and network layer.
• Composed authority: Agents can invoke other agents, creating chains where the original principal's intent gets lost. Existing delegation primitives handle single hops, not multi-hop chains.

The Agent Access Model: five principles

AAM is built on five principles:

1. Credentials are short-lived and bound: Tokens are task-scoped, sender-constrained (via DPoP), and expire with the task.
2. Enforcement lives in the harness and network: Policy is applied at tool calls and network requests, not in the prompt.
3. Human oversight is exceptional: Approvals are reserved for high-risk actions to avoid fatigue.
4. Grants are reviewed from evidence: Activity logs drive policy adjustments, but never widen the active task.
5. Capability state moves in one direction: The Trust Ratchet removes capabilities on protected events; authority returns only in a new task.

Reference architecture

The architecture includes four active controls and two supporting systems. The Agent Identity Broker issues short-lived, task-scoped credentials using OAuth 2.0 Token Exchange (RFC 8693) and DPoP (RFC 9449). The Task-Scoped Access Engine authorizes each action against the task's capability ceiling, which is defined by task templates intersected with the principal's authority. The Trust Ratchet removes capabilities when protected events occur, and the Agent Activity Log captures evidence for the Grant Review Loop.

This is a reference architecture, not a wire-level spec. It's designed to work with existing standards, and it doesn't depend on any single protocol winning.

What this means for engineers

If you're building AI agents that interact with enterprise systems, this model gives you a concrete pattern for least privilege at machine speed. It's not just theoretical—the components are buildable today with OAuth, DPoP, and a policy engine. The hard part is the multiplayer access control: handling chains of agents and multiple humans. But the single-principal case is tractable now.

The key takeaway: don't rely on prompts to keep agents safe. Enforce boundaries where actions happen, and make credentials die with the task.