The Agent Access Model

For the last twelve years, enterprise security has moved away from trusting the network. BeyondCorp made the case that a request's origin, inside the corporate perimeter or on the open Internet, should not decide whether it is allowed. Identity and device health should.

That model won: it now underpins much of Zero Trust. Google’s BeyondCorp assumed a specific principal: a human at a device, acting at human speed. Organizations are now deploying agents , software principals that reason, act, and reach into systems on our behalf.

A task-scoped agent run is ephemeral. It ends when its work is done. A long-lived agent service may handle many such tasks and move data far faster than a person.

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. This paper proposes an access model for agents: the Agent Access Model (AAM) .

We describe the model and show how its components can be built. We then walk through a concrete example and separate the single-principal controls available today from the harder problem of multiplayer access control . Much of the current work tries to make each access decision smarter.

AAM takes a different approach: make the agent's capability smaller, so there is less to judge in the first place. The shift A decade ago, the hard question in enterprise security was where is this request coming from, and do I trust that place? BeyondCorp's answer was that you should not trust the place at all.

You authenticate the user, interrogate the device, and make an access decision for that specific request. Location became one signal among many, not a verdict. That reframing worked because the principal was legible.

A human logs in each morning, carries a device or two, works at human speed, and generates a trickle of access decisions a system can reason about. We built an entire industry around that shape of principal: single sign-on, device posture, conditional access, session risk scoring. Agents do not have that shape.

An agent service may run many tasks. In this paper, an agent is one task-scoped run. We use task execution graph for all work belonging to that run and governed by the same capability ceiling and trust level.

The same harness solving a different task, consuming a different event, or running on tomorrow's schedule creates a new graph. A single human instruction ( reconcile these two ledgers , triage the overnight alerts , open a pull request that fixes this bug ) can dispatch one or more such tasks. Each may need to reach databases, source control, logs, ticketing systems, knowledge bases, documents, or spreadsheets.

The task may need broad access. It needs it now, for this task, and ideally not one second longer. An agent must have enough authority to complete its task and no more.

Least privilege is as old as access control. What changes is how quickly and often it must be enforced. For a workforce of humans, least privilege is often a policy reviewed every quarter.

For large populations of short-lived agents, it is a system that runs in real time and leaves an audit trail. Why the human model does not transfer Agents look like service accounts or very fast users. Four properties make both sets of controls a poor fit.

Agents are ephemeral. Credentials are durable. Service accounts were designed for long-lived software: a payroll system, a nightly batch job.

They often come with long-lived keys, broad scopes, and rare rotation. Applied to short-lived agents, those credentials outlive the work they were issued for and remain in memory, logs, or environment variables where they can be replayed. The lifetime of the credential should match the lifetime of the task.

For an agent, that is often minutes. Agents act at machine speed. Anomaly detection, rate limits, and data-loss controls tuned for human activity may react too slowly.

An agent with a database connection and an outbound network path can read a table and POST it to an external endpoint before a human-tuned control has finished sampling. Preventive controls therefore have to run inline, at the point of action. The prompt is not a perimeter.

Teams commonly tell an agent do not access production or never send data to third parties . Those instructions help shape behavior, but they do not enforce access. A model can be manipulated by content injected into the data it reads or can produce an unsafe action on its own.

Inferred intent can inform a risk decision, but an attacker can shape that signal through the same text. Enforcement belongs in the harness that mediates tool calls and at the network layer that mediates packets. A boundary you can talk your way past is not a boundary.

Agents compose authority across hops. An agent can invoke a tool that invokes another agent, which calls an API on behalf of the original human. Somewhere in that chain, the answer to who is this for, and what are they allowed to do can disappear.

Existing primitives handle a single hop of delegation better than they handle many hops or several humans. The Agent Access Model The Agent Access Model starts with one rule: Do not trust the run. Authorize every action against the task and its accumulated state.

BeyondCorp removed implicit trust from the network . AAM removes implicit trust from the task execution graph . Authorization for one action does not carry over to the next.

Every action is evaluated against three things: who the agent is, what task it was authorized to perform, and which policy-relevant resources the graph has already touched. That accumulated state can only reduce the graph's remaining capabilities. Google's Beyond Zero makes the same opening move: shrink the trust boundary from the application to the individual action and make the decision at machine speed.

Beyond Zero puts a reasoning engine behind each authorization decision. AAM bounds the capability set that engine must judge.