Build1 publisherNot yet confirmed elsewhere3 min readPublished
Cloudflare wants the task run, not the person, to be the thing you authorise
Its proposed Agent Access Model says the fix is not smarter access decisions but smaller grants, sized to a single task run. The half Cloudflare admits it has not built is the interesting part.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

What happened
- Cloudflare has published a proposed Agent Access Model whose method is to make an agent's capability smaller rather than make each access decision smarter.
- Cloudflare's stated diagnosis is that human-shaped controls fail quietly against agents by granting too much, seeing too little and trusting for too long.
- Service-account keys are long-lived, broadly scoped and rarely rotated, so pointed at a short-lived run they outlive the work and sit where they can be replayed.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Matching credential life to task life moves issuance out of the quarterly access review and into the runtime, which is an identity-platform build, not a policy update.
- cost If prevention has to sit in the request path, someone has to own that path for every agent action, and that bill lands on platform engineering rather than on the reviewer signing off entitlements.
- exposure Teams treating written instructions as a boundary are exposed by design, because the same data an agent is asked to read can carry the thing that redirects it.
- precedent Naming the run as the unit of authorisation invites a directory sized to task volume rather than employee count, which is the number vendors will now have to price against.
Put the two clocks next to each other. Least privilege for a workforce is commonly a policy someone reviews each quarter [7]. The paper says an agent's credential should live as long as its task, which is often minutes [9]. A quarter is about 129,600 minutes, so the cadence enterprises actually run sits four to five orders of magnitude away from the thing it would be governing [13]. That gap is the argument for shrinking the grant instead of sharpening the judgement applied to it [1]. A decision engine can be made cleverer. A quarterly attestation cannot be made ten thousand times faster.
The credential failure is mundane. Service accounts were designed for payroll systems and nightly batch jobs, and they arrive with long-lived keys, broad scopes and rare rotation [8]. Point one at a short-lived run and the key outlives the work it was issued for, sitting in memory, logs or environment variables where it can be replayed [8].
The timing failure is worse because it is invisible. Cloudflare's case is that an agent holding a database connection and an outbound network path can read a table and POST it to an external endpoint before a control tuned to human activity has finished sampling [10]. Detection that arrives after the request completed is a record, not a control.
Then there is the instruction that costs nothing and does nothing. Telling an agent not to touch production shapes behaviour without enforcing access, and the model can be moved by content injected into the data it reads [11].
The definition is doing the real work in this paper. If the principal is one task-scoped run, then the same harness solving a different task tomorrow is a new principal with its own capability ceiling [5], and one human instruction can dispatch several of them, each reaching databases, source control, logs or ticketing [6]. The number of grants to authorise therefore tracks runs dispatched, not people employed [14]. Twelve years of single sign-on and device posture were built for a principal who logs in each morning and generates a trickle of decisions [2][3]. That plumbing has nowhere to hang a grant that dies with the task.
Two things to hold against it. The diagnosis is Cloudflare's own and is asserted rather than measured [4]: no incident count, no observed rate of over-granting. And the model is finished on one side only. Single-principal controls are presented as buildable now; what the paper calls multiplayer access control is named as the harder problem and left there [12]. An enterprise can adopt the scoping discipline today and still have no answer for the case with more than one principal in the chain.
What to watch
- Whether Cloudflare follows with a published mechanism for multiplayer access control, or leaves delegation chains named and unbuilt.
- Whether identity providers ship minute-scale, task-scoped credentials rather than routing agent runs through existing service-account keys.
- Whether anyone outside Cloudflare adopts the task-scoped run as the principal of record in shipping product or standards work.