TL;DR: AI governance breaks when policy exists without data-layer enforcement, according to Cyberhaven’s analysis of enterprise genAI use, AI-native DLP, DSPM, and data lineage. The practical problem is not drafting acceptable-use rules but proving, monitoring, and enforcing them across prompts, agents, and data flows.
At a glance
What this is: Cyberhaven argues that AI governance breaks down when organisations rely on policy without data-layer enforcement across genAI tools, agents, and shared data flows.
Why it matters: For IAM, NHI, and security teams, the lesson is that AI governance depends on controlling what data reaches which tools, not just on publishing acceptable-use rules.
Context
AI governance is the combination of policy, controls, and monitoring used to decide who can use AI systems, what data they can touch, and how that use is recorded. The article’s core point is that written policy alone does not stop employees from pasting sensitive information into genAI tools, agent workflows, or unsanctioned accounts.
The governance gap matters because AI use now spans endpoints, browsers, SaaS tools, and delegated workflows that behave more like non-human identities than traditional user sessions. That creates a direct overlap with identity security, data security, and NHI governance, especially where AI agents can move data or call tools without a human in the loop at each step.
Key questions
Q: How should organisations govern AI usage when employees use unapproved tools?
A: Organisations should start with visibility, not enforcement. If teams cannot see which apps, agents, or workflows are being used, they cannot assess data exposure or apply meaningful controls. Once usage is mapped, policy can shift from blanket bans to context-based decisions that reflect sensitivity, role, and business purpose.
Q: Why do AI policies need both governance and technical enforcement?
A: Because governance defines intent while technical enforcement controls behaviour. Without both, organisations can approve a policy, yet still fail to restrict tool access, monitor use, or stop sensitive data from flowing into unapproved AI services.
Q: What signals show that an AI governance programme is not working?
A: Warning signs include disconnected models built by different teams, repeated disputes over data ownership, inconsistent approvals and outputs that cannot be explained to stakeholders. If the organisation cannot trace which data supported a decision or who approved the model, governance is already failing at the operating level.
Q: What is the difference between AI agent visibility and AI agent governance?
A: Visibility tells you that an agent exists. Governance tells you who owns it, what it can access, whether that access still makes sense, and how it will be retired. A team can have strong dashboards and still lack control if ownership, policy, and decommissioning are missing.
Technical breakdown
Why policy-only AI governance fails
Policy-only governance breaks because it assumes behaviour can be controlled through documentation and after-the-fact review. In practice, AI usage happens at the endpoint and browser, where users paste prompts, upload files, or invoke tools outside sanctioned routes. Without enforcement at the data layer, the organisation can detect use, but not determine whether the content was sensitive, whether the tool was approved, or whether the interaction violated policy. That leaves governance with no reliable control point.
Practical implication: Move enforcement to the point where data enters AI tools, not only to policy sign-off or awareness training.
How DSPM and AI-native DLP operationalise governance
DSPM discovers and classifies sensitive data so the control plane knows what is at risk before AI access is granted or expanded. AI-native DLP then uses that context to inspect prompts, pasted text, uploads, and agent interactions in real time, applying graduated actions rather than a blanket allow-or-block response. Data lineage completes the picture by preserving evidence of where the data came from and how it moved through AI workflows. Together, they convert governance from policy intent into traceable enforcement.
Practical implication: Tie classification, inspection, and lineage together so every AI interaction is evaluated against current data sensitivity.
Why AI agents create a governance gap
AI agents change the problem because they can request data, transform it, and write outputs across systems with less visible human interaction than a conventional user session. That makes traditional approval and audit models weaker, because the risky event is often the data movement itself, not the final output. If an agent can read a contract, summarise it, and place that summary into another system, the organisation needs controls that follow the data across each step of the workflow.
Practical implication: Treat agent workflows as governed data paths and require monitoring that tracks tool use, context, and downstream propagation.
Threat narrative
Attacker objective: The objective is not necessarily classic intrusion, but uncontrolled exposure and reuse of sensitive enterprise data through AI interactions that policy alone cannot stop.
- Entry occurs when employees use a genAI tool, agent workflow, or unsanctioned account to move sensitive content outside approved channels.
- Credential or policy boundaries are then bypassed because the organisation can see the connection but not enforce data handling at the point of use.
- Impact follows when confidential material, including customer contracts or other sensitive data, is exposed to AI systems without a governable audit trail.
Breaches seen in the wild
- SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
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
AI governance debt: organisations are accumulating governance debt whenever policy, classification, and enforcement are built as separate functions. A policy that cannot see prompts, pasted data, or agent traffic does not govern behaviour, it merely records intent. The practical conclusion is that AI governance must be designed as an enforcement system, not a documentation exercise.
Data-layer enforcement is now the control boundary: in AI environments, the decisive question is not whether a tool is approved, but whether the data entering it is classified, monitored, and blocked when necessary. This is where AI governance intersects directly with identity and NHI security, because agent workflows act with delegated authority and can move data in ways a human reviewer will not see in time. Practitioners should treat the data path as the control surface.
AI visibility is not AI governance: logs, inventory, and usage reports tell teams that AI is present, but they do not prove that sensitive data stayed within policy. Governance only becomes auditable when the organisation can show what was sent, to which tool, under what classification, and what control action followed. That shifts the centre of gravity from discovery to enforcement, and from occasional review to continuous control.
Agentic workflows expose the weakest assumption in current governance models: many programmes still assume a user is always the last accountable actor in the chain. AI agents break that assumption by transforming, routing, and writing data across systems as operational intermediaries. Practitioners need governance models that follow delegated execution, not just human intent, or the control framework will miss the highest-risk movements.
Policy without telemetry produces no defensible audit trail: governance, compliance, and incident response all depend on evidence. When data lineage is absent, the organisation cannot prove whether sensitive content reached an AI system, whether the tool was sanctioned, or whether a response was proportionate. That makes lineage, classification, and DLP part of the same governance fabric, not separate projects.
From our research library:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Security Guide
What this signals
AI governance debt: many programmes now have policy language faster than they have enforcement. That gap will keep widening unless security teams tie discovery, classification, and blocking controls to the actual paths data takes through genAI tools and agent workflows.
The operational question is no longer whether employees will use AI, but whether the organisation can prove what data reached those systems and what happened next. That puts AI-native DLP, DSPM, and lineage into the same control conversation as IAM and NHI governance.
AI decision-making is shifting downward: 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey. For practitioners, that means governance must be embedded where data moves, not delegated to policy owners alone.
For practitioners
- Enforce AI policy at the data layer Block or warn on sensitive prompts, uploads, and pasted content based on live classification rather than policy documents alone.
- Inventory sanctioned and unsanctioned AI use Identify which endpoints, browsers, and accounts are reaching genAI tools, including personal accounts and agent-driven workflows.
- Connect DSPM to AI enforcement Use data discovery and classification to decide which data types can be exposed to AI systems, and update that posture continuously as permissions change.
- Preserve lineage for AI interactions Trace high-risk data from origin through prompts, summaries, agent actions, and downstream writes so investigations can reconstruct exposure precisely.
Key takeaways
- AI governance breaks when policy exists without enforcement at the data layer, because users can still move sensitive content into genAI tools and agent workflows.
- The control gap is operational, not theoretical: visibility alone cannot prove what data was exposed, where it went, or whether a policy was actually enforced.
- Teams need classification, inspection, and lineage working together so AI usage can be governed at the point of data movement, not only after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article centres on AI governance structures and accountability gaps. |
| MANAGE — AI Risk Management | The core issue is operational control over AI data handling risk. | |
| Recommendation — Establish governance that ties AI policy to enforceable controls, monitoring, and accountability. Manage AI data exposure with continuous monitoring and response controls at the point of use. | ||
| ISO/IEC 42001:2023 | AI Management System | The article maps directly to organisational AI governance and control implementation. |
| Recommendation — Build an AI management system that turns policy into monitored and auditable enforcement. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | The article is about protecting sensitive data across AI handling and movement. |
| DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | Continuous monitoring is required to detect unsanctioned AI use and risky data flows. | |
| Recommendation — Protect sensitive data before it reaches AI systems and enforce handling restrictions continuously. Monitor AI interaction paths for policy violations and anomalous data movement. | ||
Key terms
- AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
- AI-native DLP: AI-native DLP is data loss prevention designed to understand how AI systems create, move, and expose sensitive information. It inspects prompts, model outputs, embeddings, agent actions, and connected tools to detect leakage, misuse, or policy violations. It applies controls across AI workflows, not only traditional files, email, or endpoints.
- 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.
- DSPM: Data Security Posture Management is the discipline of finding, classifying, and protecting sensitive data across storage systems and workflows. In AI environments, DSPM helps teams understand what data exists, where it lives, and whether AI systems can access it appropriately.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and identity lifecycle control. It helps security practitioners connect delegated access, AI agents, and machine identity risk to a practical governance model.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org