TL;DR: Enterprise AI now moves sensitive data through chatbots, copilots, IDEs, and autonomous agents, and WitnessAI argues keyword- and regex-based controls cannot reliably govern paraphrased, summarized, or translated content in conversational workflows. The core issue is that AI security must inspect meaning and act at runtime, because static pattern matching cannot contain prompts, responses, or agent actions once processing becomes dynamic.
NHIMG editorial — based on content published by WitnessAI: enterprise AI data security risks and runtime controls
Questions worth separating out
Q: How should security teams protect sensitive data in enterprise AI workflows?
A: Start at runtime, not after the fact.
Q: Why do keyword and regex controls fail for AI data protection?
A: They were built for fixed text patterns, while AI reshapes content continuously.
Q: What breaks when AI agents inherit too much access?
A: The boundary between a conversation and an execution path breaks.
Practitioner guidance
- Map AI interactions by identity and destination Inventory where prompts, responses, and agent tool calls occur across employees, models, apps, and connected systems.
- Replace static pattern checks with runtime policy enforcement Use context-aware controls that can warn, route, tokenize, or block at the moment of interaction.
- Bind AI agent actions to human attribution Require traceability for who initiated an agent workflow, which permissions were inherited, and what tool calls executed.
What's in the full article
WitnessAI's full research covers the operational detail this post intentionally leaves for the source:
- Network-level visibility patterns for employees, models, apps, and agents in live environments
- Tokenization and redaction workflow details for prompts, responses, and downstream model paths
- Intent-based policy examples for warning, routing, allowing, and blocking sensitive interactions
- Audit trail and compliance evidence examples for regulated AI deployments
👉 Read WitnessAI's analysis of enterprise AI data protection and runtime controls →
AI data protection in enterprise AI: why regex controls fall short?
Explore further
Keyword scanning is no longer a sufficient control plane for AI data protection. Conversational systems do not preserve sensitive data in the fixed forms that legacy DLP expects. The same fact can be paraphrased, summarised, translated, or split across interactions, which means the control has to understand intent and context rather than only text patterns. Practitioners should treat static content matching as a narrow detection aid, not a governing model.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 44% of organisations have implemented policies to govern AI agents, even though 92% agree this governance is critical to enterprise security, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who is accountable when AI systems leak sensitive data?
A: Accountability sits with the organisation that defines policy and allows the workflow, even when a model or agent performs the action. Teams need logs that show who initiated the interaction, what policy evaluated it, and what control response occurred. That evidence is what turns AI governance into something compliance can verify.
👉 Read our full editorial: Enterprise AI data protection demands runtime controls, not regex