Notifications
Clear all
Topic starter
02/08/2026 11:47 am
TL;DR: Enterprise AI adoption now spans an average of 54 genAI applications, endpoint AI agent adoption grew 276% in 2025, and 39.7% of sensitive data interactions with AI tools involve data employees should not be sharing, according to Cyberhaven research. The control problem is not policy awareness but enforcement across data flow, agent behaviour, and model exposure.
NHIMG editorial — based on content published by Cyberhaven: Enterprise AI Security Use Cases: What Security Teams Are Solving For
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Cyberhaven's analysis of enterprise AI security use cases →
Enterprise AI security use cases: are your controls keeping up?
Explore further
02/08/2026 12:58 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Enterprise AI security use cases are really data and agent control gaps
