Cloudflare's Agent Access Model: Permissions Beyond the Prompt

When organizations decide what to delegate to an AI agent, model performance is often one of the first considerations.

The reasoning is straightforward: a more capable model should make delegation safer.

But better model performance does not, by itself, prevent an agent from accessing data it should not reach, carrying out an unapproved write operation, or retaining access after the task that justified it has ended.

The infrastructure that grants and enforces those permissions is a separate part of the design.

From August 3 to 7, 2026, Cloudflare explored that problem during Agents Week. This article focuses on two publications released on August 5: the proposed Agent Access Model and the WriteGuard private beta.

The Agents Week Context

Among the many announcements made during Agents Week, five are especially relevant to this article.

On August 4, Cloudflare introduced Wallets, a programmable payments capability for agents to transact as participants in what it calls the emerging agentic economy; the Agent Development Lifecycle, a reframing of the traditional software development lifecycle for agentic software; and the Cloudflare Agents platform with tracing, replay, and human-in-the-loop approvals.

On August 5, it published the proposed Agent Access Model and introduced WriteGuard.

This article focuses on the latter two.

They are different kinds of artifact, and the distinction matters throughout. The Agent Access Model is not a shipped product but a reference architecture—a design model Cloudflare is proposing. WriteGuard is an implementation that Cloudflare has run internally and has now begun offering to customers as a private beta.

The Agent Access Model—a reference architecture built on “do not trust the run”

The Agent Access Model (AAM) is the framework proposed in “The Agent Access Model,” published August 5, 2026 by Cloudflare’s Matt Silverlock.

The article describes itself as proposing an access model for agents, and explicitly as a reference architecture rather than a wire-level specification. AAM, in other words, is not a feature Cloudflare shipped as a product; it is a design proposal offered to the industry.

At its core is the principle: “Do not trust the run. Authorize every action against the task and its accumulated state.”

Cloudflare positions this as extending the Zero Trust thinking embodied by Google’s BeyondCorp—do not trust something merely because it sits inside the network—from human users to AI agent task execution. BeyondCorp, the article notes, assumed a specific principal: a human at a device, acting at human speed. AAM is presented as an attempt to revisit that assumption for agents.

AAM consists of five principles and a reference architecture that implements them: four active controls plus two supporting systems, six components in total.

The five principles are as follows.

1. Credentials are short-lived and bound to the task.
2. Enforcement lives in the harness and the network, not the prompt.
3. Human oversight is exceptional.
4. Grants are reviewed from evidence.
5. Capability state moves in one direction.

On the second principle, Cloudflare’s position is that a harness earns the name only if it actually enforces, and that its default must be deny. Writing “please don’t go beyond this” into an instruction does not constitute a boundary.

The four active controls are as follows.

Agent Identity Broker issues a short-lived token scoped to a specific combination of agent, requester, and task each time a task is assigned. This establishes the agent’s identity on a per-task basis rather than through a permanent API key.

Task-Scoped Access Engine sets the ceiling on the operations an agent may perform at the moment the task is authorized. This corresponds to the agent’s authorized scope.

The Mediation Layer enforces policy at two boundaries—tool calls and outbound communication—and defaults to deny.

Trust Ratchet is the part we found most interesting. When the system encounters an event classified as protected, it initiates a policy-defined transition to a narrower capability state. The protected response is withheld from the model until the relevant enforcement points have acknowledged the new state. Any capability removed by the Trust Ratchet can return only in a newly authorized task.

Cloudflare’s worked example runs as follows. A report returned by a payments processor is classified as protected, so the harness holds it outside the model context and begins the transition from a baseline state to a restricted one. That transition removes access to payments-processor operations and support actions, retaining only two named ledger reads and a schema-constrained output to a designated finance channel. Once the enforcement points have taken up the new state, the report is passed to the model. A subsequent attempt to invoke a support operation through the prompt is denied independently by both the harness and the network.

The two supporting systems are as follows.

Agent Activity Log records activity captured by the Identity Broker, Access Engine, harness, Trust Ratchet state store, and network enforcement point in an append-only, queryable form. This corresponds to the agent’s operational record. Cloudflare also notes that where tamper evidence is required, the storage system has to provide it—being append-only does not, by itself, guarantee tamper resistance.

Grant Review Loop uses execution records to assess whether grants were too broad or too narrow, and surfaces candidate changes to future task templates. Changes approved here apply only to future tasks; they do not widen a task already running.

One strength of the proposal is that it explains not only how the architecture is intended to work, but also where its current scope ends. On multiplayer access control—whether an agent shared across users may respond to one user based on another user’s information—Cloudflare writes: “We are not comfortable saying that multiplayer access control can be built end to end today.” AAM does not claim to solve the problem; its current boundary is a task execution graph governed by one effective authority fixed before dispatch. This is not a disclosure of a product defect; it is the proposal clearly defining the scope of the problem it currently addresses.

WriteGuard—a private beta for MCP servers

WriteGuard is the capability described in “WriteGuard: fine-grained controls for MCP Servers,” published August 5, 2026 by Cloudflare engineers Scott Roe-Meschke and Kenny Johnson.

Cloudflare describes bringing these controls to its MCP server portals through a private beta, placing WriteGuard at that stage as of August 2026.

WriteGuard is presented as a shared policy, attribution, and auditing layer. Attribution here means recording whether an action was taken by a person directly or by an agent session acting on that person’s behalf.

Each tool has three configuration elements: a risk tier, an enabled or disabled state, and a labeling configuration. Cloudflare states that risk tiers determine whether an action is logged and whether a tool call is permitted. The published GitLab example uses both the risk tier and the enabled/disabled setting, so the examples should not be read as establishing a universal one-to-one mapping between every tier and a single outcome.

Risk tier	Examples Cloudflare gives	Behavior documented in the article
Read Only	Search, viewing a merge request	In the GitLab example, passes through unchanged
Minimal Impact	Adding a reaction, marking as read	Given as examples only; no fixed allow rule is stated in the article
Contained Write	Posting a comment, creating a merge request	In the GitLab example, executed with agent attribution added and an audit event recorded
Critical	Merging a merge request, deploying to production	In the GitLab example, the tool is set to disabled and the call is blocked before execution

In the GitLab example, fetching a merge request passes through as-is; posting a comment executes with agent attribution added while an audit event is recorded asynchronously; and merging a merge request is blocked before the handler runs, with the attempt recorded.

The article opens with a hypothetical scenario—introduced as “Let’s imagine the Case of the Endlessly Closing Tickets”—in which an over-broadly permissioned cleanup agent closes thousands of tickets within a few hours. It illustrates why such controls are needed. The example of dropping a database table is likewise offered as a more severe case one might generally anticipate, not as a count of incidents WriteGuard actually prevented.

Cloudflare says its internal MCP portal connects 27 MCP servers, and that it operates WriteGuard as a shared control and audit layer spanning them. The sequence itself—running it internally before offering it externally—tells us something about the company’s posture toward this class of control.

That said, WriteGuard is not a finished, generally available product. Cloudflare describes the beta as validating how the risk model maps onto customer tools, which downstream applications need which attribution formats, and what audit delivery guarantees customers require. Reading it as already proven at the same level in customer environments would be premature.

Our View: Six Dimensions of Agent Permission Design

Model capability matters, but safe delegation also depends on how permissions are designed and enforced.

MIF uses six dimensions as a practical framework: identity, authorized scope and action ceilings, runtime enforcement, human oversight, operational records, and capability reduction.

AAM and WriteGuard operate at different levels: AAM is a proposed reference architecture, while WriteGuard is a concrete implementation in private beta. WriteGuard can be viewed as a server-side implementation of controls related to pre-execution tool policy, agent attribution, and auditing. Mapped to MIF’s framework, they look like this:

Our dimension	Corresponding material from Cloudflare	Status
Identity	Agent Identity Broker	Reference architecture proposed by AAM
Authorized scope and action ceilings	Task-Scoped Access Engine	Reference architecture proposed by AAM
Runtime enforcement	Mediation Layer, WriteGuard	AAM is a design proposal; WriteGuard is an implementation in private beta
Human oversight and approval	AAM’s principle of reserving human oversight for exceptional decisions, Grant Review Loop	Reserves human review for significant decisions and for approving changes to future task templates
Operational records	Agent Activity Log, WriteGuard audit logs	AAM is a proposal; WriteGuard is an internal implementation now being offered in private beta
Capability reduction	Trust Ratchet	Reference architecture proposed by AAM

Control that consists only of writing “please don’t go beyond this” into a prompt absorbs the full impact of a model’s errors and misreadings of context. Placing control outside the model can create a stronger boundary than relying on prompt instructions alone, provided the relevant execution paths cannot bypass the control.

That proviso is doing real work. AAM itself states that tool calls and communication must not be able to bypass the Mediation Layer, that the shared control plane must fail closed, and that processing outside the boundary is not covered. Coverage follows the mediation boundary: encrypted traffic, activity outside that boundary, and telemetry failures create collection gaps that deployments should make explicit. Placing control outside the model is a strong design, but whether the boundary itself has gaps is a separate thing to verify.

Our own two-pass refinement steps and PR-based publication gate in our article production system come from a related idea: embedding a structure where you cannot proceed unless a check passes, rather than relying on individual exchanges.

The other aspect we find notable is the Trust Ratchet’s one-way design. Once permissions narrow, they do not loosen within that task. We see value in a design that defaults to a narrower capability state when uncertainty arises, while recognizing that it may also block legitimate work.

Cloudflare is direct about that trade-off: a broad ratchet policy will deny benign activity along with malicious activity, particularly while classifications and destination policies remain coarse, and the mechanism does not prove that every permitted output is safe. Which accesses to protected data should trigger a reduction, and which destinations should remain available, are design choices that need tuning against actual denial records.

Why so many control capabilities arrived in the same week

Agents Week paired capabilities that expand what agents can do, such as Wallets, with proposals and products focused on control, attribution, observability, and security.

Cloudflare itself notes that as agents become more capable and autonomous, the challenges extend beyond model performance to identity, communication, orchestration, memory, observability, and security.

The following is MIF’s interpretation: the clustering of these announcements suggests that expanded agent capabilities and governance controls increasingly need to be developed together. Cloudflare’s framing of agents as participants in an emerging agentic economy presumes that agents will increasingly conduct transactions. As agents are permitted to execute more transactions and write operations, the importance of enforceable limits grows.

This remains, however, Cloudflare’s work as an infrastructure provider; adopting it does not resolve the permission design problem in full. Which tasks to delegate to an agent, what to designate as protected, and who approves exceptions are ultimately design decisions for the adopting organization.

Before Granting an Agent Operational Permissions: A Starting Checklist

Whether or not you end up using capabilities like AAM or WriteGuard, reviewing the following dimensions in advance can reduce design gaps.

The items and their granularity below are one example; the specific scope and operational strictness should reflect your organization’s operations, risk tolerance, and regulatory environment.

Dimension	Question to confirm	Likely implementation location
Identity	Is the agent’s identity scoped per task, or is a permanent key reused?	Authentication infrastructure, secret management
Authorized scope and action ceilings	How are the permitted data and tools fixed for this task?	Permission management, workflow design
Runtime enforcement	Is the default allow or deny? Which exceptions require human approval?	Middleware, connection infrastructure settings
Capability reduction	When it accesses protected data or attempts a disallowed operation, can permissions narrow automatically?	Permission management implementation, internal policy
Operational records	Can you later trace which agent, acting on whose behalf, executed what, under which task and policy outcome?	Logging infrastructure, audit systems
Runtime write decisions	Are write operations sorted by severity of risk? Which operations cannot be undone?	Connected tool settings, internal operating rules
Completeness of the control boundary	Do all tool calls and outbound communications pass through the control points you declared? Can direct connections, alternative clients, encrypted flows, or off-path execution bypass those controls?	Harness, network, MCP servers, connection design

That last row deserves particular attention. In a follow-up post on August 14, Cloudflare separates the places MCP traffic can be observed or managed into three layers—the client, the network, and the MCP server—and is explicit that some paths fall outside all of them. Local stdio calls, off-network connections, traffic excluded from TLS inspection, and requests that never traverse the gateway remain outside that view, and someone can connect directly to an upstream URL and skip a portal’s policy, curated catalog, and tool-level audit trail entirely.

What matters when building this table is not confusing which items are outer boundaries the agent itself cannot change with which are merely internal rules everyone is expected to follow.

The former is intended to be enforced technically outside the agent. The latter remains effective only while the organization continues to follow its operating procedures.

Conclusion—Model Capability and Permission Design Are Separate Engineering Problems

The two Cloudflare publications examined here focus less on making agents more capable and more on controlling the authority under which they act.

AAM proposes task-scoped credentials, mediated execution, evidence-based grant review, activity logging, and one-way capability reduction. WriteGuard provides a narrower, concrete implementation for classifying and controlling MCP tool writes, adding agent attribution, and recording activity.

They occupy different stages: AAM is a proposed reference architecture, while WriteGuard is a private beta still being validated with customers. Neither should be treated as a mature, final answer to agent permission design.

Infrastructure also cannot decide which tasks an organization should delegate, what should count as protected, or who should approve exceptions.

Before granting an agent operational permissions, organizations should assess not only model capability, but also where permissions are enforced, which paths can bypass those controls, what evidence is recorded, and who can stop the agent when unexpected behavior occurs.

Sources and Verification

This article was prepared as of August 20, 2026, drawing primarily on the following posts from Cloudflare’s official blog.

• “Everything we launched during Agents Week” (Shelley Jones, Ann Ming Samborski, Kathy Liao, published August 10, 2026)
• “The Agent Access Model” (Matt Silverlock, published August 5, 2026)
• “WriteGuard: fine-grained controls for MCP Servers” (Scott Roe-Meschke, Kenny Johnson, published August 5, 2026)
• “How Cloudflare detects MCP traffic and helps secure it” (Kenny Johnson, published August 14, 2026)

The Agent Access Model is a reference architecture proposed by Cloudflare; it was not announced as a single product or a generally available capability.

WriteGuard is offered as a private beta for MCP server portals, based on a mechanism Cloudflare has operated in its internal MCP environment.

The published posts do not present quantitative validation of safety or defensive effectiveness in customer environments.

The six-dimension framework—identity, authorized scope and action ceilings, runtime enforcement, human oversight, operational records, and capability reduction—and the cross-cutting interpretation of the Agents Week announcements are MIF’s own analysis.

Product availability, specifications, risk classifications, and audit capabilities may change.