Why AI agents need their own identities

Every record of who did what depends on identity. If an AI agent signs in as a person, a shared account or another agent, the systems it touches record the wrong actor, and nothing later can fully separate its actions from anyone else's. Each agent needs a distinct identity, with a named owner and only the capabilities it was granted.

What goes wrong when agents borrow identities?

Three common patterns, each damaging in its own way.

Running as a person. A team connects an agent to a mailbox or a CRM using a staff member's credentials, because that was the quickest way to get it working. From then on, every email the agent sends and every record it changes is logged as that person. If the agent makes a mistake, the log blames the person. If the person leaves, the agent breaks, or worse, keeps running on an account that should have been disabled.

Sharing a service account. Several agents, and sometimes scripts and integrations, use one technical account. The connected systems see a single actor. You cannot tell which agent changed a record, and you cannot revoke one agent's access without stopping all of them.

Agents using each other's credentials. An orchestrating agent passes its own token to the agents it coordinates. Each sub-agent now holds the orchestrator's full reach, and every action is recorded as the orchestrator's.

In all three, the record of who acted, which is the foundation of audit, investigation and accountability, is wrong from the start.

Why is the record of who acted so important for agents?

Because agents act at volume and their mistakes repeat. If one agent misreads a rule, it may apply that misreading to hundreds of cases before anyone notices. Finding and fixing those cases means finding every action that agent took. With its own identity, that is a query. With a borrowed one, it is an investigation that may never be complete.

Internal audit relies on the same record. An auditor testing whether an agent stayed within its bounds needs to see its actions, and only its actions, in the connected systems. Our piece on why internal audit needs its own view of agent decisions depends entirely on this: audit cannot see an agent's decisions if the systems cannot tell the agent apart from a person.

What should an agent's identity carry?

An identity is more than a username. For an agent, it should carry enough to support governance on its own.

The last row is easy to overlook. Many identity systems distinguish people from service accounts but have no category for agents. Marking agent identities clearly means access reviews, monitoring rules and incident responses can treat them appropriately. Our playbook on giving an AI agent its own identity in your access management system covers the setup.

Should an agent be able to change its own permissions?

Never. An agent that can widen its own access has no bounds, because any limit you set can be undone by the thing it limits. The same applies to an agent that can create new identities, grant access to other agents or alter the rules it is checked against.

This is one reason identities need named human owners. Changes to an agent's grants should be requested by the owner, approved by someone else and recorded. Our piece on whether an agent should be able to change its own permissions explains the controls in more detail.

How do agent identities work in a chain of agents?

Each agent in the chain should act under its own identity, with its own grants. An orchestrator can ask a sub-agent to do something; it should not hand over its own credentials to let it. The sub-agent's action is then checked against the sub-agent's own bounds and recorded under its own name.

That keeps two properties intact. The record shows exactly which agent did what. And no agent's authority can be inflated by borrowing another's. A drafting agent coordinated by an orchestrator stays at draft, whatever the orchestrator itself may do.

What about acting on behalf of a customer or a member of staff?

Sometimes an agent acts on a person's behalf, for example drafting a reply that will go out under a staff member's name, or taking an action a customer requested. The agent should still use its own identity, with the person recorded as the requester or approver. The record then shows both: who asked, and which agent acted.

This also matters for staff. People working alongside agents need to know that the record will not show them doing things the agent did. Clear identities are part of what makes it reasonable to ask people to supervise agents, a shift we look at in how agents change the shape of operations teams.

What is the trade-off?

Separate identities take more administration. Each one needs creating, owning, reviewing and eventually retiring. Some older systems have a limited number of licences or accounts, or cannot distinguish one technical account from another, and giving every agent its own seat may cost money or need a checking layer in front of the system.

Weigh that against the cost of not knowing who did something. Every borrowed identity is a gap in the record, a broader grant than the agent needs and an account you cannot revoke cleanly. Our discussion of whether AI agents should have their own identities and credentials works through the edge cases. The practical step is simple: list every agent you run and the identity each one uses, and fix every case where that identity belongs to a person, is shared, or belongs to another agent. The governance model that depends on these identities is set out in our guide to agent governance as a bound, not a model.

Where Pryme fits

In Pryme, each agent has its own identity with a named owner and holds named capabilities, each at its own depth, for each customer. Every action is checked and filed under that identity. An orchestrator coordinates other agents through their own identities and bounds, so authority cannot be borrowed along the chain.