AI agent identity governance is the missing layer in enterprise AI

At a glance

What this is: This is a practitioner guide to AI agent identity governance, showing that usage controls and identity controls solve different problems and that most organisations lack visibility into what agents can actually access.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes will miss major risk and compliance evidence if they only govern human users and prompt-layer AI usage.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Oleria Security's analysis of AI agent identity governance and enterprise AI risk

Context

AI agent identity governance is the discipline that tracks what an AI agent can access, what it can do, and who is accountable for it. In enterprise environments, the key problem is not only what employees do with AI tools, but the service principals, managed identities, and app registrations those agents create in the background.

Most organisations already have some visibility into prompt use and data leakage risk, but that does not answer the harder IAM question: which AI identities exist, what permissions they hold, and whether those permissions still match business need. That gap sits squarely in NHI governance, IAM, and lifecycle management.

The article’s core point is that identity controls and usage controls are complementary, not interchangeable. If a programme cannot inventory and review AI identities at speed, it will struggle to satisfy least privilege, accountability, and regulatory evidence requirements for agentic systems.

Key questions

Q: How should security teams govern AI agents that hold enterprise permissions?

A: Security teams should govern AI agents as identities, not as application features. That means inventorying the service principal or app registration, recording the human owner, validating granted scopes against actual use, and tying the object into recertification, offboarding, and incident response workflows. Without those controls, the agent can retain access long after its business purpose changes.

Q: Why do AI agents complicate least-privilege access models?

A: AI agents complicate least privilege because their permissions are often assigned before the full operational pattern is known, then left active indefinitely. The result is a standing access footprint that can be broader than the task needs and harder to review than a human user’s access. In practice, scope drift becomes a governance problem, not just a configuration issue.

Q: What breaks when organisations only govern AI usage and not AI identity?

A: What breaks is accountability, not just visibility. Usage governance can tell you what was typed into a model, but it cannot show which agent identity acted, which permissions it held, or whether those permissions were ever removed. That leaves a gap in access review, ownership, and regulatory evidence that security teams will eventually have to close.

Q: Who is accountable for AI agent access when the agent is owned by an administrator account?

A: The controlling human account is accountable for the agent’s access posture, even if the agent itself runs independently once deployed. If that owner account is weak, compromised, or overburdened with many agents, the risk transfers directly to every identity it controls. That is why ownership concentration must be treated as an access governance issue.

Technical breakdown

AI agent identity vs usage governance

AI usage governance looks at what people do with AI tools, such as prompts, copied data, and output handling. AI agent identity governance looks at the agent itself as an identity object: service principal, managed identity, or app registration. That identity is what authenticates, authorises, and persists inside the enterprise. The practical difference is that usage telemetry can show activity, but only identity governance can show standing access, ownership, and whether permissions still exist after the original use case has ended.

Practical implication: build separate control paths for prompt oversight and agent identity inventory instead of treating them as one programme.

Why service principals become AI footprints

When a platform deploys an agent, it often creates a service principal or equivalent identity and grants scopes that define what the agent can touch. In low-code environments, default permissions are often broader than the task needs, because broad scope reduces implementation friction. The problem is structural: the agent’s enterprise footprint is encoded in identity, not in the prompt interface. That means the blast radius is determined by scopes, ownership, and credential age, not by how well a user writes prompts.

Practical implication: review every AI agent as an identity with scopes, owners, and credentials, not as a feature toggle inside the application.

Why dormant AI agents create hidden risk

A dormant AI agent is still a live identity if its service principal, token, or credential remains active. Dormancy removes behavioural familiarity, so security teams lose the baseline they need for detection and response. The agent may have been created for a pilot, abandoned, and then left with high privilege for months or years. That makes inactivity a governance problem, not a sign of safety. In identity terms, unused access is still exposed access until it is removed or recertified.

Practical implication: include dormant AI identities in recertification and offboarding workflows, not only active production systems.

Threat narrative

Attacker objective: The attacker’s objective is to exploit a trusted AI identity to reach enterprise data and actions without needing to compromise the human user directly.

1. Entry occurs when an AI agent is deployed in Microsoft Copilot Studio, Salesforce Agentforce, Azure AI Foundry, ServiceNow, or GitHub Copilot and is issued a service principal or app registration with broad permissions.
2. Credential or scope abuse follows when the agent retains OAuth credentials and over-provisioned access that outlives the original task, creating a standing identity foothold.
3. Impact occurs when that identity is used to access data, execute actions, or interact with connected systems beyond the intended business purpose.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity governance is now a distinct control plane, not a subset of prompt safety. Usage governance can show what employees paste into prompts, but it cannot show what a service principal can do after the prompt ends. That distinction matters because the identity layer carries the permissions, ownership, and lifecycle evidence needed for IAM and compliance. The implication is that AI governance programmes must be evaluated against both layers, or they will remain incomplete.

Identity does not stop at deployment when the actor is an AI agent. AI agent identity was designed for a condition where access could be tracked, owned, and retired through normal lifecycle processes. That assumption fails when the agent persists indefinitely, can be reconfigured quickly, and may never pass through a human offboarding event. The implication is that lifecycle governance for autonomous and semi-autonomous systems cannot rely on human employment metaphors.

Over-provisioned AI scopes create identity blast radius, not just access waste. The article’s example of unused high-privilege permissions shows how agent scope is often set for speed rather than task fidelity. That is a direct least-privilege failure under OWASP-NHI and Zero Trust thinking, because the identity can reach more than it ever needs. Practitioners should treat unused scopes as an exposure class, not an optimisation opportunity.

Shadow AI is an identity inventory problem before it is a policy problem. The central blind spot is not that teams lack rules, but that they do not know how many AI identities exist, who owns them, or whether they are still active. That makes discovery and ownership mapping the first governance functions, with recertification and monitoring following behind. The practitioner conclusion is simple: if you cannot enumerate it, you cannot govern it.

AI identity evidence now maps directly to regulatory assurance. The article shows how identity records support EU AI Act and NIST AI RMF obligations, especially around accountability, monitoring, and security. That means AI identity governance is no longer an internal hygiene exercise. For security and compliance leads, the practical implication is that the identity graph is becoming a regulatory evidence source, not just an operational directory.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Another finding from the same research shows that only 5.7% of organisations have full visibility into their service accounts, which is why hidden AI identities so often evade review.
• For the broader control model, read Top 10 NHI Issues for a practical view of the governance patterns that most often fail.

What this signals

AI identity governance will become a standard part of IAM operating models. Teams that keep AI controls inside security awareness or prompt review workflows will miss the access layer that actually governs blast radius. The next maturity step is to treat service principals, app registrations, and managed identities as first-class inventory objects with owners, review cycles, and revocation paths.

Blast-radius scoring is the right named concept for this category. It captures the fact that one agent can carry permission scope, owner concentration, sibling access patterns, and dormant credentials at the same time. In practical terms, that means security teams need a way to rank AI identities by reach, not by usage volume alone.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the control gap around AI identity will only widen if credential hygiene stays fragmented. The programme response should link identity discovery to secrets management, lifecycle review, and continuous monitoring in one operating cadence.

For practitioners

• Separate AI usage and identity governance controls Track prompt activity, then separately inventory AI identities, scopes, owners, and credential age. Put the identity layer under IAM and lifecycle ownership instead of leaving it in the application team’s backlog.
• Automate discovery from the identity graph Pull service principals, managed identities, and app registrations from identity systems continuously so new, dormant, and ownerless AI identities are visible without manual registration.
• Recertify unused and over-privileged scopes Compare granted permissions against actual usage and remove scopes that have no operational proof. Treat long-dormant agents as priority review candidates because inactivity can hide persistent risk.
• Map ownership chains and escalation paths Identify the human account responsible for each AI identity, then verify MFA strength, credential rotation age, and any sibling agents sharing the same owner or templates.

Key takeaways

• AI governance fails when organisations only inspect prompts and outputs but ignore the service principals and app registrations that actually hold access.
• Over-provisioned and dormant AI identities create a larger blast radius than most teams expect, especially when ownership is concentrated in a few administrator accounts.
• Identity inventory, scope review, and lifecycle control are the practical foundations of AI agent governance, not optional add-ons.

Key terms

• AI Agent Identity: The identity object that represents an AI agent inside enterprise systems. It is usually implemented as a service principal, managed identity, or app registration and carries the permissions, ownership, and authentication details needed to act across connected tools and data sources.
• Blast Radius: The amount of damage an identity can cause if it is misused or compromised. For AI agents, blast radius depends on permission scope, data reach, ownership concentration, and whether the identity remains active after its original purpose has ended.
• Shadow AI: AI agents or related identities that exist in the environment without being properly discovered, owned, or governed. In practice, shadow AI is usually an identity inventory failure first and a policy failure second, because unseen objects cannot be reviewed or revoked.
• Ownership Concentration: A condition where one human account owns many AI identities or related non-human accounts. This concentrates risk because compromising that one account can expose every agent it controls, turning a single identity failure into a wider enterprise incident.

What's in the full article

Oleria Security's full article covers the operational detail this post intentionally leaves for the source:

• The step-by-step identity inventory approach for discovering AI agents through the identity graph.
• The full regulatory mapping for EU AI Act and NIST AI RMF evidence in the AI identity layer.
• The blast-radius scoring method used to assess permission scope, ownership concentration, and dormancy.
• The controls table showing which identity fields to capture for each AI agent at discovery time.

👉 The full Oleria Security article covers discovery, regulatory mapping, and blast-radius assessment for AI identities.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity security across human and non-human estates, it is worth exploring.