TL;DR: Most enterprises cannot answer basic questions about their AI agents because the stack was never built to track ownership, access, intent drift or per-agent cost, and first scans often find five to eight times more agents than expected, according to Aizome. The control gap is not visibility alone; it is governed identity, accountability and runtime oversight for agents that keep acting after their builders are gone.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Aizome's blog post: Enterprise AI agent governance fails when organisations cannot inventory agents, bind them to accountable owners, or detect when their runtime behaviour drifts beyond the original purpose.
Why it matters: IAM, IGA and security teams need a model for governing AI agents as runtime identities, because access, accountability and cost control break once agents outlive the people who created them.
Context
Enterprise AI agents create a governance problem that current identity stacks were not designed to solve. They can be built outside central IT, attached to business systems, and left running with inherited access even after the original owner changes roles or leaves. In practice, that makes the first question less about model quality and more about who can prove the agent exists, what it can reach, and who is responsible for it.
This is a lifecycle and accountability issue as much as a technical one. If an agent continues operating on credentials that were issued to a human, or if its purpose changes without a corresponding change in oversight, then normal IAM and IGA processes lose the thread. The governance model has to start with inventory and ownership, then extend to runtime behaviour and spend.
Key questions
Q: How should teams inventory AI agents that are built outside central IT?
A: Teams should record every externally built AI agent as a governed identity subject with an owner, intended purpose, tool list, data sources, model version, and approval path. Use a central register, unique agent ID, scoped credentials, and periodic review so shadow agents can be discovered, constrained, and revoked when no longer needed.
Q: Why do AI systems create accountability gaps in security programmes?
A: AI systems often combine automated access, opaque transformations, and distributed tooling, which makes it hard to reconstruct who did what. When identity events are not tied to data lineage, teams lose the ability to explain outputs, investigate misuse, or prove control execution to auditors and regulators.
Q: What is the difference between AI governance and AI runtime security?
A: AI governance focuses on policies, documentation, approvals, fairness checks, and regulatory evidence. AI runtime security focuses on protecting live models, prompts, data flows, and APIs while systems are running. Both matter, but they solve different problems: governance proves control, while runtime security prevents abuse, leakage, and unsafe behavior in production.
Q: What is the best way to control AI agent spend without losing oversight?
A: The best way is to tie spend controls to the agent’s identity, not just its project budget. Set per-agent limits on API usage, tool calls, token consumption, and approved destinations, then route activity through logging, anomaly detection, and human approval for exceptions. That preserves oversight while preventing uncontrolled runtime spend.
Technical breakdown
Why agent inventories diverge from what IT thinks exists
AI agents are often created in business teams, embedded in SaaS workflows, or activated by vendor updates without a formal registration step. That means the effective estate can be much larger than the catalog maintained by central IAM or security tools. Cloud discovery alone is not enough, because an agent can be logically active without looking like a traditional workload or service account. The hard part is not counting systems you already know about. It is identifying the actors that were never brought into the control plane at all. See the Agentic AI Identity Guide.
Practical implication: Treat agent discovery as a governance exercise, not a tooling exercise, and require registration before production use.
How ownership and intent drift change the identity problem
An AI agent can retain access after its human builder moves teams, leaves the company, or changes responsibilities. It can also begin acting beyond its original purpose, which creates intent drift: the access is still valid, but the behaviour is no longer aligned with the approved use case. That is different from a simple privilege issue. The agent is not just over-entitled; it is operating without a stable accountability chain. Traditional role models assume the person behind the access remains easy to identify and supervise. See the AI Agent Authorisation Guide.
Practical implication: Bind each agent to an accountable owner and review whether the approved purpose still matches the actions the agent is taking.
Why access governance and runtime governance are not the same thing
Access governance answers what an agent is allowed to do at authorisation time. Runtime governance answers what it is actually doing while it runs. Those are related but distinct control layers. An agent may have legitimate credentials and still drift into customer records, financial systems, or other sensitive services that sit outside its intended scope. The governance failure is not that access was never granted. It is that no existing control continuously evaluates whether the live behaviour still matches the declared mandate. See the AI Agent Observability, Audit and Incident Response Guide.
Practical implication: Separate approval of access from monitoring of live agent behaviour, and treat scope drift as a governance exception.
Threat narrative
Attacker objective: The objective is to exploit unmanaged agent identity and inherited access to gain persistent, unaccounted influence over business systems and data.
- Entry occurs when a business user or vendor update creates an AI agent outside central IT oversight, often with inherited access to enterprise systems.
- Credential or permission exposure follows when the agent runs on the creator's access, a reused token, or another standing identity that was never reassigned to a governed non-human identity.
- Escalation happens as the agent continues operating after the human owner changes role or leaves, while its actions expand beyond the original mandate into additional systems.
- Impact is organisational, not just technical: the enterprise loses visibility into who can act, what they can reach, and how much risk or cost they are creating.
Breaches seen in the wild
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
- Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
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
AI agents have become shadow identities before most organisations have built the controls to govern them. The practical problem is not that agents exist, but that they are being created faster than inventory, ownership and oversight processes can absorb them. When a business unit can stand up an agent with enterprise access outside IT, the security programme is already behind. The implication is that identity governance now has to treat agent registration as a control boundary, not an administrative afterthought.
Intent drift is the named governance failure this class of deployment exposes. Access governance can say what an agent may do, but it cannot prove that the agent is still doing the job it was approved to do. That mismatch grows when the builder leaves, the workflow changes, or the agent starts touching delegated agent access across business systems. The lesson is that approval without runtime accountability is not governance, it is a temporary permission record.
Inherited access is the assumption that breaks first. Traditional access models assume a stable human operator behind the entitlement, but enterprise agents often keep running after that operator is gone. That assumption fails when the identity is software, the workload is continuous, and the business value of the agent depends on uninterrupted execution. The implication is that lifecycle thinking must move from human ownership to non-human continuity.
Cost attribution is now part of identity governance for AI agents. If an organisation cannot map spend to a specific agent and owner, it cannot judge whether the identity is creating value or just consuming resources. The broader pattern is that identity teams are being pulled into financial accountability because agent governance now spans permissions, behaviour and usage economics. Practitioners should expect AI agent oversight to sit at the intersection of IAM, IGA and chargeback controls.
The regulatory direction is moving toward provable governance, not informal oversight. The guide points to a market where boards and regulators will increasingly ask for evidence that an organisation can identify each agent, name its owner, and show what it accessed. That shifts the identity conversation from policy language to proof. For practitioners, the important question is whether the current stack can produce evidence on demand, not whether it can describe a future target state.
From our research library:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
AI agent visibility will become a baseline governance requirement, not a niche control. Organisations that cannot identify which agents exist, who owns them and what they can reach will struggle to answer board and audit questions. The operating model is moving toward evidence-based oversight, where the existence of an agent is not enough unless the enterprise can prove its approved purpose and current scope.
Intent drift is the operational signal teams need to watch. When an agent starts touching systems beyond its original remit, the control failure is not only in authorisation. It shows that the governance model is still assuming human-paced change and manual review. Teams should watch for scope expansion, ownership churn and unexplained access to sensitive systems as early signs that the governance model is out of date.
For practitioners
- Build a complete AI agent inventory Track every agent that can reach enterprise systems, including business-built agents, SaaS-activated agents and agents created outside central IT. See the Agentic AI Identity Guide.
- Assign named human ownership Require each agent to have a current accountable owner who can approve changes, attest purpose and answer for the agent's actions.
- Separate approved access from live behaviour Review whether the actions an agent takes still match its declared purpose, not just whether the original access request was approved.
- Tie spend back to the agent record Map token use and operational cost to the specific agent and owner so governance, finance and security teams can investigate anomalies together.
- Treat agent deployment as a lifecycle event Reassess access and accountability when the builder changes role, leaves the company or no longer owns the workflow the agent supports.
Key takeaways
- Enterprise AI agents create an identity governance problem because they can be deployed outside IT and continue operating without a clear control owner.
- The strongest evidence of scale is that first-pass discovery often reveals far more agents than expected, which means inventory gaps are already material.
- The practical control gap is not just access approval but the ability to tie each agent to ownership, purpose and runtime behaviour.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Maturity Model
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 surface, NIST AI RMF and NIST CSF 2.0 set the technical controls, and EU AI Act defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents here inherit access and operate beyond intended scope, which is an identity and privilege issue. |
| ASI01 — Agent Goal Hijack | The article centers on agents drifting away from their declared purpose while still appearing legitimate. | |
| ASI08 — Cascading Failures | Multiple unmanaged agents can amplify governance failures across systems, ownership and cost control. | |
| Recommendation — Map agent access inheritance and scope drift to ASI03 and review where privileges exceed the approved task. Assess whether agent behaviour still matches the approved goal and flag unexplained scope expansion as drift. Contain agent sprawl before one unmanaged deployment creates wider governance and access failures. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Agents continue running after their human builders leave or change roles, leaving access active without lifecycle closure. |
| Recommendation — Revoke or reassign agent ownership when the original human operator leaves, moves or no longer supports the workflow. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The guide is fundamentally about organisational governance, ownership and accountability for AI systems. |
| Recommendation — Establish governance records that identify owners, decision rights and oversight responsibilities for every deployed agent. | ||
| EU AI Act | Art. 9 — Risk Management System | The source explicitly cites documented human ownership and oversight requirements under the EU AI Act. |
| Recommendation — Document and maintain oversight evidence for each high-risk agent and verify the owner can intervene. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about who and what gets access to critical systems and how those permissions are governed. |
| Recommendation — Review agent entitlements against approved business purpose and remove access that no longer matches current need. | ||
Key terms
- AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
- Intent Drift: A mismatch between the original purpose of an agent session and the outcome produced by a later chain of actions. It matters because each step can be individually permitted while the overall behaviour still becomes unsafe or non-compliant.
- Agent Inventory: A governed record of every AI agent in use, including who created it, who can invoke it, what data it can reach, and what actions it can trigger. Without a current inventory, security teams cannot judge whether agent access still matches the business purpose.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
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 November 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org