AI agent identity risk is outpacing enterprise IAM controls

At a glance

What this is: This is an analysis of why AI agent security in the enterprise is fundamentally an identity and governance problem, with visibility gaps, over-permissioning, and dynamic tool use emerging as the key failure points.

Why it matters: It matters because IAM, PAM, and data governance teams now have to govern software actors that inherit access, act across systems, and create risk faster than conventional review cycles can see them.

By the numbers:

• Gartner projects that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025.
• Only 54% of enterprises fully understand what data their AI agents can access, and just 44% have formal governance policies in place.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Lasso Security's analysis of how to secure AI agents in the enterprise

Context

AI agents are software actors that can plan, call tools, and complete tasks across enterprise systems with limited human oversight. The governance problem is that access is no longer just a static entitlement on a service account or API key. It becomes a runtime decision path that can cross SaaS apps, internal data sources, and external integrations.

Most existing IAM models were built for identities whose permissions are stable enough to assign, review, and certify on a schedule. AI agents break that assumption when they can inherit permissions, expand their tool use, and expose data through dynamic workflows. That is why agent security has to be treated as identity governance, not just application security.

This post uses Lasso Security's analysis as a trigger to examine the operational gap, not the vendor's product. The practical question for practitioners is where current access controls stop being reliable once software begins to act with context, autonomy, and cross-system reach.

Key questions

Q: How should security teams implement least privilege for AI agents?

A: Treat each agent as a distinct software identity with separate read, write, and execute boundaries. Scope permissions to the narrowest task path, map every tool and API the agent can invoke, and avoid inheritance across unrelated SaaS systems. If the agent needs broader access, split the workflow so higher-risk actions require separate controls and explicit logging.

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

A: Traditional automation follows fixed rules, which makes access easier to predict, test, and certify. AI agents can choose actions and tools dynamically, so their effective privilege depends on context, prompts, and retrieved data. That makes them harder to govern with static IAM models and increases the chance of unintended cross-system actions.

Q: What do teams get wrong about monitoring AI agents?

A: Teams often log only final outputs and miss the decision path that produced them. For agents, the risk often starts with unusual prompt content, unexpected tool selection, or access to an unfamiliar data source. Monitoring has to cover the full chain or the control will fail exactly where the misuse began.

Q: How should organisations respond when an AI agent inherits access across multiple systems?

A: They should re-evaluate whether the inheritance model is actually necessary and then break the access into smaller, task-scoped permissions. If the agent can reach documents, tickets, chat, and databases from one identity, the blast radius is too large for effective governance. Cross-system reach should be treated as a privileged design choice, not a default.

Technical breakdown

Why AI agents are not the same as traditional automation

Traditional automation follows predefined rules, so security teams can test the path, predict the outcome, and constrain the blast radius. AI agents behave differently because they use model reasoning to choose actions, retrieve data, and invoke tools dynamically. That makes their security boundary depend on context, prompt content, and tool access rather than a fixed workflow. In practice, the same agent can behave safely in one session and dangerously in the next if its inputs, sources, or permissions change. The core technical risk is not only what the agent can do, but that the decision path is not fully knowable in advance.

Practical implication: inventory agents separately from scripted automation and treat dynamic tool use as a runtime security control problem.

How agent permissions expand across SaaS, APIs, and data sources

Enterprise agents often inherit access through OAuth, service accounts, or delegated permissions, then reuse that access across multiple tools. When an agent can read documents, update tickets, send messages, and query databases, it effectively becomes a bridge between systems. If scopes are broad, a single compromised prompt or poisoned input can drive unintended actions across the chain. This is not the same as a single API being exposed. It is the accumulation of cross-system privilege into one software actor that can move laterally through legitimate integrations.

Practical implication: map every connected tool and scope, then segment write access, data access, and action authority instead of bundling them together.

Why visibility and behavioural monitoring matter for agent governance

AI agents are hard to govern when security teams cannot see prompts, tool calls, retrieved data, and resulting actions in one audit trail. Logging only the final output misses the path that produced it, which is where misuse often begins. Behavioural monitoring matters because agents can drift from intended use without crossing a traditional threshold like malware detection or credential theft. The important signal is not just what data left the environment, but whether the agent invoked an unexpected tool, queried an unusual source, or completed a workflow outside its normal task boundary.

Practical implication: instrument prompts, tool invocations, and outputs together so investigation and policy enforcement cover the full agent workflow.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Dynamic tool use has created an identity governance problem that conventional IAM does not fully model. The article shows that agents do not simply consume access, they select tools, retrieve data, and execute workflows in context. That means the control plane has to account for runtime behaviour, not just assigned entitlements. The practitioner conclusion is that access governance for agents is now a first-class identity domain, not an extension of application security.

Over-permissioned agent access is the clearest failure mode in enterprise deployments. When one software actor can move between CRM, messaging, document, and analytics systems, it becomes a privileged bridge with an oversized blast radius. That creates identity blast radius, a named concept for the way one agent can spread its reach across connected systems through legitimate delegation. The practitioner conclusion is to treat privilege sprawl as the primary risk surface.

Visibility gaps are turning agent governance into an audit and accountability issue as much as a security issue. If organisations cannot trace what an agent accessed and why it did so, they cannot reliably investigate misuse or demonstrate control maturity. This is where NIST AI RMF and NIST CSF style governance functions become relevant alongside NHI controls. The practitioner conclusion is that auditability must be designed into the agent lifecycle from the start.

Access review models built for stable identities do not fit software actors that change behaviour every session. The assumption that a review cycle can certify access after the fact presumes the privilege state persists long enough to be observed. That assumption fails when the actor's tool use and data path are runtime-dependent and may differ from one task to the next. The practitioner conclusion is to rethink what evidence a review can actually certify for agentic access.

Identity blast radius: Agents with inherited permissions can become the shortest path from a single prompt to multi-system impact. That changes the category from isolated misuse to connected-system governance failure. The practitioner conclusion is to scope each agent as if it were a privileged service with unstable behaviour and broad downstream reach.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader identity lens, Top 10 NHI Issues shows how privilege sprawl and visibility gaps repeat across machine identities.

What this signals

Identity blast radius: the next governance question is not whether an agent can act, but how far one identity can move across enterprise systems before control breaks. With 80% of organisations already seeing agent behaviour beyond intended scope, the risk is no longer theoretical. Teams should align agent governance with NIST AI Risk Management Framework controls and identity-led monitoring.

The most exposed programmes will be the ones that treat AI agents as application features instead of software identities. Once an agent inherits permissions from users, service accounts, and OAuth grants, the governance model has to shift toward continuous verification and scoped delegation. That is where identity, data, and security operations need a shared operating model, not separate queues.

The category is moving fast enough that visibility debt will become the dominant control gap. If an organisation cannot trace what an agent accessed, the question is not just whether the data was sensitive, but whether the decision was auditable at all. That is a baseline requirement for both compliance and incident response.

For practitioners

• Inventory every AI agent and connected tool Build a live register of agents, their prompts, data sources, OAuth scopes, APIs, and SaaS integrations. Include developer-side orchestration platforms and any shadow AI instances that can reach enterprise data.
• Separate read, write, and execution authority Do not grant agents bundled access across messaging, documents, ticketing, analytics, and code systems. Split permissions so the agent can only complete the minimum task path required in each environment.
• Log the full agent decision path Capture prompts, retrieved context, tool calls, and final outputs in one trace so investigators can reconstruct how a task unfolded. Use anomaly detection for unexpected tool sequences, unusual data queries, and off-scope actions.
• Review governance policies against agent behaviour drift Reassess whether your current approvals, recertification, and PAM processes assume stable access. If an agent can change its effective privilege during a session, the control evidence has to move from periodic review to continuous verification.

Key takeaways

• AI agents create identity risk because they can select tools, access data, and execute work across systems in ways static IAM models were not built to govern.
• The evidence points to a real operating problem, not a future concern, with most organisations already seeing agent behaviour beyond intended scope.
• The control priority is to reduce blast radius, improve traceability, and redesign governance for software identities that act at runtime.

Key terms

• AI Agent: A software entity that can decide actions, select tools, and execute tasks with limited human intervention. In identity terms, an AI agent is not just an application component. It is a non-human actor whose runtime behaviour can change the effective scope of access.
• Identity Blast Radius: The amount of damage one identity can cause once it is compromised or misused. For AI agents, blast radius is shaped by inherited permissions, tool reach, and cross-system delegation. The wider the blast radius, the less reliable a single access review becomes as a control.
• Prompt Injection: A manipulation technique that alters an AI agent's behaviour by feeding it malicious instructions through prompts, documents, or retrieved content. The attack targets the decision layer, not just the software interface. In agent governance, prompt injection matters because it can trigger unintended actions across connected tools.
• Behavioural Monitoring: The practice of observing how an AI agent actually acts, including prompts, tool calls, and resulting outputs. This is more useful than output-only logging because it captures the path to action. For agent governance, behavioural monitoring is the evidence layer for investigation, policy enforcement, and audit.

Deepen your knowledge

AI agent identity and access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for software identities that can act across enterprise systems, it is worth exploring.

This post draws on content published by Lasso Security: How to Secure AI Agents in the Enterprise: Visibility, Governance & Risk Control. Read the original.