Notifications
Clear all
Topic starter
02/08/2026 11:22 am
TL;DR: Enterprise LLM deployments are outrunning the controls meant to govern them, with Cyberhaven Labs finding that 39.7% of data shared with AI tools is sensitive and that shadow AI, agent access, and inference risk all create exposure paths legacy DLP often misses, according to Cyberhaven. The practical issue is not model adoption itself but whether identity, access, and data lineage controls can keep pace with how people and agents actually use LLMs.
NHIMG editorial — based on content published by Cyberhaven: Implementing AI Security: Your Enterprise LLM Security Checklist
By the numbers:
- Cyberhaven Labs research found that 39.7% of the data employees share with AI tools is sensitive.
- Endpoint-based AI agents grew 509% in 2025.
Questions worth separating out
Q: How should security teams implement LLM governance without slowing adoption?
A: Start by governing the model’s access path, not just the application wrapper.
Q: Why do LLM applications create governance problems for IAM and security teams?
A: LLM applications create governance problems because they can turn untrusted input into live system behaviour.
Q: What breaks when traditional DLP is used alone for AI security?
A: Traditional DLP misses much of the risk because prompts, browser submissions, and generated outputs do not always look like file transfers.
Practitioner guidance
- Build a continuous AI inventory Track every sanctioned and unsanctioned LLM, browser assistant, plugin, agent, and MCP server.
- Apply least privilege to AI-connected identities Review the permissions granted to API keys, service accounts, and agent credentials used by AI workflows.
- Enforce data controls at the point of use Extend controls beyond file DLP to cover pasted prompts, browser submissions, generated outputs, and agent actions.
What's in the full article
Cyberhaven's full article covers the operational detail this post intentionally leaves for the source:
- The six-part enterprise LLM security checklist with specific audit points for discovery, access, data protection, monitoring, and incident response.
- Detailed guidance on how Cyberhaven maps data lineage across prompts, outputs, and agentic workflows.
- Examples of how the vendor classifies sanctioned, tolerated, and restricted AI tools in practice.
- The article's explanation of how its continuous Data Lineage graph supports enforcement decisions.
👉 Read Cyberhaven's enterprise LLM security checklist for AI governance and data protection →
Enterprise LLM security: are your data controls keeping up?
Explore further
02/08/2026 12:40 pm
Enterprise LLM security is becoming an identity and data lineage problem, not just an AI tooling problem. The article correctly frames prompt, output, and agent activity as distinct control points, which is where many programmes still fail. When access is mediated by humans, service accounts, plugins, and MCP-connected tools, the governance question is who can move data, under what authority, and with what audit trail. That means LLM security has to sit alongside IAM, PAM, and NHI governance, not outside them.
A question worth separating out:
Q: Who is accountable when sensitive data is retained in a third-party AI tool?
A: Accountability sits with the organisation that allowed the data into the tool, even if the provider stores or processes it. Teams need clear ownership for prompt retention, deletion requests, and vendor data processing terms. If the provider cannot prove erasure or lineage, the organisation still carries the compliance and privacy risk.
👉 Read our full editorial: Enterprise LLM security is now a data governance problem
