Who Owns an AI Agent's Identity?

Every AI agent needs two kinds of owner: a named person accountable for what it does, and a system that decides what it may do at any moment. Most organizations have neither. The agent runs on a developer’s API key or a shared service account, and when it does something wrong the logs name the wrong identity.

“Ownership” hides three separate questions. Who is accountable for the agent’s purpose and risk? Who operates it? And who authorizes each action it takes, including the person on whose behalf it acts? This guide separates them and shows where each one lives in the architecture.

Why existing identity categories do not fit

Identity programs were built for two kinds of actor. Agents are neither.

Identity type	How it acts	Authority	Lifetime	Accountable
Human	Own judgment	Role-based, reviewed	Employment	The person
Service account or workload	Fixed code paths	Static, often broad	Long	Owning team
AI agent	Runtime judgment, tool choice	Should be delegated and bounded	Task to persistent	Unclear by default

Two failure patterns follow from that gap.

Borrowed identity. The agent uses the user’s session or token. It carries the user’s full privilege, and every action looks like the user did it. Attribution collapses, and an injected instruction inherits everything the user can do.

Orphan identity. The agent runs on a shared service account or a long-lived API key. Access is broad and standing, nobody owns it, and nothing retires it. OWASP lists agent identity and privilege abuse among the ten major agentic risks.

The ownership model

The architecture below separates six concerns. Each answers one question and has one owner.

Layer	Question it answers	Who owns it	Key design decision
1. Agent identity	What is this agent, and who is it?	IAM team operates it. A named business owner is accountable.	A unique identity per agent, never shared. Separate identities for each environment.
2. Delegation	On whose behalf is it acting?	The delegating user or system	Carry the user’s context alongside the agent’s identity, not instead of it. OAuth 2.0 Token Exchange (RFC 8693) supports an actor claim for exactly this.
3. Authorization	What may it do right now?	Security policy owner, with resource owners	Narrow, task-scoped, audience-restricted tokens. Resource indicators (RFC 8707) bind a token to its target. Sender-constrained tokens (RFC 9449) reduce replay.
4. Credential handling	How does it prove itself?	Platform engineering	No long-lived static keys in prompts, configs or environment variables the agent can read. Prefer attested workload identity and just-in-time issuance.
5. Observability	Who did what, as whom, on whose behalf?	Security operations	Log every tool call with agent ID, delegator, scope and session. Correlate across multi-agent chains.
6. Lifecycle	When does it end?	Business owner	Record the owner, set an expiry, review on a schedule, deprovision when the owner leaves, the project ends or the agent goes idle.

One rule runs through all six layers: accountability cannot be shared. Teams share responsibility, but each agent has one named accountable person. When that person moves roles, the agent is reassigned or retired.

Six decisions you will have to make

1. Its own identity or the user’s?

Give the agent its own identity and delegate a narrowed slice of the user’s authority into it. Never pass the user’s full session through. The exception is an agent that drives a browser or desktop as the user. Treat that pattern as high risk and constrain it heavily, because the agent and the user become indistinguishable in logs.

2. One identity per agent, or per instance?

At minimum, one per agent type and environment, with per-task credentials minted from it. Per-instance identities improve attribution at the cost of more to manage. For agents that touch sensitive data or take irreversible actions, the cost is usually worth it.

3. Persistent or ephemeral?

Make task agents ephemeral by default: credentials exist for the run and die with it. Always-on agents need an owner, a review cycle and tighter monitoring, because their credentials live longer.

4. Where does authorization live?

In a policy layer outside the agent, evaluated on each call. A prompt that says “only use read access” is an instruction, not an enforcement point.

5. How does authority move through agent chains?

Authority may only narrow along a chain. A sub-agent never receives more than its caller delegated, and the full chain is recorded. Without that rule, a low-privilege agent can talk a high-privilege one into acting for it.

6. What about third-party and SaaS agents?

You cannot inspect their internals, so control the edges. Require separate identities from your users’ own, scoped OAuth grants, revocation you can trigger, and an inventory of every consent granted. The Model Context Protocol’s security guidance shows what goes wrong when scopes are too broad and consent is skipped.

Who does what

Role	Responsible for
Business owner (accountable)	Purpose, risk acceptance, periodic recertification, retirement decision
Platform or engineering owner	Building and running the agent, wiring credentials and the policy layer
IAM team	Registration standards, lifecycle automation, inventory of agent identities
Security operations	Monitoring, investigation, credential revocation during an incident
Resource owners	Deciding what agents may access in their systems
Delegating user	The authority they hand to an agent, and noticing when it is misused

What to watch for

Identity-centric detections suit agents well, because the identity is the one thing that stays constant while the model’s behavior varies.

An agent credential used outside its normal runtime or network location
Scope escalation requests, or tokens used after the task that justified them ended
Tool calls outside the agent’s normal profile
A run of reads followed by an outbound send
New agent registrations or OAuth consents that did not go through your process

These feed the same pipeline that handles identity threat detection and response for people and workloads. The agent identities just need to be in it.

Anti-patterns

One shared service account for every agent
A developer’s personal access token in an agent’s configuration
Long-lived API keys in prompts or in environment variables the agent can read
Administrator scope granted to avoid consent friction
No owner field on the agent record
Agents that can create other agents or credentials without limit

Standards are still forming

NIST’s National Cybersecurity Center of Excellence has published a concept paper on software and AI agent identity and authorization. It raises identification, authorization, auditing and non-repudiation as open questions, and the project is at the concept stage. There is no finished agent identity standard to adopt. Build on current OAuth and OpenID primitives, and keep the model portable so you can adapt when guidance firms up.

Check your design

Does every agent have a unique, non-shared identity?
Is there one named accountable person per agent, recorded where the IAM team can see it?
Does each token show both the agent and the user it acts for?
Are tokens scoped to a task, restricted to one audience and short-lived?
Is authorization enforced outside the agent, on every call?
Can a sub-agent ever hold more authority than its caller gave it?
Can you revoke one agent’s access without disrupting the rest?
Does an expiry or review date exist for every agent identity?

Run this list against your most capable agent first. The failures show where autonomous-agent risk is concentrated.

Sources

IETF, RFC 8693: OAuth 2.0 Token Exchange. https://www.rfc-editor.org/rfc/rfc8693
IETF, RFC 8707: Resource Indicators for OAuth 2.0. https://www.rfc-editor.org/rfc/rfc8707
IETF, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP). https://www.rfc-editor.org/rfc/rfc9449
OWASP GenAI Security Project, Top 10 for Agentic Applications. https://genai.owasp.org/owasp-top-10-for-agentic-applications
Model Context Protocol, Security Best Practices. https://modelcontextprotocol.io/specification/draft/basic/security_best_practices
NIST National Cybersecurity Center of Excellence, Software and AI Agent Identity and Authorization. https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization