Cloudflare published a reference architecture this week for restricting what AI agents can touch while they work, built around credentials that expire the moment a task ends. The company calls it the Agent Access Model, and it targets a gap most enterprises deploying agents have quietly ignored: agents inherit access patterns built for human employees and long-running service accounts, and neither shape fits how a task-scoped agent actually behaves. Cloudflare’s framing borrows from BeyondCorp, the access architecture Google described in a 2014 USENIX paper. Where BeyondCorp stopped trusting network location, this model stops trusting the run itself.
The real issue is standing credentials, and this is the part the source material undersells. Most enterprises that have shipped agents so far handed them the same kind of API key or service-account token used for a payroll job: something that sits in an environment variable for months and gets rotated on a quarterly cycle, if at all. An agent that queries a production database and posts a Slack summary does not need that key for months. It needs it for the ten minutes its task takes. Cloudflare argues credential lifespan ought to track task duration, not a service’s uptime. The gap between issued access and actually needed access, not a model reasoning its way into an exploit, is where most agent breaches will originate.
The architecture has five working parts. An identity broker mints a short-lived credential scoped to one task, bound to a proof key the runtime holds so a leaked token cannot be replayed elsewhere. An access engine checks each request against a pre-approved task template intersected with the initiating employee’s own authority. A mediation layer enforces policy inside the tool-calling runtime and at network egress, on the premise that a rule stated only in a system prompt is not enforcement, because a model can be talked past it. A ratchet mechanism narrows what a task can still do once it touches sensitive data, and that narrowing runs one way only: capability removed mid-task comes back solely in a freshly authorized task. A review loop turns observed denials and unused grants into evidence for revising the next template, rather than leaving access decisions to a policy owner’s guess.
Cloudflare demonstrates the model with a nightly reconciliation agent that reads a settlement report, checks it against two ledgers, and posts a summary to a finance channel. When one ledger entry contains text instructing the agent to attach account history to a support ticket, the runtime and the network both refuse the request independently, because the ratchet already closed that path once the agent touched sensitive data. Neither refusal depended on the model recognizing the manipulation.
What the paper does not solve may be the costlier problem for enterprises: shared, multi-user agents. An agent serving a workspace with two employees who hold different permissions has no clean answer for what it can say once it has read data only one of them can access. Cloudflare cites research putting privacy-violation rates in simulated enterprise workflows between 15.8% and 50.9%. That is not an edge case for any company running agents across shared CRM records or ticketing queues.
Adopting this model is not a settings change. It means retiring standing service keys, writing task templates for every recurring agent job, and instrumenting a runtime and network layer most security teams do not currently own outside a vendor platform. For a mid-size company, that is months of identity engineering before a single agent ships with a credential that actually expires on schedule. Teams evaluating agent platforms this quarter should ask vendors directly whether task-scoped, short-lived credentials ship by default, or whether that engineering work falls on the buyer.
Published by The Cloudflare Blog on August 5, 2026.
