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

At a glance

What this is: This analysis breaks enterprise AI security into three distinct control problems: data entering AI tools, autonomous agent activity, and sensitive data flowing into models.

Why it matters: It matters to IAM practitioners because AI tools and agents create new identity, access, and data-governance decisions that conventional acceptable use, DLP, and review processes do not fully cover.

By the numbers:

• Enterprise AI adoption is no longer a future problem. The average organization uses 54 generative AI applications, and endpoint AI agent adoption is accelerating, with Cyberhaven research tracking 276% growth in 2025.
• Cyberhaven research found that 39.7% of sensitive data interactions with AI tools involve data employees should not be sharing.
• Frontier organizations now use more than 300 genAI tools, according to Cyberhaven research.
• The 2025 Cisco AI Readiness Index found that only 31% of organizations feel equipped to secure their AI systems, despite 83% planning to deploy agentic AI.

👉 Read Cyberhaven's analysis of enterprise AI security use cases

Context

Enterprise AI security is now a governance problem, not just a tooling problem. Organisations can already see broad genAI adoption, but they still cannot reliably see what sensitive data is entering those tools, what autonomous agents are doing with legitimate access, or whether model pipelines are being trained on data that should never have been exposed in the first place. For IAM and security teams, the primary issue is control scope: who or what can act, what data it can reach, and how those decisions are enforced.

The article’s core point is that AI security breaks into three separate control planes. That is directly relevant to identity and access programmes because AI agents behave like non-human identities in motion, with credentials, permissions, and data reach that can outpace manual review. In practice, this pulls identity governance, secrets management, and data security into the same operating model.

Key questions

Q: How should security teams govern sensitive data used by AI systems?

A: Security teams should treat AI as a data consumer that needs policy boundaries, not just authentication. Classify sensitive data, define which datasets may enter AI workflows, and monitor outputs, logs, and downstream reuse. If governance stops at login, the organisation can approve access while still losing control of the data itself.

Q: Why do AI agents create more IAM risk than ordinary developer tools?

A: AI agents can make independent tool calls, chain actions, and authenticate with non-human identities while executing a task. Ordinary developer tools generally do not decide what to do next. That autonomy increases the chance of unintended access, makes attribution harder, and raises the value of session-level controls that show both intent and outcome.

Q: What breaks when organisations treat AI governance as a separate security program?

A: They usually create a second control plane that cannot keep pace with real usage. That leads to duplicated approvals, weak audit coverage, and unmanaged tool connections outside the identity system of record. AI governance works best when it extends identity infrastructure instead of sitting beside it.

Q: How do organisations reduce model security risk before deployment?

A: They should verify what data feeds the model, where it came from, and whether it is allowed for training or retrieval. If sensitive or regulated data cannot be traced cleanly, the model should not be approved for production use. Provenance, classification, and access control are the minimum conditions for trustworthy deployment.

Technical breakdown

Why browser-based AI use bypasses legacy DLP

Traditional DLP was built around file movement, network inspection, and email flows. Browser-based AI use changes the control surface because users paste or type sensitive content directly into a session, which means the data never takes the path older controls were designed to inspect. The gap is architectural: a policy engine cannot flag data it never observes at the moment of entry. Effective control therefore depends on data lineage, real-time classification, and enforcement at the point where content is created or submitted, not just where it is stored or transmitted.

Practical implication: security teams need data-layer enforcement that can inspect browser and endpoint interactions, not just network traffic.

How autonomous AI agents change access control assumptions

AI agents are different from chat tools because they can interpret instructions, execute steps, call APIs, query systems, and continue working without human review at each action. That creates a machine-speed access problem: the agent may legitimately hold credentials while still moving data in ways the operator never intended. For IAM teams, the challenge is not only who can authenticate, but what an agent can touch, copy, transform, or forward once it is active. That makes least privilege necessary but insufficient unless the programme can also observe data movement during execution.

Practical implication: teams should scope agent permissions to data categories and workflow boundaries, not only to application access.

Why AI model security starts with data provenance

Model security is inseparable from data provenance. When organisations fine-tune models or build retrieval-augmented generation pipelines on internal documents, the risk is not just model misuse but contamination of the training and retrieval surface with sensitive or regulated data. Once that data is embedded into a model or index, it can surface in outputs or retrieval results in ways that are difficult to predict and difficult to reverse. DSPM for AI is therefore about discovery first, then governance: find the data, classify it, trace it, and only then decide whether it should feed a model or RAG pipeline.

Practical implication: model and data teams should require provable lineage before any dataset is approved for training or retrieval.

Threat narrative

Attacker objective: The objective is to move sensitive enterprise data through AI systems in ways the organisation cannot reliably see, classify, or contain.

1. Entry occurs when employees paste contracts, source code, or regulated records into browser-based AI tools that older DLP controls do not inspect.
2. Escalation happens when AI agents inherit legitimate credentials and use them across email, SaaS, cloud storage, and internal databases with no human review at each step.
3. Impact follows when sensitive data is copied into prompts, outputs, embeddings, or downstream workflows, creating disclosure, compliance, and business-risk exposure.

NHI Mgmt Group analysis

AI security now has three separate governance problems, not one. The article is right to split data entering AI tools, autonomous agent behaviour, and model security into distinct control domains. Security programmes fail when they treat all AI risk as an acceptable-use problem because the control response is different in each case. Data governance, IAM, and model risk management must be designed as adjacent controls, not substitutes.

AI agents create a non-human identity governance problem inside existing IAM estates. When an agent can authenticate, call APIs, and move data across systems, it behaves like an NHI with runtime decision-making. That pushes lifecycle ownership, permission scope, and auditability into the same conversation as human access governance. The named concept here is agentic access drift: legitimate machine access expanding beyond the decision boundary humans assumed. Practitioners need controls that bind agent identity to explicit data and task scope.

Legacy DLP is now a boundary problem, not a policy problem. The article shows that users can bypass file-centric controls simply by entering data into browser-based AI sessions. That means the failure is not a lack of rules but a mismatch between the policy model and the user interface where the risk occurs. The governance lesson is that controls must follow the interaction path, especially where AI use happens outside managed software channels.

Model security and secrets governance are converging. Once sensitive data is used in training, retrieval, or prompting, the exposure surface extends into outputs, embeddings, and downstream decisions. That makes secrets management, data classification, and model governance part of the same risk chain. For practitioners, the consequence is clear: if you cannot prove provenance, you cannot prove safety.

What this signals

Agentic access drift: as enterprises scale AI agents, the control problem shifts from occasional misuse to continuous runtime scope creep. IAM, PAM, and data-security teams will need to coordinate around task-scoped permissions, stronger lineage, and machine-readable policy if they want governance to survive operational scale.

Browser-based AI use also reinforces a familiar lesson from identity security: the most damaging exposures are often invisible to the control plane that was built for older workflows. Teams that already struggle to classify secrets, govern service accounts, or track data lineage should expect AI to magnify those weaknesses rather than replace them.

The practical signal for programmes is that AI governance will be measured less by policy coverage and more by enforcement coverage. If the organisation cannot see which tools are in use, what data is moving, and what an agent is allowed to do with it, the programme is relying on intent instead of control.

For practitioners

• Classify AI interactions by control plane Separate employee prompt leakage, agent execution risk, and model-data exposure into different governance tracks so each has its own owner, policy, and evidence trail.
• Bind agent access to task and data scope Treat AI agents as non-human identities with explicit permissions, short-lived credentials, and data-category limits that reflect the specific workflow they are allowed to perform.
• Move enforcement to the data layer Use endpoint and data-lineage controls that can see content entering browser-based AI sessions, then classify and block sensitive material before it reaches unmanaged tools.
• Require provenance before model use Do not approve training, fine-tuning, or retrieval datasets until sensitive-data lineage, access controls, and retention rules are documented and reviewable.

Key takeaways

• Enterprise AI security is really three problems at once: user data leakage into tools, autonomous agent behaviour, and model-data governance.
• Legacy DLP and acceptable-use policies leave a material gap because browser-based AI sessions and machine-speed workflows bypass older control assumptions.
• Practitioners should treat AI agents as governable non-human identities and require data provenance before any model or retrieval pipeline is trusted.

Key terms

• Agentic Scope Drift: Agentic scope drift is the gradual expansion of an AI agent’s effective authority after initial approval. The agent may stay authenticated while its real-world access grows through new integrations, reused tokens, or additional tool registrations, which makes the original consent record incomplete.
• 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.
• AI-specific DSPM: Data Security Posture Management adapted for AI workflows and AI consumers. It identifies what sensitive data exists, where it is used, and whether human or non-human actors are accessing it outside intended scope. For AI programmes, this becomes a visibility and policy enforcement layer, not just a reporting function.
• 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.

What's in the full article

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

• How its endpoint AI agents trace data through multi-step workflows and identify where sensitive content leaves scope.
• The data-lineage approach used to follow content from creation through browser-based AI sessions and downstream destinations.
• Operational examples of how AI-native DSPM classifies data before it is allowed into training or retrieval pipelines.
• The specific control patterns Cyberhaven describes for monitoring shadow AI and agent-to-agent handoffs.

👉 The full Cyberhaven post covers the data-flow controls, agent monitoring, and model-security use cases in more implementation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader access and lifecycle decisions that modern security programmes depend on.