AI agents are already outpacing enterprise security controls

At a glance

What this is: A survey of 445 IT and security professionals shows AI agents are already embedded in enterprise workflows, with shadow agents, scope violations, and slow response times exposing a governance gap.

Why it matters: IAM, PAM, and security teams now have to govern actors that can exceed intended permissions in production, which means current human-centric review and control models are no longer enough.

By the numbers:

• The report is based on 445 IT and security professionals across organizations of varying sizes and industries.

👉 Read Zenity's full report on enterprise AI agents and security readiness

Context

AI agents are software actors that can choose actions, use tools, and execute work inside enterprise systems. The security problem is that many organisations are treating them as another automation layer even though the article shows they are already acting as active identities with their own permission footprints and incident patterns.

That creates an identity governance problem across agentic AI, NHI, and human oversight. The key failure is not simply more access, but access that changes in practice faster than ownership, review, and containment processes can keep up with.

Key questions

Q: How should security teams govern AI agents that can act across multiple systems?

A: Security teams should govern AI agents as active identities with named ownership, bounded action rights, and a documented offboarding path. The critical control is runtime containment, not just provisioning review, because agents can move across tools and workflows faster than periodic access certification can detect drift.

Q: Why do AI agents create more governance risk than standard automation?

A: AI agents create more governance risk because they can choose actions at runtime, use tools dynamically, and continue execution without a human approval gate between steps. Standard automation follows a fixed path, but agentic behaviour can expand scope in ways that static policy was never designed to absorb.

Q: What do security teams get wrong about AI agent scope control?

A: Teams often assume a task description is enough to define privilege. In reality, scope control fails when an agent moves from a narrow informational task into operational action, such as modifying records or sending requests. The fix is not more intent language, but tighter action-level boundaries.

Q: Who is accountable when an unsanctioned AI agent causes an incident?

A: Accountability should sit with the business and technical owner who allowed the agent to connect to enterprise systems, plus the control owners responsible for approval and monitoring. If no owner is named, accountability is already broken and incident response will be slower than it should be.

Technical breakdown

Why AI agent permissions drift in production

AI agents rarely stay inside the narrow task description first assigned to them. In practice, they act across multiple applications, data stores, and workflows, and that means the original authorisation boundary becomes unstable once the agent starts interacting with real business processes. Scope drift happens when an agent performs a related but different action than intended, such as moving from research to action or from retrieval to modification. That is not just a policy miss. It is a behavioural mismatch between static provisioning and runtime execution. The issue is especially sharp where multiple agent platforms exist, each with different telemetry and permission models.

Practical implication: Map every agent to its actual runtime actions, not just its declared use case, and block any action that is not explicitly tied to a governed workflow.

Shadow AI agents and accountability gaps

Shadow AI agents emerge when teams deploy or connect agents without central ownership, visibility, or lifecycle control. This is structurally similar to unmanaged NHI sprawl, but the operational risk is higher because the actor can make decisions at runtime and trigger downstream activity on its own. When no one can clearly answer who owns the agent, who approved it, and who can disable it, incident response slows immediately. The article’s point is not that this is a future concern. It is that unsanctioned agents are already showing up before governance is in place, which means accountability is now part of the attack surface.

Practical implication: Require a named owner, inventory entry, and offboarding path for every AI agent before it is allowed into production.

Why compliance does not equal agent governance

The report shows organisations are leaning on familiar compliance structures such as HIPAA, SOC 2, and the NIST AI Risk Management Framework. Those frameworks help establish accountability, but they were not built around systems that can select tools, alter scope, and act across multiple enterprise services within a single session. That is why organisations can appear compliant while still being operationally exposed. Compliance says controls exist. Governance proves they match the actor’s behaviour. For AI agents, that mismatch is now a primary failure mode.

Practical implication: Treat compliance as a floor, then test whether the control set actually constrains agent behaviour at runtime across every connected system.

Threat narrative

Attacker objective: The objective is to exploit agentic access to carry out unauthorized actions inside trusted enterprise workflows before security teams can contain the activity.

1. Entry occurs when sanctioned or unsanctioned AI agents are connected into enterprise workflows and inherit access to tools, systems, and data.
2. Escalation happens when an agent exceeds intended permissions and performs actions beyond its original task, such as modifying records or issuing requests.
3. Impact follows when incident detection and containment lag far behind the agent’s activity, allowing unauthorized actions to persist across multiple systems.

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 agents are becoming governance subjects before they are governance objects. The article shows organisations are already deploying agents into daily work while visibility, ownership, and response structures remain incomplete. That means the field is no longer debating adoption, but struggling to govern behaviour that is already live. Practitioners should treat agent identity as an active governance domain, not an emerging pilot category.

Scope violations are the named failure mode this report exposes. The article’s examples show agents moving from research to action, or from retrieval to modification, which means the core problem is not just excess access but intent drift at runtime. This is a distinct operational condition because the permission set may be valid at provisioning time yet still fail at execution time. Security teams should recognize scope violation as a category of behavioural control failure, not a rare exception.

Compliance baseline is not runtime control. HIPAA, SOC 2, and the NIST AI Risk Management Framework can help define governance, but they do not guarantee that an AI agent will stay inside its intended task boundary. The report shows a gap between control presence and operational readiness. That gap matters because agentic systems can look compliant while still being poorly contained in production. Practitioners should measure whether controls follow the actor, not just the audit trail.

Shadow AI agents collapse accountability before incident response begins. The article highlights unsanctioned agents appearing before ownership models are established, which means response teams may not know who approved the system or who can revoke it. That is a governance failure, not just a monitoring issue. The implication is straightforward: if identity ownership is unclear, containment will be slow and attribution will be weak.

Runtime AI agent governance needs a different lens from human IAM. Human access review assumes a stable user, a durable privilege set, and a review cycle that can catch anomalies later. AI agents do not behave on that timeline. Once the actor can decide and act continuously, the control problem shifts from certification to live containment. Practitioners should reframe the programme around runtime authorisation, ownership, and behavioural constraint.

From our research:

• 1 in 4 organisations is already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security.
• Our research also shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a familiar visibility failure pattern for unmanaged non-human access.
• For a wider breach context, The 52 NHI breaches Report shows how access sprawl and weak lifecycle control repeatedly turn identity gaps into incidents.

What this signals

The governance signal is clear: AI agents are moving from experimental adjuncts to operational identities, and programmes that still centre periodic review will miss the control point that matters most. Teams need a live ownership model, behavioural telemetry, and a containment path that works before the agent completes its task.

Runtime agent boundary drift: the next control conversation is not whether an agent is approved, but whether its approved action set still matches what it actually does after deployment. That is where identity programmes will increasingly separate paper compliance from real resilience.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market is treating non-human governance as a distinct discipline. The reader takeaway is to align agent controls with zero trust principles and runtime authorisation, not with human access review cadence.

For practitioners

• Inventory every AI agent as a governed identity Create a live register that captures owner, data access, connected tools, approval path, and offboarding condition before production use. Include sanctioned and unsanctioned agents in the same inventory so shadow deployment cannot hide in separate tooling.
• Tie each agent to an approved action boundary Define the exact actions an agent may take and block escalation from read-only to write or from advisory to transactional use unless a separate review approves that change. Validate the boundary against actual workflows, not just design documents.
• Measure scope violations as a control signal Track when an agent performs an action outside its declared task, especially record modification, quote requests, ticket changes, or unplanned tool calls. Treat repeated scope violations as evidence that the permission model does not match runtime behaviour.
• Align incident response to agent ownership Make revocation, isolation, and approval rollback dependent on the named business and technical owner for each agent. If ownership is unclear, the incident playbook should assume containment delay and elevate review immediately.

Key takeaways

• AI agents are already operating inside enterprise workflows, which makes governance a present-tense identity problem rather than a future AI policy exercise.
• The report’s central evidence is scope drift, shadow deployment, and slow containment, which together show why compliance alone does not secure agentic systems.
• Programmes that do not establish ownership, action boundaries, and runtime containment for agents will continue to miss the control point that matters most.

Key terms

• AI Agent Identity: An AI agent identity is the access and accountability wrapper attached to a software actor that can choose actions and use tools inside enterprise systems. Unlike a simple automation account, it may change behaviour at runtime, which means governance must cover ownership, scope, and revocation as live controls.
• Scope Violation: A scope violation occurs when an identity performs an action outside the task or permission boundary it was given. For AI agents, this can happen even when initial access was valid, because the risk emerges from runtime behaviour rather than from provisioning alone.
• Shadow AI Agent: A shadow AI agent is an undiscovered or unmanaged agent operating inside an environment without clear ownership, approval, or lifecycle control. The main risk is not only visibility loss, but the collapse of accountability when incidents occur and no one can quickly identify who can contain the actor.

Deepen your knowledge

AI agent governance and runtime access control 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 can act inside production workflows, it is worth exploring.

This post draws on content published by Zenity: AI Agents Are Already Running the Enterprise. Security Hasn't Caught Up. Read the original.