AI Agent Identity Governance: Controls and Framework

AI agent identity governance is the set of policies, ownership rules, access certifications, and lifecycle controls that decide who can create AI agents, what those agents reach, and how their access gets reviewed over time. It applies familiar identity governance disciplines (ownership, certification, least privilege, deprovisioning) to a class of non-human identity that takes action on its own across cloud and connected applications. Done well, ai agent identity governance closes the gap between what an agent is configured to do and what it actually does once it starts running.

Governance is not the same as agent identity management. Management concerns the identity record itself: the credentials, the tokens, the authentication path. Governance sits a level above. It sets and enforces the policies, reviews, and controls that keep agent access tied to a real business need for as long as the agent exists.

The reason this matters now is speed and scale. Agents hold bearer tokens, inherit OAuth scopes, and act across platforms faster than any person could. They behave like a machine insider. Yet no insider risk program accounts for them, and no quarterly certification lands in a manager's inbox for the thousands of agents an enterprise may already be running before anyone starts counting.

Identity governance for agents extends five functions to non-human identity: inventory, ownership, entitlement mapping, certification, and lifecycle enforcement. The mechanics differ from human governance because agents authenticate with tokens rather than passwords, and their permissions come from a creator's credentials or a connector's scopes rather than a user profile. The discipline of ai agent identity governance is making those five functions work on entities that were never designed to sit inside an identity program.

The workflow reads like this:

1. Discover every agent across every platform in use, including shadow agents that never went through a formal request.
2. Assign ownership to a named human, never a shared mailbox or a departed employee.
3. Map effective authority by correlating the agent's configuration with the entitlements it actually resolves inside each connected application.
4. Certify access on a set cadence, with the owner attesting that connectors, MCP servers, and data scopes are still needed.
5. Deprovision when the owner leaves, when the agent goes idle, or when its risk score crosses a policy threshold.

Step three is the hard one. Most tooling stops at theoretical configuration and calls it done. Runtime truth requires watching what the agent does, not reading what its policy claims it can do.

Where it diverges from traditional IAM

Traditional IAM assumes a human lifecycle. A person is hired, provisioned, reviewed each quarter, and offboarded. Agents break every one of those assumptions.

Non-human identities already outnumber human ones by roughly 25 to 50 times in most enterprises, and the ratio climbs with every deployment. An identity program that does not cover them does not cover most of its identities.

Agents move roughly 16 times more data than human users, and around 90 percent hold more privilege than they need. A single ungoverned agent can do damage out of all proportion to how it looks on an org chart. Governance matters because it builds the ownership and control chain that makes fast remediation possible at all.

Three risks make it non-optional:

• Maker mode privilege escalation. A user with no access to a CRM invokes an agent built by a CRM administrator. The agent runs on the admin's credentials. The user pulls records they had no right to see. IAM was not bypassed; it was never consulted.
• Orphaned agents. The creator's account gets disabled. The agent keeps running on the creator's inherited credentials, with no expiry, indefinitely.
• Confused deputy attacks. An agent with elevated permissions gets talked into performing an action on behalf of a user who should not have it.

None of these surface in a standard access review. Governance built for people cannot see them.

The two escalation paths worth watching

Human-to-agent escalation. A user without direct access to a system talks to an agent that carries embedded credentials for it. The user extracts data they were never provisioned to reach. The agent did nothing out of policy. Your IAM was simply out of the loop.

Agent-to-agent escalation. Agent A, with narrow permissions, calls Agent B, with broad ones. Agent B hands back data that Agent A (and by extension whoever invoked it) should never touch. Single-platform tooling misses this entirely, because the two agents may live in different tenants.

Action chaining is the connective mechanism underneath both. Each tool call in a sequence compounds access, and the blast radius of a compromised agent grows with every connector it holds.

Start with inventory. Establish ownership. Cut down maker mode. Certify on behavior, not just configuration. Deprovision without sentiment. The order matters, because each control depends on the one before it.

The controls that carry the most weight:

• A single inventory across platforms. One system of record for every agent, its owner, its connectors, and its MCP servers. This is the precondition for everything else.
• A named human owner. No shared accounts, no service mailboxes, no departed employees. When the owner leaves, the agent moves into a review workflow automatically.
• A maker mode policy. Restrict who can build agents with fixed-credential connectors, and require a security review for any agent that runs with elevated permissions.
• Effective authority reviews. Certify what the agent actually reached in the last 90 days, not just what its config would allow.
• Toxic combination detection. Flag agents that stack risk factors: public access plus sensitive data, maker mode plus admin credentials, an orphaned owner plus active connectors.
• Deterministic guardrails at runtime. Fixed enforcement rules applied to probabilistic agents, blocking privilege escalation and unauthorized tool calls before the action lands.

Set the certification cadence to the agent's risk. Critical-risk agents warrant continuous review. Low-risk agents can ride a quarterly cycle that fits your existing process.

Mistakes that quietly undo the program

• Skipping inventory. Every downstream control assumes you know what you are governing.
• Chasing configuration ghosts. Static analysis of agent policies with no evidence of what happened leaves teams ranking theoretical risks with no way to prioritize.
• Ignoring maker mode. Fixed-credential agents bypass IAM by design, which makes this the single highest-impact gap.
• Treating agents as applications. Application governance tracks an app record. Agents are identities with credentials, and they belong in the identity graph.
• Human-cadence reviews. Quarterly certifications on entities that forge new connections every day miss most of the risk between reviews.

Implementation runs in four phases, and skipping any of them produces governance theater rather than governance.

Phase 1: Discovery. Build the inventory across every AI platform in use, including shadow agents surfaced through browser telemetry and MCP server enumeration. Teams consistently find two to five times more agents than they expected. One assessment turned up hundreds of agents no one had catalogued.

Phase 2: Ownership. Map every agent to a named owner. Flag orphaned agents for immediate review and assign interim owners where the creator has already left.

Phase 3: Risk scoring and toxic combinations. Score each agent on posture (maker mode, public access, orphaned owner) and on effective authority (the data it can actually reach). Push agents with toxic combinations to the front of the remediation queue.

Phase 4: Certification and enforcement. Roll out certification workflows for owners, apply deterministic guardrails at runtime for the highest-risk agents, and wire remediation into ticketing so it carries an SLA.

Most programs stall in phase one because native platform logs sit in silos and demand manual correlation. The move from posture to runtime evidence is what separates programs that ship from programs that only report.

Governing across many clouds at once

The same workflow often runs in more than one cloud simultaneously, and each cloud's native tooling only sees its own tenant. A finance agent in one environment can hand data to a workflow agent in another, and neither platform's dashboard shows the full path. Cross-cloud governance needs:

• A single agent inventory spanning every hyperscaler and agent builder.
• Normalized risk scoring, so a maker mode agent in one platform is directly comparable to an overpermissioned role in another.
• Cross-platform action tracing to catch agent-to-agent communication.
• An MCP server inventory that reaches custom and local deployments, not just the managed ones.

The alternative is a dashboard per cloud, which recreates the exact siloed problem identity teams solved for human users a decade ago.

Governance frameworks including NIST AI RMF, ISO 42001, MITRE ATLAS, and the OWASP Top 10 for Agentic AI increasingly name agent-specific controls. The OWASP LCNC-SEC categories map cleanly to real risks: Account Impersonation (LCNC-SEC-01), Security Misconfiguration (LCNC-SEC-05), and Excessive Data Access (LCNC-SEC-06).

For compliance evidence, security teams need to show:

• A current inventory of the AI agents in scope.
• Documented ownership for each agent.
• Certification records tied to real usage, not a configuration snapshot.
• Deprovisioning evidence for terminated employees whose agents were retired or reassigned.
• Audit trails of runtime activity for any agent touching regulated data.

The reporting requirement, more than the technical control, is often what unlocks budget. Audit committees are asking direct questions about AI exposure that a CISO cannot answer without an inventory in hand.

What breaks when the controls are missing

Three failures follow predictably. Agents pile up access no one reviews, and around 90 percent drift into overpermissioned territory. Orphaned agents keep running on credentials from people who left months ago. And a single incident, a hijacked agent or a compromised connector, produces an outsized blast radius precisely because no one can say what the agent could touch or how to shut it down.

Recent events fit the pattern. Attackers hijacked one AI chat agent and reached more than 700 organizations through a single supply chain event. Agentic failures have wiped out inboxes and deleted production databases. In each case the missing piece was governance: knowing what the agent could do, who owned it, and how to stop it fast. Runtime truth without governance is noise. Governance without runtime truth is ghost chasing. Programs that scale run both together.