What is AI agent identity?

AI agent identity is a separate, verifiable identity assigned to an AI agent, so that systems can authenticate it, decide what it may do, and record what it did. The alternative is the common shortcut of running the agent on a person’s login or a shared API key, where logs cannot tell the agent from the human or from other software using the same credential.

Two formal statements are worth knowing. Microsoft describes an agent identity as the account an AI agent uses to authenticate, with an identifier, a display name, a sponsor and a blueprint. The 2026 arXiv paper AI Identity takes a wider view and defines identity as “the continuous relationship between what an AI agent is declared to be and what it is observed to do, bounded by the confidence that those two things correspond at any given moment.” The first is about accounts and credentials. The second adds that identity has to hold up against the agent’s actual behavior.

How agent identity relates to non-human identity

Non-human identity (NHI) is the broader term. OWASP’s NHI Top 10 says NHIs arise when applications in production must be identified, and that these identities are often associated with secrets that serve as credentials. Service accounts, API keys and pipeline bots are NHIs. An AI agent is one more, with a difference: the model chooses its actions at run time, so the permissions granted to its identity are the main limit on what a mistake or an attack can do.

The OWASP list shows which failures to expect, and several apply directly to agents:

OWASP NHI 2025 entry	What it means for an agent
NHI2 Secret Leakage	Keys placed in prompts, logs or tool output can leak
NHI5 Overprivileged NHI	An agent given broad access can use all of it
NHI7 Long-Lived Secrets	Static keys outlive the task they were issued for
NHI9 NHI Reuse	One credential shared across agents hides which one acted
NHI10 Human Use of NHI	A person using the agent’s credential, or the reverse, blurs accountability
NHI1 Improper Offboarding	A retired agent keeps working access

The entry names come from OWASP’s list of ten; the right-hand column is an application of each name to agents, not OWASP text.

What an agent identity contains

Microsoft’s Entra Agent ID is a concrete, documented model. Per its documentation (page updated June 2026), an agent identity is a special service principal with these parts:

Part	What it does
Identifier	An object ID that uniquely identifies the account within a tenant
Credentials	None of its own; the blueprint acquires tokens on its behalf
Display name	The human-friendly name shown in admin tools
Sponsor	The human user or group accountable for the agent, contacted if a security incident happens
Blueprint	The reusable template that sets the kind of agent and shared metadata
Agent’s user account	Optional second account for systems that strictly require a user account

Two design choices stand out. Credentials sit on the blueprint, not on each agent identity; Microsoft lists federated identity credentials, certificates or keys, and client secrets as the blueprint’s credential types. And because every identity comes from a blueprint, an admin can apply a conditional access policy to, disable, or revoke a permission grant for every agent of a kind at once.

The same page covers delegation. When an agent acts for a user, the token’s subject is the user and the actor is the agent identity, so the token names both. Agent identities are single-tenant, though a blueprint can be multitenant.

Microsoft is one vendor’s design. Other identity providers attach different objects to the same problem, so check what a product means by “agent identity” before comparing.

Authenticating with OAuth and MCP

Most agent access still runs on OAuth. The MCP authorization specification (version July 2026, the latest as of November 2026) shows the pattern for tools: an MCP server acts as an OAuth 2.1 resource server and an MCP client as an OAuth 2.1 client. Authorization is optional, and STDIO servers should take credentials from the environment instead.

Three rules in that specification bear on identity:

• Clients must send a resource parameter (RFC 8707) naming the server the token is for.
• Servers must check that a token was issued for them, and must not pass through the token they received to upstream APIs.
• Authorization servers should issue short-lived access tokens.

These limit what a stolen or misrouted token can do. They do not say who the agent is: the client ID names an application, not a particular agent run. For how agents connect to tools, see the Model Context Protocol.

Open problems

The standards are still catching up. The OpenID Foundation’s whitepaper (October 2025) surveys existing resources for securing agents and sets out an agenda for harder problems: scalable access control, identities for agents, distinguishing AI workloads, and delegated authority.

The AI Identity paper goes further. It finds that no current technical or regulatory document adequately governs nondeterministic, boundary-crossing entities, and names five gaps: semantic intent verification, recursive delegation accountability, agent identity integrity, governance opacity and enforcement, and operational sustainability. The authors call these gaps “structural”, meaning more engineering will not close them alone. Recursive delegation is the one most visible in multi-agent systems, where one agent hands work to another.

Standards bodies are asking for input. In February 2026, NIST’s NCCoE released a concept paper on identity and authorization for software and AI agents, with questions on identification, authorization, auditing and non-repudiation, and on controls against prompt injection. Comments closed April 2, 2026. The NCCoE project page says it received over 600 responses and plans an SP 1800 series practice guide, with no draft published as of November 2026.

Practical steps

These follow from the sources above rather than from one checklist:

1. Give each agent its own identity, not a person’s login or a key shared with other software (OWASP NHI9, NHI10).
2. Name a human or group accountable for it, as Entra’s sponsor field does.
3. Grant only the permissions the agent’s task needs, and prefer short-lived tokens over static keys (OWASP NHI5, NHI7; MCP specification).
4. Record both the user and the agent on delegated actions.
5. Retire the identity when the agent is retired (OWASP NHI1).
6. Treat identity as one layer. Permissions do not stop a hijacked agent from using what it was given, so pair them with guardrails that limit what an agent can do.

Tracing which agent did what in HoneyHive

An identity is only useful if its actions can be seen afterward. HoneyHive does not issue or manage agent identities; it can record the identity of an agent on its traces. Per the enrich traces docs, enrich_session() sets attributes once for every trace in a session, and keys outside the typed namespaces go to metadata:

tracer.enrich_session({
    "tenant_id": "acme_corp",
    "user_tier": "premium",
    "app_version": "2.1.0"
})

Use the same call with your own keys, such as the agent’s identifier from your identity provider and its sponsor. The docs say enriched fields can be used to filter events, build custom charts or set up alerts, which lets you ask which agent called a tool or which identity is behind a spike. For what else to capture, see agent observability.

FAQ

Is AI agent identity the same as non-human identity (NHI)?

Agent identity is one kind of non-human identity. OWASP describes NHIs as the identities that arise when applications in production must be identified, often tied to secrets that act as credentials. An agent is one such application, but its behavior is less predictable than a service account's.

Should an agent use its user's credentials or its own?

Its own identity, with the user's authority attached by delegation. In Microsoft Entra's model, a token issued on behalf of a user has the user as subject and the agent identity as actor, so the token names both.

Do the existing standards cover agents?

Partly. The OpenID Foundation whitepaper surveys existing resources for securing agents and says identities for agents, distinguishing AI workloads and delegated authority are open questions. NIST asked for input, until April 2, 2026, on which standards organizations use for agent identity.

Does MCP give an agent an identity?

Not by itself. The MCP authorization specification is optional and builds on OAuth, where the client has a client ID and the server checks the token's audience. How an agent maps to that client is up to the implementer.