AI Identity and Access Governance

Governing an AI agent’s access starts with a question most identity programs have not had to answer: whose authority is this software exercising? Until each agent has an answer, permissions get granted by whoever deploys it, and the audit trail cannot say who acted.

This is an identity governance problem before it is an AI problem. The controls that matter are ownership, delegation, scope, lifetime and revocation. The difficulty is that agents break the assumptions each of those controls was built on.

Why existing identity models bend

A human identity is authenticated, accountable and managed through joiner, mover and leaver processes. A service account has a fixed function and predictable behavior. An agent sits between the two and fits neither. It acts on instructions, chooses its actions at runtime, and often runs with either the user’s own privileges or a broad shared account.

The OpenID Foundation’s paper on identity management for agentic AI describes the consequence: when an agent acts as the user, logs cannot tell the agent from the person, and genuine delegation requires explicit on-behalf-of flows. NIST’s National Cybersecurity Center of Excellence reaches a similar place from the other direction. Its concept paper asks how organizations should tell agent identities apart from human ones, and how an agent’s identity should be bound to a human so that approval and accountability still work.

OWASP’s agentic list captures the failure as its own category, identity and privilege abuse. Its guidance on excessive agency adds the practical rule: run actions under the individual user’s identity and scope, not a shared high-privilege account.

Four ways agents hold authority

PATTERN	WHOSE AUTHORITY	GOVERNANCE EXPOSURE	WHAT TO REQUIRE
Agent acts as the user	The user’s full session or token	No separation between person and agent. Logs show the user. The agent inherits every permission the user has.	Avoid for anything beyond low-risk tasks, or constrain by policy to a subset of the user’s access.
Agent acts on behalf of the user	Delegated, with its own identity	Delegation chains and consent fatigue. Users approve more requests than they can review.	Tokens that identify both the user and the agent, so audit shows who authorized and who acted.
Autonomous agent with its own identity	The organization’s, through an owner	Standing privilege and orphaned agents when owners move on.	A named accountable owner, a stated purpose, and scheduled access review.
Agent delegating to other agents	Passed down a chain	Authority that widens or blurs at each hop, with no clear way to narrow it.	Scope narrowed at every delegation step, and chain depth limited and logged.

The governance record for every agent

Governance for agents can be built on existing identity processes, with a few additions. Each agent should have an entry answering these questions. They are a recommended baseline, not a published standard.

Who owns it? A named accountable human, with a process for reassignment when that person moves or leaves.
What is it for? A stated purpose, because purpose is what makes “excessive” measurable.
Whose authority does it carry? The user’s, the organization’s, or a delegated mix, as per the table above.
What is its permission envelope? The tools, data and actions it may use, expressed as policy rather than assumed from the platform’s defaults.
How long does access last? Short-lived credentials by default, with a documented reason for anything standing.
What reviews it? A cycle for recertifying scope and a trigger for review when its tools or data change.
How does it end? A de-provisioning path that removes credentials, tokens and any delegated access.

An agent without an owner and purpose is, in effect, a shadow identity. Treat it as an unmanaged privileged account until it has both.

Technical points that decide whether governance holds

Token audience and passthrough

The Model Context Protocol’s security guidance forbids token passthrough, where a server accepts a token not issued to it and forwards it downstream. It requires servers to refuse tokens that were not explicitly issued for them. The reasons are governance reasons as much as technical ones. Passthrough lets requests slip past controls tied to the token’s audience, and it makes downstream logs show the wrong source, which damages the audit trail that agent accountability depends on.

Scope and delegation

The same guidance recommends starting with minimal scopes and stepping up through targeted challenges when a sensitive operation arrives, and warns against wildcard or omnibus scopes. For delegation chains, the OpenID Foundation suggests narrowing authority at each step, for example through OAuth token exchange, so that a sub-agent never holds more than the agent that called it.

Approval that people can actually perform

Agents can generate more authorization requests than any person can meaningfully review, and reflexive approval follows. The OpenID paper’s answer is to define operating envelopes in policy and ask for human approval only when risk triggers it, using out-of-band mechanisms for high-risk actions so the agent is not left stalled.

Authentication, lifecycle and revocation

NIST’s concept paper lists several standards under consideration for these jobs, including OAuth and OpenID Connect for authorization and authentication, SPIFFE and SPIRE for workload identity, and SCIM for lifecycle automation. It also notes that SCIM handles provisioning only, not authentication or authorization. Revocation is the weakest link. The OpenID paper observes that revoking tokens across a whole system is hard to guarantee, particularly where tokens were delegated for offline use, and that a revoked agent identity can linger as a threat.

What is still unsettled

Be careful about what the sources actually are. NIST’s paper is a concept paper seeking input, not a standard. The OpenID paper notes that vendors are building proprietary agent-identity systems, which fragments interoperability. Cross-domain and multi-user scenarios strain OAuth 2.1, and no widely adopted protocol yet covers an agent that serves a team with different permission levels.

The sensible reading is to build on OAuth, OpenID Connect and existing identity governance, keep agent-specific components replaceable, and avoid committing to a vendor’s private identity model before the guidance settles.

Bringing agents into detection and response

Agent identities are identities, and identity threat detection should cover them. Useful signals to consider, offered as recommendations, include scope elevation outside normal patterns, token use from an unexpected workload, unusually deep delegation chains, and an agent touching resources far from its stated purpose. Without an inventory and owner for each agent, none of those signals has a baseline to compare against.

The decision for leaders

Do not create a parallel identity program for agents. Extend the existing one: add an agent identity type, require an owner and purpose, and carry the same lifecycle discipline across. The harder decision is which agents should be allowed to act as the user at all. That is a risk acceptance, and it belongs with the business owner of the data, not with the team that deployed the agent.

Where to start


Take the agents already running in your environment and fill in the seven-point record for each. The ones you cannot complete, usually owner and purpose, are your unmanaged identities.

Sources

Identity Management for Agentic AI — OpenID Foundation, AI Identity Management Community Group openid.net
Accelerating the Adoption of Software and AI Agent Identity and Authorization (concept paper) — NIST National Cybersecurity Center of Excellence
Model Context Protocol: Security Best Practices — Model Context Protocol project
OWASP GenAI Security Project: Top 10 for Agentic Applications — OWASP genai.owasp.org
OWASP GenAI Security Project: Top 10 for LLM Applications, Excessive Agency — OWASP