Agentic AI breaks your identity model before it breaks anything else

The security conversation about agentic systems tends to start with autonomy: what happens when software decides for itself. In practice the first thing that breaks is duller and more immediate. An agent needs an identity, and enterprise identity models have two shapes available, a person or a service account, and an agent is neither.

The result is predictable. The agent gets a service account, the service account gets whatever permissions the broadest anticipated task requires, and a system that acts on instructions derived from untrusted content now holds standing access it never needs for any single request.

Four properties that do not fit

It acts on behalf of a user, but not as the user. Impersonation gives the agent everything the user has, permanently, including while the user is asleep. Its own service identity, by contrast, detaches the action from the person who asked for it, so the audit trail records that “the assistant” did it. Neither is right. What you want is delegation: the agent’s own identity, constrained to the intersection of its permissions and the requesting user’s, for the duration of this task.

Its permissions should change mid-task. A research step needs read access to a document store. A drafting step needs none of it. A filing step needs write access to one system and nothing else. A single credential spanning the whole workflow is a credential sized for the union of every step, held for the duration of the longest one.

It chains. Agent calls agent calls tool. Three hops later, whose authority is the action taken under, and does the last system in the chain have any way to know? Without a propagated, verifiable delegation context, it does not, and the answer becomes whatever the last service account happened to hold.

It is not deterministic. Traditional non-human identity governance leans on predictability: this batch job touches these tables on this schedule, so anomalies are visible. Agents do not produce that baseline. The same prompt legitimately yields different tool calls on different days.

What works

Scope to the task, not the agent. Issue credentials per task instance, short-lived, carrying the requesting user’s context, with the tools for the current step and no others. Token exchange gets you most of the way there with standards that already exist: the agent presents evidence of the user’s request and receives a narrow, time-boxed token for the next step. The pattern is ordinary delegation. What is new is how many times a minute it happens, which is a token-service capacity question, not a design problem.

Make the tool the boundary. Whatever a tool will do when called with plausible arguments is your real permission model, because the argument values are in the attacker’s influence the moment any untrusted content enters the context. Design each tool as a narrow, validated operation: “refund order X up to £Y”, never “execute SQL”. Then enforce the entitlement inside the tool, against the delegated identity. A tool that trusts its caller to have checked is a tool that will be asked nicely.

Save approval for what cannot be undone. Human-in-the-loop on every step trains people to click approve. Reserve approval for actions that move money, send external communications, change access, or cannot be undone, and let the rest run. Where an action can be made reversible, by staging it, queueing it or writing it as a draft, do that instead. A reversible action needs a much cheaper control.

Log the whole chain. An audit record showing that a service account called an API is worthless three months later. The record needs the task, the requesting user, the delegation path, the tools invoked and the arguments. Assume you will one day have to reconstruct exactly what an agent did on a specific afternoon and answer whether it was entitled to. Build the trail that answers it before you need it.

Revoke at the task level. If the only way to stop a misbehaving agent is to disable an account that fifty concurrent workflows share, you have no containment. Per-task credentials give you a kill switch with a sensible blast radius.

Where governance lands

Two questions decide most of the architecture, and both are asked long before autonomy is:

Who is accountable for what the agent did? Somebody is, and the answer must be a named role that exists on an organisation chart. If the delegation chain cannot be reconstructed back to the person or function on whose behalf the agent acted, that question has no answer, and it will be asked at the worst possible moment.

What is the agent’s maximum authority, stated as a number? Not “it can process refunds”, but “it can process refunds up to £X, at most N per hour, for orders matching these conditions”. Bounded authority is what turns an incident into an anomaly report instead of a disclosure.

The near-term position

The standards are catching up: delegation semantics for autonomous software, verifiable credentials for workload identity, tighter tool-invocation protocols. But the durable answer is already a familiar one. Agents are non-human identities with delegated, short-lived, narrowly-scoped authority, and existing zero trust principles apply to them directly. The work is making your identity platform capable of issuing that authority at the rate agents consume it, and making your tool layer enforce it rather than assume it.

Start there. The organisations that will struggle are not the ones whose agents behaved unexpectedly. They are the ones that cannot say, afterwards, what their agents were permitted to do.