Notifications
Clear all
Topic starter
01/07/2026 2:06 am
TL;DR: AI prompts can now pull sensitive data from payroll files, connected systems, and shadow accounts faster than traditional DLP and CASB were built to inspect, according to WitnessAI. The real failure is not visibility alone but governance that assumes risky data moves only through legacy channels, not copilots, agents, and conversational interfaces.
NHIMG editorial — based on content published by WitnessAI: AI data leakage prevention and why legacy controls miss it
By the numbers:
- Nearly 10% of employee prompts to popular large language models include sensitive information.
Questions worth separating out
Q: How should security teams prevent sensitive data from leaking through AI prompts and copilots?
A: Security teams should combine discovery, intent-aware classification, entitlement review, and runtime enforcement.
Q: Why do AI tools create more data leakage risk than traditional SaaS applications?
A: AI tools create more risk because the sensitive event often happens in natural language, not in a file transfer or database query.
Q: What do security teams get wrong about shadow AI?
A: They treat shadow AI as only an application discovery problem.
Practitioner guidance
- Map AI interactions to identity sources Correlate prompts, responses, and agent actions back to managed identities, including personal accounts and embedded AI features that bypass SSO.
- Classify prompt intent before enforcing policy Use intent-aware controls to distinguish legitimate analysis from disclosure risk, especially in multi-turn conversations where sensitive information appears gradually.
- Review entitlements behind copilots and agents Audit the systems connected to AI tools and reduce over-broad retrieval permissions so agents cannot surface data beyond the user’s role.
What's in the full article
WitnessAI's full research covers the operational detail this post intentionally leaves for the source:
- Network-level discovery examples for sanctioned AI tools, shadow AI accounts, and agentic activity
- Intent-based classification logic for distinguishing legitimate use from disclosure risk in multi-turn sessions
- Tokenization and response rehydration mechanics for sensitive values that must not reach the model
- Policy routing examples that show when to allow, warn, block, or redirect an AI interaction
👉 Read WitnessAI's analysis of AI data leakage and legacy control gaps →
AI data leakage and the governance gap teams are missing?
Explore further
01/07/2026 2:28 am
AI data leakage is now an identity governance problem, not just a content filtering problem. The article shows that sensitive data is escaping through prompts, copilots, and agent workflows that sit outside the perimeter logic of older controls. That changes the control objective from detecting bad content to governing who can expose which data through which AI interface. For IAM and NHI teams, the practical conclusion is that identity context must move into the data protection layer.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
A question worth separating out:
Q: Should organisations block all AI use to reduce leakage risk?
A: No. Blanket blocking often pushes users toward unmanaged tools, which increases shadow AI. A better approach is to allow approved use with policy-based routing, tokenization, and account-level governance. That keeps productivity available while reducing the chance that sensitive data leaves governed boundaries.
👉 Read our full editorial: AI data leakage exposes the limits of legacy DLP and CASB
