Your Agent Needs an Identity, Not a Password

Ask a platform team how their first production agent authenticates and you will usually hear one of three answers. It uses a service account created three quarters ago for a batch job. It uses a personal access token belonging to whichever engineer built the prototype. Or it uses a single API key, stored in a secret manager, shared by every agent in the estate because rotating it would break four pipelines nobody has time to test.

All three answers describe the same failure. The agent has credentials, but it does not have an identity. Credentials answer the question of whether a request is allowed. Identity answers the questions that matter after something goes wrong: which agent did this, who authorised it to exist, what was it permitted to do, when did that permission last get reviewed, and can we switch it off without switching off everything else.

This gap is not exotic. It is the ordinary result of moving fast. Agents arrived through pilots, and pilots inherit whatever access is already lying around. The problem is that pilots became production, and the borrowed access came with them. The most capable actor in your systems is now the one with the weakest identity story.

Control is the second of the four C's, and Chapter 13Chapter 13 · 6 min LockedGovernance Was Built for Humans. Agents Need More.Access control is not action control. makes the case that governance has to move from controlling access to controlling action. Identity is the hinge between the two. You cannot govern actions you cannot attribute.

Enterprise identity systems were designed around a set of assumptions that agents quietly violate. A human has one identity, joins once, leaves once, and does so at human speed. A human sits behind a login flow that can demand a second factor. A human is accountable in a way an audit committee understands.

An agent is different in every one of those respects. It can be created by a deployment pipeline in seconds and duplicated forty times by an autoscaler. It has no browser and cannot answer a multi-factor prompt. It may spawn sub-agents that need narrower versions of its own authority. It runs continuously, so a credential that leaks is exploited immediately rather than at the next login. And it has no career to protect, so the deterrent that keeps humans careful does not apply.

The consequence is that mapping agents onto human identity constructs produces something worse than either. Give an agent a human account and you have destroyed your audit trail, because every action it takes appears under a person's name. Give it a legacy service account and you have a credential with no owner, no expiry, and usually far more privilege than the task requires. Neither approach survives the first serious question from an auditor.

The fix is not a new product category. It is treating agents as a first-class identity type with their own registry, their own lifecycle, and their own review cadence — the same discipline you already apply to employees, applied to something that works faster and never sleeps.

Before any technology decision, you need a list. An agent registry records every agent that can act on a system of record, and it does not need to be sophisticated to be transformative. One row per agent, with a small number of columns that are all boring and all essential.

Give each row a stable agent identifier that never gets reused. Record its purpose in one sentence a non-engineer could read. Record the named human owner — a person, not a team alias, as The Agent Org Chart argued for context ownership. Record the systems it can reach and the actions it can take in each. Record where its credentials live and when they were last rotated. Record the date of the last permission review and the date the identity expires if nobody renews it.

The registry is valuable long before it is complete. The first pass typically surfaces two uncomfortable findings: agents running in production that nobody claims, and agents whose permissions are far broader than their one-sentence purpose could justify. Both are cheap to fix once written down and expensive to discover during an incident.

Expiry deserves particular attention. Human identities are removed by a leaving process. Agents have no leaving process, so identities accumulate. An expiry date that requires a deliberate renewal is the only mechanism that reliably prunes an estate, and it converts a slow accumulation of risk into a scheduled five-minute decision.

The interesting cases in agent identity are not single agents calling single systems. They are chains. A human asks for something, an orchestrating agent decomposes the request, and a specialist sub-agent performs the actual write. Three actors, one intent, and a question that most implementations answer badly: on whose authority did the write happen?

The right model is delegation, and the rule is that authority narrows at every hop. The human can approve refunds up to a limit; the orchestrator receives a token scoped to this one request; the sub-agent receives a token scoped to this one refund on this one account, valid for minutes. At no point does a downstream component hold more authority than the step it is performing requires, and at every point the chain back to the originating human remains legible.

This is where the handoff problems described in The Handoff Problem become security problems rather than quality problems. If the orchestrator passes its own broad credential downstream, a sub-agent that gets confused by injected instructions inherits the full authority of the system, and your blast radius is no longer bounded by the task. The Blast Radius covers how to bound reach; scoped delegation is how you enforce that bound at the credential layer rather than in a prompt.

Practically, this means short-lived tokens issued per task, audiences restricted to the specific tool being called, and a rule that no agent may mint a credential broader than the one it holds. Long-lived shared secrets cannot express any of this, which is the real reason to retire them.

Every organisation agrees with least privilege and very few practise it, because permissions are granted under deadline pressure and reviewed under no pressure at all. Agents make this worse, because the fastest way to unblock an agent at 4 p.m. on a Friday is to widen its role, and nothing ever prompts anyone to narrow it again.

Turn the principle into a mechanism. Grant new agent permissions with an expiry by default, so the wide grant made under pressure lapses instead of persisting. Separate read from write in the role model, so an agent that only needs to summarise cannot be talked into updating. Require a distinct, individually approved permission for irreversible actions — money movement, deletion, external communication, production configuration changes.

Then measure the gap between granted and used. Most access platforms can report the permissions an identity holds against the ones it actually exercised over the past thirty days. For agents, that report is unusually actionable, because agent behaviour is far more repetitive than human behaviour. An agent using twelve of its forty permissions is not an agent that needs flexibility. It is a role definition waiting to be trimmed.

Much of the effort spent on agent credentials goes into hiding them better — a stronger vault, tighter file permissions, redacted logs. Hiding matters, but it is a defence against theft, and the more useful question is what a stolen credential is worth. A secret that lives for ninety days and grants broad access is a serious incident when it leaks. A secret that lives for five minutes and grants one action on one resource is a footnote.

So prefer workload identity and federation over stored keys wherever the platform supports it, so the agent proves what it is rather than presenting something it knows. Where a stored secret is unavoidable, keep the lifetime short and make rotation automatic and unremarkable. A rotation procedure that requires a change window is a rotation procedure that will not happen.

One habit matters more than any of this: never let a secret pass through the model's context. Credentials belong in the execution layer, injected by the runtime at call time, invisible to the reasoning loop. Anything that enters context can end up in a log, a trace, a cached transcript, or a reply — and agent transcripts are retained far more widely than most teams assume. Chapter 16Chapter 16 · 5 min LockedTrust Is Designed, Not AssumedHow leaders earn confidence in AI systems. covers the guardrail layer where this boundary is enforced.

Ask a simple question in your next architecture review: if this agent starts behaving badly at 2 a.m., who can stop it, how long does it take, and what else breaks when they do? The quality of the answer tells you more about your agent governance than any policy document.

Good revocation has three properties. It is granular, so one agent can be stopped without stopping the platform. It is fast, which in practice means credentials expire quickly enough that revoking issuance is sufficient, rather than depending on a long-lived token being centrally blacklisted. And it is available to the people on call, not only to the team that built the agent — a control that requires a specific engineer to be awake is not a control.

Test it. A revocation drill takes fifteen minutes: pick a non-critical agent, revoke it, time how long until its next action fails, then restore it and record what else broke. Teams that run this drill almost always discover something surprising — a cached token valid for another hour, a shared key whose revocation would have taken down three unrelated jobs, a runbook naming somebody who left. Better to find it in a drill than in an incident, which is precisely the argument made in Design for the Bad Day.

When something goes wrong — a wrong refund, a leaked document, an email nobody approved — the organisation does not primarily want a root-cause analysis of the model. It wants a narrative: what happened, who allowed it, and what stops it happening again. That narrative comes from the audit trail, and an audit trail built for humans will not produce it.

An agent action log needs the agent identifier, the human or system on whose authority the action was taken, the tool and resource touched, the parameters at the level of detail your privacy policy allows, the decision path if approval gates were involved, and the outcome. Crucially it needs the version of the agent's instructions and the version of the context it was working from, because the same agent with different context is effectively a different actor.

That last requirement is why identity and context are not separate programmes. Chapter 14Chapter 14 · 7 min LockedFrom Access Control to Action ControlMoving from who can see to what can act. covers audit as a design requirement, and Chapters 10 through 12Chapter 10 · 9 min LockedInstitutional Memory Is the MoatAs frontier models converge, the durable advantage is the accumulated why — decisions, definition history, and organizational logic. cover institutional memory, living context, and portability — the machinery that lets you say which version of the truth an agent was reading when it acted. Without it, your log tells you what the agent did but never why it was reasonable at the time.

The bill for missing agent identity arrives in three forms, and none of them appear as a security incident on the first day. The first is a slow loss of confidence. When leaders cannot get a straight answer about what agents can touch, they respond by restricting scope, and the agent programme stalls in pilots that never expand.

The second is audit friction. Regulated organisations increasingly face direct questions about automated decision-making and the controls around it. Answering with a spreadsheet compiled the week before the audit works exactly once. Answering with a registry, expiry dates, and per-agent logs turns a two-week scramble into a query.

The third is the incident itself, and its cost is proportional to how little you can attribute. A misdirected agent with its own narrow identity is a contained problem: one identifier, one owner, one revocation, one log to read. The same event on a shared key is an investigation across every system that key can reach, with no way to distinguish the misbehaving agent from the four well-behaved ones sharing its credentials. The technical fault is identical. The organisational consequence is not.

In the first week, build the registry. List every agent that can act on a system of record, give each a stable identifier and a named human owner, and record what it can reach. Expect the list to be longer than anyone predicted and expect at least one entry nobody claims.

In the second week, separate identities. Stop the practice of sharing one credential across agents, starting with any agent that can write. One agent, one identity, one owner. Retire personal access tokens from production paths entirely, because they attribute machine actions to people and they leave when the person does.

In the third week, shorten and scope. Move the highest-privilege agent to short-lived, task-scoped credentials, and put an expiry on every permission grant made in the previous quarter. Split read from write in the role model so that summarising and changing are no longer the same authority.

In the fourth week, prove you can stop and explain. Run one revocation drill and record the time to effect. Then take a single real action from a log and reconstruct the full story: which agent, on whose authority, with which instructions and which version of context. If you can produce that narrative for one action, you have the pattern for all of them — and you have something far more persuasive than a policy.

It is tempting to read identity work as friction, the tax paid for moving quickly earlier. It is closer to the opposite. Every meaningful expansion of agent autonomy runs into the same question from the people who carry the risk: if this goes wrong, will we know, and can we stop it? Identity is how you answer yes.

That is why this belongs alongside the economic argument in Every Agent Needs a P&L. Cost accounting and identity are the same instinct applied to different ledgers. An agent with a named owner, a scoped identity, a budget, and an audit trail is a colleague the organisation can extend trust to incrementally. An agent with a shared key and a monthly invoice is a liability that happens to be useful.

The organisations that scale agents through 2027 will not be the ones with the best models. Models will keep improving for everyone. They will be the ones that can say, precisely and without a meeting, what each agent is, who owns it, what it may do, and how to stop it. That is not bureaucracy. That is the infrastructure of trust, and it is the only thing that makes real autonomy something a serious business can approve.