Agent identity

What is an agent identity?

An agent identity is an account that belongs to an AI agent rather than to a person. The agent authenticates with it, receives its own permissions, and appears under its own name in your logs.

That sounds obvious until you look at how most agents are actually running today. They use the account of the colleague who built them, or an API key in a configuration file, or a shared service account that already had access to everything so nobody had to think about it. All three work fine right up to the first question you cannot answer, which is usually "who did this".

Microsoft calls these non-human identities, and the reasoning behind giving agents their own is that organisations now deploy agents that assist, agents that act on their own, and agents that behave much like a user. Those need identity constructs of their own so you can authenticate them, authorise them, govern them and protect them the way you already do for people.

Why a shared service account is not enough

Four things go wrong, and each one is the kind of thing that only surfaces at the worst moment.

You lose the trail. If five agents and two integrations all sign in as the same service account, then a log line tells you that the account did something and nothing more. You cannot answer which agent, and therefore you cannot answer why.

Permissions can only grow. A shared account collects the union of everything anyone attached to it ever needed. Nobody dares take a permission away, because they cannot tell what still uses it. Least privilege stops being possible in practice.

The agent inherits a person. An agent running under an employee's account can reach everything that employee can reach, which is almost never what you intended. And when that person changes roles or leaves, the agent either breaks or keeps running on an account that should have been closed.

You cannot apply a rule to it. Access rules, risk detection and periodic reviews all need something to hang on. If the agent is not an identity, there is nothing to hang them on.

What you can do once an agent has an identity

The point of making the agent a real directory object is that all your existing machinery starts working on it.

Access rules. Conditional access can apply to agents, so you can limit which resources an agent may reach and from where, in the same way you do for staff.

Risk detection. Identity protection can flag agents behaving in a risky way, which is what you want if an agent's credentials end up somewhere they should not be.

Ownership. Every agent identity gets a sponsor or an owner, which is the person the review question goes to. This is the field that keeps a registry from going stale.

Lifecycle. Lifecycle workflows can retire an agent's access when it is no longer needed, so an agent does not keep permissions for longer than the project that created it.

Logs. Sign-ins and activity are logged under the agent's own name, which is what makes an audit possible after the fact.

Microsoft has also built this so it does not only cover agents made in Microsoft tooling. Agents built on other platforms can be given a governed identity too, through an authentication SDK or through workload identity federation. The protocols involved are the ones you would expect: OAuth 2.0 for authorisation, MCP for tool access and A2A for agent-to-agent communication. Note that extending the full set of Entra security features to agents requires a Microsoft Agent 365 licence, so this is a budget line and not just a switch.

How this relates to an agent registry

These two are often mentioned together and they are not the same thing.

An agent registry answers the question of which agents exist, who owns them and what they are for. It is an inventory.

An agent identity answers the question of who the agent is when it authenticates and what it is allowed to reach. It is a credential with rules attached.

You need both, and they reinforce each other. An identity without a registry entry gives you an account nobody can explain. A registry entry without an identity gives you a description of an agent that is still using somebody else's login.

What to watch out for with agent identities

Give the agent less than the person who built it. The temptation is to copy the builder's permissions so it works on the first try. Start from what the agent demonstrably needs, and add rather than remove.

An agent that acts for a user is a separate case. There is a difference between an agent doing something on its own behalf and an agent doing something on behalf of a colleague. In the second case the permissions of that colleague also have to apply, and the log has to record both. Decide which of the two you are building before you configure it.

Set an expiry date. If you build an agent for one project, its access should end when that project does. Without a date, that access lives until someone notices, and nobody notices.

More tools means more exposure. Every tool you connect to an agent identity widens what a successful prompt injection could set in motion. Review the tool list at the same time as the permissions, because on their own they each look reasonable.