Yes to identities, and yes to credentials with a caveat. Each agent should have its own identity, so every action traces to that agent and nothing else. It should also have its own credentials, but short-lived, issued per task by a broker, and never visible to the model. The agent proves who it is; it does not carry the keys.
Why not let the agent use a person's login or a shared account?
Because attribution breaks. If an agent acts under a staff member's login, the record says the person did it. If several agents share one service account, the record says "the integration" did it. In both cases, you cannot reconstruct which agent acted, under which version and certificate, or why.
Access also breaks. A person's login carries everything that person can do, which is far more than any one agent needs. A shared service account usually carries the union of everything its users needed. Both make the agent's role scope a fiction. The fuller argument is in why AI agents need their own identities.
What are the options, and what goes wrong with each?
| Option | What goes wrong |
|---|---|
| Agent uses a staff member's login | Actions recorded as the person's; access far wider than the job |
| Agents share a service account | No way to tell agents apart; rights accumulate over time |
| Own identity, long-lived key stored in its configuration | Attributable, but the key can leak and outlives its purpose |
| Own identity, short-lived credentials issued per task by a broker | Attributable, scoped, and expires on its own |
The fourth row is the target. The agent authenticates as itself; a broker checks what it is allowed to do and issues a credential that covers that task and lapses soon after.
Why keep credentials away from the model itself?
Anything in a model's context can end up in its output. A key pasted into instructions or returned by a tool can be repeated in a reply, written into a log, or extracted by a prompt injection hidden in a document. The safe pattern is that the model asks for an action, and a component outside the model attaches the credential when calling the system. Our guide on keeping credentials and keys away from an AI agent sets out that pattern.
Who decides, where is it enforced, and what is recorded?
Who decides. Security owns identity standards: one identity per agent per environment, no shared accounts, no human logins. The process owner decides what each identity may access, drawn from the agent's capability list. Risk signs off on anything at depth 4.
Where it is enforced. At two points. The access management system enforces what the identity can reach at all. The agent platform enforces, at the moment of action, whether this action is allowed for this agent now.
What is recorded. Every action carries the agent's identity, its version, the credential used and its expiry, and, where a person approved a held action, that person's name too. When an agent acts on behalf of a named customer or colleague, both identities are recorded.
What does this look like in practice?
Take a payments firm with three agents: one for onboarding, one for reconciliation, one for customer service. At first they ran under one integration account with access to everything the three jobs needed.
Moving to separate identities exposes the problem. The customer service agent had write access to the reconciliation tables because the shared account did. Nobody had noticed, because nothing had gone wrong yet. With separate identities, each agent gets only what its capabilities need. Credentials are held in a secrets manager and issued per task; storing an AI agent's credentials in a secrets manager covers the setup. Rotation is automatic, so no one has to remember it; see how to rotate the credentials an AI agent uses.
Which controls make this hold?
- No human logins for agents. Ever, including in testing against production data.
- One identity per agent per environment. Not per instance; instances of the same agent share its identity and are told apart by run.
- Brokered, short-lived credentials scoped to the task.
- No secrets in prompts, briefs or tool outputs.
- Access reviews comparing each identity's rights to its capability list.
- Retirement. When an agent is retired, its identity is disabled the same day.
Identity is the base layer of agent governance: without it, no record can say which agent acted.
Questions people ask
Do agents need identities in every system they touch?
They need an identity each system can recognise. Often that is one identity in your access management system, federated to the systems it reaches.
What about agents a vendor runs for you?
Insist on the same rules. The vendor's agent should act under an identity you can see, restrict and disable, not a vendor-wide account.
Should identities be named after the agent's job?
Yes, with the version tracked separately. A name like "accounts-payable-matching" makes access reviews readable.