Agent Credentials or User Impersonation: Which Pattern Survives an Audit

Give your agent its own credential. Impersonation ships in a week, and then it charges rent on every investigation you run for the next three years. Agent credentials cost more to provision, and they are the only pattern that keeps the audit trail honest. Machine identities already outnumber human ones 109 to 1 in surveyed enterprises, and almost none of them are people.

The short answer

Give the agent its own identity, and pass the user's identity alongside it rather than instead of it. Impersonation is faster to build and it destroys attribution, which is the one property an audit needs. Reserve impersonation for legacy systems that cannot accept a second principal, and scope it tightly.

The two patterns, defined properly before you argue about them

Most architecture debates about agent credentials fail because the two sides are describing three things and naming two. Get the vocabulary right and the decision gets much shorter.

Impersonation: the agent becomes the user

The agent holds or borrows the user's session, token or API key. Downstream systems see the user. There is no second principal anywhere in the request.

RFC 8693, published by the IETF in January 2020, is unusually blunt about what this means. When principal A impersonates principal B, A "is given all the rights that B has within some defined rights context and is indistinguishable from B in that context".

Read that last clause again. Indistinguishable is not a side effect of a sloppy implementation. It is the defined semantic. You are asking the identity layer to erase the difference between your agent and your customer success manager, and it will do exactly that.

Dedicated identity: the agent is its own principal

The agent gets a credential of its own. A workload identity, a client credential, a certificate, a scoped service principal. It authenticates as itself and carries its own entitlements.

Downstream systems now see a subject they have never seen before, which is the point. Every log line names the agent. Revocation kills the agent without disabling a person.

The cost lands immediately. Somebody has to decide what that agent is allowed to do, which is a question nobody had to answer while the agent was quietly wearing a human's badge.

Delegation: the third pattern most teams skip

Delegation keeps both identities in one token. RFC 8693 defines it as the case where "principal A still has its own identity separate from B", and it is explicitly understood that any action is taken by A representing B.

Mechanically, the user stays in the subject claim and the agent lands in the act claim. A chain of delegation is expressed by nesting one act claim inside another, with the outermost representing the current actor. A companion may_act claim states which parties are permitted to act for a given subject.

This is the pattern I would build if the systems in scope support it. It is also the pattern that gets skipped, because it needs a token service and most teams reach for whatever their SDK made easy.

Why impersonation wins sprint one every single time

Nobody chooses impersonation after a design review. They choose it because it is what happens when nobody makes a choice at all.

The permission model already exists. Your application already knows what a logged-in user can see. Handing the agent that same session means the agent inherits a working authorisation model for free, on day one, with no new tables and no new policy engine.

Provisioning also stays somebody else's problem. There is no new identity to create, no lifecycle to manage, no offboarding path to design. The agent appears and disappears with the user, which feels tidy right up to the moment somebody asks who approved a refund.

Be honest about the size of this advantage, because pretending it does not exist is how architecture documents get ignored. Impersonation is days of work. A governed agent identity with scoped entitlements, rotation and lifecycle is weeks to months. That gap is real and it is why the pattern keeps winning.

What impersonation costs you the first time something goes wrong

The bill arrives late, which is the whole problem. Impersonation has no running cost until an incident, a dispute or an auditor arrives. Then it has one very large cost.

Attribution collapses into a single column

An investigation asks three questions. What changed, who did it, and under whose authority. Impersonation answers the first and silently corrupts the other two.

The record says a named employee updated 400 opportunity records at 02:14. The employee was asleep. You cannot prove from the log whether the agent did it, whether the employee did it, or whether an attacker holding the agent's token did it. All three produce the identical row.

That is not a logging gap you can patch by adding a field later. The field has to be populated by the token, and there is nothing in the token to populate it with. The specific fields worth capturing are covered in the 12-field agent audit log specification, and none of them help if the identity layer cannot tell you which principal acted.

The second column of the dedicated identity row is the honest cost. A dedicated credential tells you which agent acted, and it does not by itself tell you which human asked. You need to carry that context yourself, or move to delegation.

The compliance answer was written before agents existed

Teams treat agent identity as an open question. In regulated scope it is a settled one, and it has been for years.

PCI DSS Requirement 8.2.2 governs group, shared and generic accounts. The PCI Security Standards Council's own FAQ on shared authentication credentials, article 1080, states the intent directly. Each user must be uniquely identified so that every action taken is attributable to an individual user ID. Shared credentials are permitted only for an exceptional circumstance, limited to the time necessary, with a documented business justification approved by management.

An agent fleet running on one borrowed human login is not an exceptional circumstance. It is a standing architecture. My reading is that impersonation at scale inside cardholder data environments is a finding waiting to be written, and the same logic transfers to any control framework that asks for individual accountability.

The worked example nobody wants to be part of

In August 2025 the Salesloft Drift chatbot integration was compromised. The attacker did not need a password. They needed the OAuth tokens the integration already held.

FINRA's alert to member firms describes what followed in language worth quoting. By using those tokens, the threat actors "bypassed traditional multi-factor authentication and impersonated Drift to move laterally into customer systems". More than 700 organisations had Salesforce data exported, including accounts, contacts, opportunities and support cases.

The second-order damage is the part that matters here. Attackers combed the exported support cases for embedded API keys, Snowflake tokens and cloud credentials. One integration's identity became a search index for everyone else's.

Third-party access is not a fringe risk any more. The 2026 Verizon Data Breach Investigations Report, published in May 2026, found third-party involvement in 48% of breaches, a 60% rise on the previous year. Every agent you connect to a SaaS system is another third party holding a token. That is why the supply chain risk in MCP servers deserves the same scrutiny as the agent itself.

Now apply the counterfactual. If Drift had impersonated individual users rather than holding its own application identity, revocation would have meant disabling several hundred human accounts across 700 companies. The dedicated identity is what made the containment surgical. That is an argument for the pattern, made by an incident that is usually quoted against it.

What dedicated agent credentials actually cost you

The case for agent credentials is easy to overstate. Here is the bill, itemised, because a recommendation that hides its own cost does not survive contact with a delivery plan.

You now own a provisioning workflow

Every agent needs a request path, an approver, an owner, an expiry and an offboarding trigger. That is a workflow, not a config file, and it needs a human owner in your organisation chart.

The volume is the difficult part. At 109 machine identities per human, manual provisioning stops working long before you notice, and orphaned agent credentials become the default state. This is the same failure the wider non-human identity problem describes, arriving through a door you opened deliberately.

Vendors are pricing this work rather than absorbing it. Microsoft documents Entra Agent ID as giving each agent its own identity with logged authentication and activity. It also documents that extending Entra security features to agents requires a Microsoft Agent 365 licence. Governed agent identity is a line item, not a checkbox.

Secrets sprawl is the failure mode you inherit

Give every agent a credential and you have created a credential distribution problem. The evidence on how that goes is not encouraging.

GitGuardian's State of Secrets Sprawl 2026, published in March 2026, scanned roughly 1.94 billion public GitHub commits. It counted 28.65 million new hardcoded secrets added during 2025, up 34% on the prior year. Secrets tied to AI services rose faster than anything else, up 81% to 1,275,105. Worse, 64% of the secrets confirmed valid in 2022 were still valid in January 2026. Four years in public, never rotated.

The mitigation is unglamorous and well understood. Short-lived tokens over static keys, workload identity federation over stored secrets, and rotation that runs whether or not anyone remembers. If your answer to agent credentials is an API key in an environment variable, impersonation was arguably safer.

There is a second cost that surprises teams. Once the agent is its own principal, you have to decide what it may reach, and most systems do not have entitlements at the granularity an agent needs. This is the same wall described in the permissions gap between Glean and Copilot, and it does not disappear because you picked a different identity model.

The pattern that is neither, and why it is winning the standards fight

You do not have to choose between naming the agent and naming the human. Token exchange names both.

Under RFC 8693 the agent presents its own credential together with a token representing the user, and receives a downstream token that encodes both identities. The user sits in the subject claim. The agent sits in the act claim. Nesting expresses a chain, so a multi-hop agent workflow leaves a readable path rather than a single anonymous actor.

That structure is what makes an agent action defensible six months later. It answers all three investigator questions from one artefact rather than from three correlated systems and a hopeful assumption.

The standards work is moving in the same direction. The OAuth working group's Identity Assertion JWT Authorization Grant draft is informally called Cross-App Access. It builds on token exchange and the JWT authorisation grant profile. An application can then obtain a scoped token for a third-party API through an identity provider both sides already trust. The draft explicitly discusses AI agents integrating with SaaS applications and internal services.

Treat that draft as direction, not deployment. It is an Internet-Draft, it is at revision 04, and drafts change. What it tells you is that the ecosystem is standardising on delegation rather than on impersonation, which is a reasonable input to a decision you have to make this quarter.

The decision, stated plainly

Dedicated identity, with delegation where the systems support it, and impersonation only as a documented exception with a named owner and an expiry date.

Row three is the concession. There are systems where impersonation is the correct engineering answer, and pretending otherwise produces a policy your team quietly ignores.

Two rules make the exception survivable. Log the exception at the token service, so that impersonated calls are themselves an auditable event. And keep the impersonation token short-lived and narrowly scoped, so that the borrowed identity expires long before anybody thinks to reuse it. The commercial version of this discipline is covered in the piece on authority clauses for AI agents, which is what your contracts should say while your architecture catches up.

Where the agent can write, not just read, the identity decision stops being a logging preference. It becomes the control that decides whether a bad write can be attributed and reversed. That is the point argued in the piece on giving agents write access to legacy systems.

Where this argument is weakest

Three places, and the first one undercuts the number in my own opening line.

The headline ratios come from vendor surveys

The 109 to 1 figure is from a security vendor's own survey of more than 2,900 decision-makers. It is self-reported, the definition of a machine identity varies by respondent, and the company selling the answer also ran the study. Treat it as directional evidence that the population is large and growing, not as a measured census.

The same caution applies to the 96% over-privilege figure in that report, which is why it is not in the stat strip. GitGuardian's numbers are stronger because they come from scanning public commits rather than asking people, and even those measure exposure, not exploitation.

A dedicated identity can be worse than impersonation

This is the failure mode I see most often and it is genuinely bad. A team creates one shared service account and grants it broad administrative access so it never blocks a workflow. Then it gives that account a static key and points the whole agent fleet at it.

That is impersonation with extra steps and a longer-lived credential. It fails PCI 8.2.2 for the same reason, and it fails harder because a human's session at least expires. Dedicated identity is only better when it is per-agent, scoped, short-lived and owned. If you cannot commit to all four, impersonation with a good correlation identifier may genuinely be the safer interim state.

The other honest limitation is that none of this touches whether the agent should have acted at all. Identity architecture answers who acted and under what authority. It does not stop an agent that was talked into acting. That is the separate problem covered in prompt injection as an agent security failure, and it is mitigated by a human approval step in the architecture.

Frequently asked questions

Where to start this week

Run one test before you write any architecture document. Pick the agent with the most production traffic and put a single question to your logs. If this agent wrote a bad record at 02:00 last Tuesday, whose name is on the row?

If the answer is an employee who was asleep, you are running impersonation whether or not anyone decided to. Write that down with the agent's name next to it, because that sentence is the entire business case for the work that follows.

Then pick the smallest agent you have, not the most important one, and give it a scoped identity of its own end to end. Provision it, log it, rotate it, offboard it. You will find out what your provisioning gap actually costs on an agent nobody depends on, which is the only cheap time to find out.

Related reading