TL;DR: PlainID describes how a contract assistant with an app registration, owner field and quarterly certification still exposed a draft acquisition agreement because governance never evaluated access at request time. The control gap is not discovery or review alone, but real-time authorization that binds agent, user and data scope.
At a glance
What this is: This is an analysis of AI agent identity governance and the finding that paper governance can still leave sensitive data exposed when runtime access is not enforced.
Why it matters: It matters because IAM and IGA teams now have to govern agents as active identities, not just register them and certify them on a schedule.
By the numbers:
- The ratio of machine identities to human identities is 82 to 1, according to PlainID.
👉 Read PlainID's analysis of AI agent identity governance and runtime access control
Context
AI agent identity governance is the discipline of deciding which agents may exist, who answers for each one, and what each agent can access, do and expose in real time. The governance gap appears when an agent has an identity record, an owner and a certification trail, but no control that checks the request before sensitive data enters its context window.
Traditional identity governance was built around people with stable jobs, managers and entitlement patterns. AI agents break that model because they can be created outside HR, operate for very different lifetimes and change scope with every prompt, which means the approval point must move from periodic review to the moment of access.
Key questions
Q: What breaks when AI agents are certified like human accounts?
A: Quarterly certification assumes the reviewer can judge whether an entitlement still matches a stable job, manager and workflow. AI agents do not behave that way. They can serve different prompts, users and business purposes while keeping the same identity, so a valid owner field or familiar app name can hide the real exposure path.
Q: Why do AI agents create more governance risk than ordinary integrations?
A: AI agents can connect quickly, run continuously, and accumulate broad permissions across multiple services. That combination makes ownership blur and scope drift more likely, so the real risk is not the tool itself but the uncontrolled access path it creates across enterprise systems.
Q: How can security teams tell whether AI agent approval controls are actually working?
A: Look for evidence that sensitive actions trigger a fresh approval event, that approvals are tied to a specific human principal, and that the agent cannot proceed when the checkpoint fails. If high-risk actions still complete on inherited trust or stale tokens, the control is not working. The test is whether runtime intervention is enforceable, not whether the workflow exists.
Q: Should AI agent governance sit in IAM, IGA or runtime authorization?
A: It has to span all three, but the decisive control is runtime authorization. IAM creates the identity, IGA records who answers for it and what it is supposed to do, and runtime policy decides whether a specific request can proceed. Without that last layer, the programme remains documentary rather than preventive.
Technical breakdown
Why IGA models fail for AI agents
Identity governance for people assumes a stable subject, a manager who can judge need, and entitlements that map cleanly to role and job function. AI agents break that pattern because they are often created in pipelines or notebooks, can persist for seconds or years, and may serve different users with the same credentials. That makes entitlement review too coarse to answer the real question: whether the agent should be allowed to reach a specific data category for a specific request. When the entitlement is identical but the context changes, the governance model loses precision. Practical implication: move approval logic from static entitlements to request-aware policy. Read Top 10 NHI Issues.
Practical implication: Shift governance from certification of named access to decisioning at request time.
How runtime authorization changes the control point
Runtime authorization evaluates the agent, the human behind the prompt and the specific request before data is returned. This matters because an identity record alone cannot tell you whether a buyer asking about vendor contracts should be allowed to see acquisition material hidden in a SharePoint site. The control is not simply allowing or denying an app registration. It is deciding, at the data boundary, whether a request matches the approved purpose, category and user context. That is the difference between governed by policy and merely documented by policy. Practical implication: enforce access before retrieval, not after the model has already seen the data. See the AI Agent Authorisation Guide.
Practical implication: Place authorization at retrieval and tool-use boundaries, not only in identity provisioning.
Why agent scope must follow business purpose, not roles
A role tells you what an identity can generally reach. It does not tell you what the business intended the agent to do with a given task. For AI agents, the useful control is category-based scope: vendor contracts, procurement policies, customer PII or M&A documents, each with separate permissions. That model also has to carry through to sub-agents and delegated workflows, because the same agent may be used by different employees for different tasks. The scope becomes the governing unit, and the request purpose becomes part of the decision. Practical implication: classify data and tools into business categories so the policy matches the actual task. See the AI Agent Identity Security Buyer's Guide.
Practical implication: Use business categories and intent signals as the basis for approval.
Threat narrative
Attacker objective: The objective was unauthorized disclosure of sensitive deal information through an apparently governed AI agent.
- Entry occurred when a procurement team created a contract assistant, registered it in Entra ID and gave it broad read access to SharePoint sites.
- Credential access persisted because the assistant kept a live identity, live permissions and an owner assignment even after the original builder moved teams.
- Impact followed when the assistant returned draft acquisition terms to a junior buyer who had no business need to see them, exposing sensitive corporate development content.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Paper governance is not governance for AI agents: An agent can carry an identity record, an owner and a certification result and still be unsafe if no control evaluates the request at the moment of access. That is the governance failure this example exposes. The programme described the agent correctly, but it did not govern the data path. The practitioner lesson is that identity evidence must be joined to runtime decisioning or it only creates audit comfort.
Access review assumptions collapse when the subject is an agent: Quarterly certification assumes access is stable long enough for a reviewer to understand who should still have it. AI agents can be created quickly, repurposed across prompts and moved between owners faster than review cycles can react. The result is a control that certifies a name and an owner field while missing the actual exposure path. Treat that as a failure of the review model, not a review cadence problem.
Runtime authorization is the named concept this category now needs: A governed AI agent must be evaluated as a live decision point, not a static entitlement container. That means the subject of governance is the request, the user behind it and the data category in play. runtime authorization is where approval becomes enforcement, and without that layer the rest of the programme becomes descriptive rather than protective.
The real control gap is context-aware data access: The dangerous moment is not agent creation or annual recertification. It is the retrieval step, where sensitive data enters the agent’s context and can be paraphrased, summarized or leaked onward. Once that happens, the identity programme has already lost the governance contest. Practitioners should measure whether their controls can stop sensitive content before it is ever placed into the agent’s working memory.
AI agent governance extends IGA, but it does not behave like human IGA: The same lifecycle logic still applies, yet the control object changes from employee to software actor. That means ownership, scope, offboarding and review all matter, but each must be expressed in machine-readable policy and enforced continuously. The implication is not that IGA is obsolete. The implication is that IGA only works here when it is paired with request-time authorization and data-aware policy.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
- Read next: AI Agent Authorisation Guide
What this signals
Approval-only governance leaves agents overexposed: Identity programmes built around periodic review assume access can be certified after the fact. For AI agents, that assumption is too slow, because the control point has to move to retrieval time and tool invocation, where the data can still be blocked.
The operational question is no longer whether an agent has an owner or a certification record. The question is whether the programme can distinguish safe from unsafe use at the moment of access, across the requester, the agent and the data category. That is the boundary that determines whether governance is descriptive or protective.
Runtime authorization becomes the deciding layer: AI agents force IAM and IGA teams to treat request context as part of the identity decision, not a separate security concern. When agents can be repurposed by different employees, the policy must follow the task, not the registration record.
For practitioners
- Discover every live agent Inventory agents across identity providers, orchestration frameworks, MCP servers and cloud AI platforms, then record the business owner, function, environment and approved data categories.
- Replace role grants with category scope Approve agent access in terms of business data and tool categories such as vendor contracts, procurement policies or M&A material, not broad roles or generic entitlements.
- Bind the user to the agent decision Evaluate the human requester, the agent identity and the task together so a low-privilege user cannot reach restricted material through a powerful assistant.
- Block sensitive retrieval before context load Stop restricted documents, rows and columns before they enter the agent context window, because post-retrieval filtering cannot undo exposure once the model has seen the content.
- Review ownership and retirement continuously Reassign ownership when builders move roles, suspend agents when no accountable owner accepts responsibility, and retire dormant agents before their credentials outlive the business need.
Key takeaways
- AI agent governance fails when identity records and certification logs are treated as proof of control without request-time enforcement.
- The practical exposure is sensitive data reaching an agent's context window, where the model can summarize or leak material that should never have been retrieved.
- The decisive safeguard is runtime authorization that evaluates the requester, the agent and the data category before access is granted.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · Top 10 NHI Issues · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on agent identities that are over-empowered and misgoverned at runtime. |
| Recommendation — Apply ASI03 controls to bind agent actions to task-scoped privilege and request-aware authorization. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The scenario depends on an agent registration and owner model that is accepted without runtime validation. |
| NHI-05 — Overprivileged NHI | The assistant has broad SharePoint read access that exceeds the task actually being performed. | |
| NHI-10 — Human Use of NHI | A human buyer drives the request while the agent mediates access, creating a governance dependency between the two. | |
| Recommendation — Verify agent identity continuously and reject requests that rely on identity records alone. Reduce agent entitlements to the smallest data and tool categories needed for each approved task. Treat human-mediated agent requests as shared decisions and enforce user context in authorization. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core failure is that permissions were certified but not enforced against the live request. |
| Recommendation — Map agent access to PR.AA-05 and validate that permissions are enforced at the time of use. | ||
Key terms
- AI Agent Identity Governance: AI Agent Identity Governance is the set of policies, controls, and oversight used to manage how AI agents are identified, authorized, monitored, and retired. It defines who can create or operate an agent, what tools and data it may access, how its actions are logged, and how risk is reviewed across its lifecycle.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Category-Based Scope: A policy model that grants access by business data or tool category rather than by broad role or entitlement. It is especially important for AI agents because their purpose can change across prompts, so the approved scope must follow the task and the sensitivity of the content.
- Integration Window Exposure: The period after an acquisition when systems remain separate but are already under the buyer’s responsibility. In that window, inherited identities, weak authentication, and inconsistent logging can stay live even though accountability has shifted, which makes the estate especially vulnerable to breach and regulatory scrutiny.
What's in the full article
PlainID's full analysis covers the operational detail this post intentionally leaves for the source:
- Five-step governance model for AI agents from discovery through retirement
- How runtime authorization differs from static identity certification in practice
- Policy patterns for classifying data, tools and prompts into business categories
- Evidence and audit considerations for proving agent decisions to regulators
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org