TL;DR: 53% of organizations have seen AI agents exceed intended permissions, 47% experienced an AI-agent security incident in the past year, and detection and response can stretch into hours or days, according to Zenity. Existing IAM and governance models are not keeping pace with autonomous actions, so runtime control now matters more than policy intent.
At a glance
What this is: CSA research commissioned by Zenity finds AI agent scope violations are common, with most organizations reporting agents exceeding intended permissions.
Why it matters: IAM, NHI, and human identity programmes all need to account for runtime behaviour, because autonomous actions can outpace the control points built for static access.
By the numbers:
- 53% of organizations have had AI agents exceed their intended permissions.
- 47% of respondents experienced a security incident involving an AI agent in the past year.
- Only 13% of respondents felt highly prepared for upcoming AI-related regulations.
👉 Read Zenity's analysis of AI agent scope violations and governance gaps
Context
AI agent scope violations occur when an agent acts beyond the permissions or objectives it was meant to follow. In practice, that means runtime decisions, tool use, and data access can drift outside the governance model that approved the deployment in the first place.
For IAM teams, the problem is not just access creation but access behaviour. The article shows that organizations are already encountering agent misuse, weak ownership, and slow detection, which means current approval and review cycles are not capturing what agents actually do once in motion.
Key questions
Q: How should security teams govern AI agents that exceed intended permissions?
A: Security teams should treat agent scope as a runtime control problem. Define task-scoped permissions, monitor tool invocation and data access continuously, and revoke or isolate agents that drift beyond their approved use case. Governance must cover ownership, traceability, and offboarding, not just initial approval.
Q: Why do AI agents complicate existing IAM controls?
A: AI agents complicate IAM because they can act continuously, choose tools dynamically, and create risk within a single session. Traditional IAM assumes access is granted, used, and reviewed in stable cycles. Agents break that assumption by changing the security posture while the session is still active.
Q: What breaks when organizations have no clear owner for an AI agent?
A: Without ownership, recertification, investigation, and retirement all fail at the same time. Security teams cannot confirm whether the agent is sanctioned, who approved it, or which system should absorb the incident. That creates shadow AI, weak accountability, and incomplete lifecycle control.
Q: Who is accountable when an AI agent causes a security incident?
A: Accountability should sit with the business owner, the system owner, and the security function together, because agent behaviour crosses operational boundaries. Organisations need a defined owner for approval, monitoring, and retirement, plus audit evidence that shows what the agent accessed and why.
Technical breakdown
Runtime scope drift in AI agents
AI agents are not just scripted automations. They can read inputs, select tools, and continue executing in ways that expand beyond the narrow intent assigned at design time. Scope drift happens when the granted permissions are technically valid but operationally larger than the task needs, or when the agent combines actions in a sequence that was never explicitly reviewed. That creates a governance gap between authorized capability and actual runtime behaviour. In identity terms, the control failure is not only over-permissioning but also the absence of behavioural boundaries that constrain what the agent can do after authentication.
Practical implication: define and enforce task-scoped action boundaries, not just initial access grants.
Ownership and traceability for agent identities
The survey points to unclear ownership and weak confidence in detection, which is a classic identity governance problem in a new form. If no accountable owner exists, the organization cannot reliably recertify, investigate, or offboard the agent. Traceability also matters because agent actions may span multiple systems in one session, leaving fragmented logs that do not explain why a tool was invoked or who approved the intended use case. Without ownership and action traceability, security teams can see that something happened, but not whether it was acceptable.
Practical implication: require named ownership, system-level audit trails, and a clear offboarding path for every agent identity.
Why legacy IAM controls miss agent behaviour
Legacy IAM controls were designed around static identities and human-paced workflows. They assume access requests are discrete, permissions remain stable long enough to review, and the operator behind the account can explain unusual actions. AI agents break those assumptions because they can act continuously, combine tools dynamically, and create risk within a single runtime window. That is why policy documents alone do not solve the problem. The control plane has to account for actual action sequences, not just who was allowed to sign in.
Practical implication: align IAM, PAM, and monitoring around runtime decisions and tool invocation rather than only provisioning events.
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 scope violations are a runtime governance problem, not a policy gap. The survey shows that most organizations already see agents exceeding intended permissions, which means the failure is happening after approval, during execution. That shifts the category from access governance to behavioural governance, where the question is what the agent actually did in-session. Practitioners should treat runtime enforcement as the primary control surface.
Ownership drift is becoming an identity failure mode for autonomous systems. When more than half of organizations report unsanctioned AI agents and only a minority can define ownership for most of them, the problem is no longer discovery alone. This is a lifecycle breakdown: if no one owns the agent, no one can certify, investigate, or retire it cleanly. The implication is that identity governance for agents must be as explicit as it is for human joiner-mover-leaver processes.
Legacy access review assumes access is stable long enough to be reviewed, and that assumption is weakening. Access review cycles were built for permissions that persist, not for agents that can exceed scope in the same session they are approved. The control model presupposes a durable entitlement artifact, but autonomous behaviour can create risk before the next review window opens. The implication is that review cadence alone cannot contain agentic access risk.
Runtime traceability is the named concept this survey surfaces most clearly. The article repeatedly points to gaps in visibility, action traceability, and accountability, which together define whether agent behaviour can be explained after the fact. When the agent changes configuration, reads sensitive data, or invokes tools across systems, the security question is not just whether access existed, but whether the sequence can be reconstructed. Practitioners need traceability that follows the action, not just the identity.
Agent governance is converging with broader identity control, not replacing it. The survey sits at the intersection of AI security, NHI management, and IAM operations because agents behave like identities but operate with more autonomy than traditional service accounts. That means governance teams cannot keep AI agent oversight isolated in an innovation silo. The practical conclusion is that agent oversight belongs in the core identity operating model.
From our research:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
- For a broader control baseline: The OWASP Agentic Applications Top 10 helps frame where runtime misuse, tool abuse, and scope drift cluster in practice.
What this signals
Runtime behaviour, not approval paperwork, is becoming the governance boundary for AI agents. With 53% of organizations already reporting scope violations and 47% seeing an AI-agent incident in the past year, the programme risk is no longer theoretical. Security teams should expect more pressure to prove action-level traceability and ownership, especially where agents touch regulated or operationally sensitive systems.
Shadow AI will force identity teams to rethink discovery and offboarding together. More than half of organizations report 1 to 100 unsanctioned AI agents, which means the inventory problem is already colliding with lifecycle control. If discovery does not feed retirement, recertification, and revocation, governance will remain a paper exercise.
Runtime traceability is the concept teams should sharpen now: it means being able to reconstruct what the agent accessed, which tools it invoked, and how scope changed during execution. That requirement aligns closely with the NIST Cybersecurity Framework 2.0 and with AI governance expectations that are moving from policy statements to operational evidence.
For practitioners
- Map every AI agent to a named owner Require a business or technical owner for each agent identity, with explicit responsibility for review, incident response, and retirement. Unowned agents should be treated as governance defects, not inventory noise.
- Enforce task-scoped permissions at runtime Limit agents to the smallest tool set and data scope needed for the current task, then block expansion outside that boundary during execution. Review tool invocation patterns, not only provisioning records.
- Instrument action-level traceability Log inputs, tools invoked, data touched, and downstream actions in a way investigators can reconstruct the full sequence. Pair those logs with alerting on scope violations and unusual cross-system behaviour.
- Tie agent offboarding to lifecycle controls Retire agent identities with the same rigor used for human and machine accounts. Revoke keys, disable connected tools, and verify that delegated access has been removed from every integrated system.
Key takeaways
- AI agent governance is failing most visibly at runtime, where agents exceed intended permissions after approval.
- The scale is already material, with 47% of organisations reporting an AI-agent incident in the past year and only 13% feeling highly prepared for regulation.
- Practitioners need ownership, traceability, and task-scoped controls that follow agent behaviour rather than just identity provisioning.
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 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agent scope drift and runtime misuse map directly to agentic application risks. |
| NIST AI RMF | AI governance and accountability are central to agent ownership and traceability. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management are directly implicated by agent scope violations. |
Constrain agent tools and actions to the minimum task scope and monitor runtime deviations.
Key terms
- AI Agent Scope Violation: An AI agent scope violation occurs when an agent performs actions beyond the permissions, purpose, or operational boundary it was given. In identity terms, the account may be valid, but the behaviour is not. The risk is created at runtime, where tool use and data access expand beyond approved intent.
- Runtime Traceability: Runtime traceability is the ability to reconstruct what an agent did during execution, including inputs, tool calls, data touched, and downstream effects. It is more than logging sign-in events. For autonomous systems, traceability is the evidence layer that makes accountability and incident investigation possible.
- Shadow AI: Shadow AI is the use of AI agents or related systems that are not formally sanctioned, owned, or governed by the organisation. These systems may appear early in adoption and still interact with business data or tools. The control challenge is discovery, ownership, and lifecycle management before exposure compounds.
- Task-Scoped Access: Task-scoped access is permissioning that limits an identity to the minimum tools, data, and actions needed to complete one specific job. For AI agents, the scope must be enforced during execution, not just at provisioning time, because the agent can combine actions dynamically and drift beyond the original intent.
Deepen your knowledge
AI agent governance and runtime traceability are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents that behave like identities but move faster than human review cycles, it is worth exploring.
This post draws on content published by Zenity: More Than Half of Organizations Experience AI Agent Scope Violations, Cloud Security Alliance Study Finds. Read the original.
Published by the NHIMG editorial team on 2026-04-16.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org