Agentic AI security exposes the visibility gap in enterprise IAM

At a glance

What this is: This is an analysis of agentic AI security and its key finding that existing enterprise tools have poor visibility into what AI agents do on behalf of users.

Why it matters: It matters because IAM, IGA, PAM, and security teams must govern agent actions as delegated access, not as isolated AI prompts or ordinary user activity.

By the numbers:

• 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%).
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Cyberhaven's analysis of agentic AI security visibility and controls

Context

Agentic AI security is about governing software entities that act on behalf of people, not just filtering prompts sent to a model. In this article, the primary issue is visibility: agents can inherit user permissions, move across files, APIs, databases, and SaaS tools, and execute multi-step workflows that existing IAM, DLP, EDR, and insider-risk models do not reliably see.

The core identity problem is that the enterprise has delegated access to an actor whose runtime behaviour is harder to predict than a human user and faster than a manual review cycle. That makes agentic AI governance a direct extension of identity security, because the access path is still identity-led even when the action path is automated and multi-step.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents increase risk in SaaS environments?

A: AI agents increase risk because they can operate through existing application permissions and continue using them as tasks change. That turns delegated access into a broader governance problem, especially when the permissions were never reviewed for non-human use. The result is a larger blast radius from the same underlying grant.

Q: What breaks when existing DLP and EDR tools are used to monitor AI agents?

A: Those tools break at the point where agent behaviour becomes sequential and contextual rather than single-event based. DLP may see one transfer, and EDR may see one process, but neither understands the full conversation thread, tool chain, or data provenance needed to judge the actual risk.

Q: Who should be accountable for AI agent security incidents?

A: Accountability should sit with the team that owns the agent's business function and permission model, not with a single security tool owner. If the organisation cannot name who approved the agent's scope, who can revoke it, and who reviews runtime exceptions, the governance model is incomplete.

Technical breakdown

Why AI agent identity behaves differently from ordinary user access

AI agents are not just applications with APIs. They operate with the permissions of the user who deployed them, then use those permissions to read, write, query, and chain actions across systems. That means the effective identity is delegated, context-rich, and often broader than the human operator would have used manually. The security challenge is not simple authentication. It is the mismatch between human-paced governance and machine-paced execution across multiple tools and data sources.

Practical implication: treat each agent as a governed delegated identity with explicit scope, not as an extension of the user session.

Why existing monitoring tools miss agentic workflows

Traditional EDR, SASE, DLP, and insider-risk tooling were built around events that map cleanly to a person or a process. Agentic workflows break that assumption because the signal is spread across multiple tool calls, conversation turns, and data movements. A single API call may look harmless, but the risk emerges from the sequence, context, and provenance of what the agent accessed and where it sent it next. Without that sequence, defenders see fragments instead of behaviour.

Practical implication: instrument the full execution path, including tool invocations and data lineage, rather than relying on point-in-time alerts.

How data lineage changes agent governance

Data lineage turns agent activity from an opaque action stream into an investigable chain. If a file is accessed, transformed, and written elsewhere, lineage can show what the data was, where it originated, and how it moved through the environment. For agentic AI, that matters because security teams need to know whether the agent handled corporate data, personal data, or sensitive content, and whether the output crossed an approved boundary. Lineage is the bridge between AI monitoring and identity governance.

Practical implication: require lineage-aware controls so that every agent action can be tied back to source data, sensitivity, and destination.

Threat narrative

Attacker objective: The attacker wants to convert delegated agent access into rapid, low-visibility data movement and credential exposure that bypasses ordinary user-focused controls.

1. Entry occurs when a user installs or connects an AI agent, IDE assistant, or MCP-linked workflow using the permissions already attached to that user or system account.
2. Escalation happens when the agent is permitted to read files, query databases, call APIs, or chain tool actions beyond what a human reviewer would approve in real time.
3. Impact follows when the agent moves sensitive data across multiple systems, exposes credentials, or sends data to an unapproved endpoint without a human noticing the full sequence.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Delegated agent identity is now a first-class governance object. The article makes clear that AI agents inherit permissions from the user who deploys them, but they exercise those permissions in a different behavioural pattern from either humans or conventional service accounts. That means the control question is no longer just who authenticated, but what delegated actor executed which tool calls against which data sources. IAM and IGA programmes that do not model agents as a distinct governed identity type will miss the actual access path.

Identity controls built for human decision cadence do not map cleanly to agentic execution. Existing monitoring, DLP, and insider-risk models assume a person can be observed, interrupted, and reviewed at manageable checkpoints. Agentic workflows compress those checkpoints into a single session with multiple tool calls, which creates a runtime governance gap. The practical consequence is that policy enforcement must move from endpoint-only interpretation to sequence-aware control of delegated access.

Runtime observability is the missing control plane for agentic AI. Cyberhaven's framing is strongest where it separates discovery from observability and enforcement. Discovery tells you the agent exists, observability tells you what it did, and controls stop high-risk actions before the output leaves the boundary. The important takeaway for practitioners is that agent governance fails when any one of those three layers is absent, because the risk is sequential rather than static.

Data lineage is becoming the defining concept for agent security. The article points to a named problem that deserves its own label: agentic data lineage gap: security teams can often see that an agent acted, but not where the data came from, how it was transformed, or where it was sent next. That gap matters because agent risk is not just access, it is movement. Practitioners need to understand that without lineage, every detection is incomplete.

Shadow agents are the same governance problem as shadow IT, but faster and more damaging. Unapproved local agents, personal account connections, and unsanctioned MCP servers create invisible delegated access paths that sit outside formal review processes. The article shows that the issue is not merely discovery debt. It is a lifecycle failure, because these actors can appear, expand access, and persist without being captured in normal control cycles. Security teams need to treat unsanctioned agents as unmanaged identities, not as loose software.

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, according to AI Agents: The New Attack Surface report.
• For a broader identity lens, OWASP Agentic Applications Top 10 helps map agent behaviour to runtime risk, while the same governance gap should be evaluated against the NIST AI Risk Management Framework.

What this signals

Agentic data lineage gap: the moment an AI agent can read, transform, and transmit data across multiple systems, the organisation needs a control model that follows the data rather than the application. With 80% of organisations already reporting AI agents acting beyond intended scope, per the AI Agents: The New Attack Surface report, the governance issue is structural, not isolated.

The operational signal is simple: if you cannot reconstruct what an agent accessed, what tools it invoked, and where the output went next, you do not have agent governance. That is why the best programmes will converge on lineage-aware monitoring, explicit delegated ownership, and policy controls that can act during the session, not after it.

As agent usage expands, teams should align their controls to the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 rather than trying to stretch human DLP and insider-risk models into a problem they were not built for.

For practitioners

• Inventory every agent as a delegated identity Maintain a continuous inventory of local agents, IDE assistants, SaaS-linked agents, and MCP-connected workflows. Include the user account, data sources, and permissions each agent inherits so that ownership is clear when access expands.
• Instrument agent execution with lineage and sequence context Capture the full tool-call chain, source data, and destination systems for each agent session. Point-in-time logs are not enough when the risk emerges only after several actions have been chained together.
• Apply runtime guardrails to high-risk actions Block, warn, or redact when agents attempt to move sensitive data across unapproved endpoints or access data outside the expected workflow. Keep controls contextual so users can revise actions without forcing blind blanket blocking.
• Review delegated permissions through an agent lens Reassess OAuth, API, and local account permissions that were acceptable for a human but excessive for an autonomous workflow. Remove broad access that an agent can exercise at machine speed without a review checkpoint.
• Treat shadow agents as unmanaged identities Extend discovery to personal devices, hackathon-built connectors, and unsanctioned automation that can act on corporate data. If the agent is not in the inventory, it should not be considered governed.

Key takeaways

• AI agents are delegated identities, so their access must be governed as runtime behaviour rather than as a static application feature.
• The strongest evidence here is visibility failure: most organisations say agents are already behaving outside intended scope, yet many still cannot audit agent data use.
• Practitioners should move to inventory, lineage, and runtime guardrails that can see and control the full agent execution chain.

Key terms

• Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority — API access, file writes, workflow triggers — the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
• Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.
• Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight — the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.

What's in the full article

Cyberhaven's full blog post covers the operational detail this post intentionally leaves for the source:

• How the visibility layer classifies sanctioned and unsanctioned agents across endpoints, SaaS, and MCP-connected systems
• How observability reconstructs multi-turn agent sessions into a complete execution lifecycle for investigation
• How runtime controls can block, warn, or redact sensitive actions without relying on generic alerting
• How the data lineage foundation links source data, classification, and destination systems across the workflow

👉 Cyberhaven's full post covers the visibility model, execution lifecycle, and runtime control approach in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity governance capability across human and non-human actors, it is worth exploring.