Enterprise AI security use cases are really data and agent control gaps

At a glance

What this is: Cyberhaven argues that enterprise AI security use cases split into three control gaps: data entering AI tools, agent activity across systems, and sensitive data used in models.

Why it matters: IAM, NHI, and AI security teams need to govern both who and what is acting in AI workflows, because policy without enforcement leaves data exposure and autonomous action unchecked.

By the numbers:

• The average organisation now uses 54 generative AI applications, according to Cyberhaven.
• Endpoint AI agent adoption grew 276% in 2025, according to Cyberhaven.
• 39.7% of sensitive data interactions with AI tools involve data employees should not be sharing, according to Cyberhaven.

Context

Enterprise AI security is no longer just a question of acceptable use policy. The core issue is whether organisations can enforce controls over data, agent behaviour, and model exposure once AI is embedded in everyday work.

That matters to IAM and NHI programmes because AI tools, AI agents, and AI pipelines all create new identity and access decisions. When control fails at the session, workflow, or data layer, governance moves from oversight to blind trust.

Key questions

Q: What happens when sensitive data is entered into a public AI tool without strong controls?

A: Sensitive data can be exposed beyond the organisation’s intended boundary, creating risk of identity theft, fraud, reputational damage, and legal liability. If the tool logs or retains prompts, the exposure may persist even after the user deletes local history. The wider the data reach, the harder it becomes to contain the impact of one mistaken submission.

Q: Why do AI agents create more governance risk than ordinary integrations?

A: AI agents can connect quickly, run continuously, and accumulate broad permissions across multiple services. That combination makes ownership blur and scope drift more likely, so the real risk is not the tool itself but the uncontrolled access path it creates across enterprise systems.

Q: How can organisations tell whether an AI coding model is safe enough to use?

A: Use model-specific measures rather than generic vendor claims. Track pass rates by vulnerability class, compare reasoning and non-reasoning variants, and test the model on the languages and application patterns your teams actually ship. A model is only fit for use if it improves security outcomes in your environment without reducing review discipline.

Q: What should security teams do first when shadow AI tools appear in a client environment?

A: The first step is to identify where unauthorized tools are actually being used. Regular IT audits and application discovery help teams locate unsanctioned AI services, assess what data is being shared, and decide whether to block, replace, or formally approve each application. Without visibility, policy enforcement becomes guesswork and the client cannot control data flow.

Technical breakdown

Why browser-based AI data loss bypasses legacy DLP

Legacy DLP was designed around files, email, and network flows, so it often misses text pasted into browser-based genAI sessions. In that pattern, the control point is no longer the file boundary but the data lineage boundary, meaning security teams need to know what data is sensitive before it reaches the AI tool and how it moves after that point. This is not a policy problem; it is an enforcement problem at the data layer.

Practical implication: classify sensitive content before AI session entry and enforce controls at the data layer, not only at the network edge.

How agentic AI changes access control assumptions

Agentic AI is different from chat-style AI because it can interpret instructions, chain actions, call APIs, query databases, and continue across multiple systems without human review at each step. That creates a governance problem for entitlement scope and runtime oversight, especially when the agent can operate with legitimate credentials. The identity question is not just whether an agent is authenticated, but whether its permissions are narrow enough for machine-speed execution and traceable across the workflow.

Practical implication: govern AI agents as privileged actors with tightly scoped access, auditable actions, and explicit runtime boundaries.

Why AI model security starts with data provenance

Model security is not limited to prompt filtering or output moderation. If sensitive or regulated data is used in fine-tuning, RAG pipelines, or internal model development, the model can later surface that data in ways the organisation did not intend. That makes data provenance a control requirement, not a documentation exercise. Security teams need visibility into what feeds the model, where that data came from, and whether it was appropriate to use in the first place.

Practical implication: track provenance for training and retrieval data before deployment, because post-deployment controls cannot reliably undo contaminated inputs.

Threat narrative

Attacker objective: The objective is to move, reuse, or expose sensitive enterprise data through AI workflows in ways that bypass existing controls and remain difficult to audit.

1. Entry occurs when employees paste or upload sensitive data into genAI tools or when agents begin operating with legitimate enterprise credentials.
2. Credential or authority is then exercised through browser sessions, API calls, database queries, and multi-step workflows that legacy controls cannot fully observe.
3. Impact appears as sensitive data exposure, uncontrolled agent actions, or model contamination that can surface in outputs and downstream business processes.

Breaches seen in the wild

• Cyberhaven Chrome extension breach 2024: A phished OAuth consent gave attackers Chrome Web Store publishing rights and a malicious Cyberhaven extension update reached about 400,000 users.

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

Enterprise AI governance has become a control problem, not an awareness problem. Most organisations already have acceptable use language, but policies do not stop pasted contracts, source code, or regulated data from entering AI systems. The gap is enforcement across the data path, which means security teams must treat AI sessions as governed data movement, not informal productivity activity. The practitioner conclusion is simple: if the control cannot see the data flow, the policy cannot hold.

Agentic AI creates a privilege boundary problem that conventional review processes cannot absorb. Agents can chain actions across systems fast enough that human review arrives after the damage window has opened. That makes runtime scope, traceability, and permission boundaries more important than static approval workflows. For IAM and PAM teams, the relevant question is not whether the agent is sanctioned, but whether its authority is bounded tightly enough to survive machine-speed execution.

AI model security now depends on data lineage and provenance discipline. Fine-tuning and RAG expand the blast radius of whatever enters the model-building path, including regulated or otherwise inappropriate data. Once data has been embedded, indexed, or learned into a model workflow, downstream exposure becomes much harder to reverse than a traditional access event. Practitioners should therefore govern model inputs as a security boundary in their own right.

Shadow AI and shadow agents expose a governance blind spot that identity teams cannot ignore. The article’s real warning is that security teams may know AI is present without knowing which tools, which agents, or which data paths are actually active. That is an identity and access governance issue as much as a data issue, because unmanaged AI creates unsupervised runtime authority. The conclusion for practitioners is to inventory AI actors and their data access before attempting broader policy enforcement.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Guide

What this signals

Data lineage is becoming the practical control plane for enterprise AI. Security teams cannot govern pasted content, retrieved documents, and downstream model exposure with file-centric controls alone, because AI workflows collapse the old boundaries between endpoint action and data movement. The issue is not whether employees use AI, but whether governance can still see the data once it enters those systems.

Shadow AI and shadow agents are now an identity inventory problem as much as a data problem. If organisations do not know which AI actors are active, they cannot assign authority, verify scope, or revoke access with any confidence. The governance shift is toward discovering AI actors first, then enforcing least-privilege data access around them.

Agentic AI security will increasingly depend on task-scoped authority rather than user-scoped trust. As agents take on more operational work, control models built for human sessions will lose fidelity. Teams should expect policy to move from permissive oversight to explicit runtime constraints and auditable execution paths.

For practitioners

• Map AI data flows to sensitive classifications Track what data enters genAI tools, where it originates, and whether it should be allowed in browser-based sessions at all.
• Scope agent permissions to task-level need Treat agents as privileged execution paths and restrict access to only the systems and data categories required for the workflow.
• Instrument model pipelines for provenance Record what data is used in fine-tuning, retrieval, and internal model development so exposed inputs can be traced before deployment.
• Inventory shadow AI and shadow agents Build a current register of sanctioned and unsanctioned AI tools, agent workflows, and the business owners responsible for them.

Key takeaways

• Enterprise AI security breaks down when organisations can see AI usage but cannot enforce controls over the data entering tools, the actions agents take, or the inputs feeding models.
• The article points to three distinct risk surfaces, and the control model for each one is different enough that a single policy approach will not cover them.
• Practitioners should treat AI data flow, AI agent authority, and model provenance as separate governance problems that need separate controls.

Key terms

• 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 AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• Model Provenance: Model provenance is the evidence chain showing where an AI artefact came from, how it was modified, and whether the version in use is the one that was approved. For AI security teams, provenance is the control that turns trust from assumption into verification.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners build the access and lifecycle controls that AI governance programmes depend on.