Notifications
Clear all
Topic starter
19/08/2026 3:58 pm
TL;DR: Generative AI data security breaks legacy assumptions because prompts, uploads, context, and outputs now move sensitive data through live workflows that traditional DLP cannot reliably see, according to Strac. The practical shift is from policy-only governance to technical enforcement, where DSPM informs exposure and AI DLP blocks or redacts risk at runtime.
NHIMG editorial — based on content published by Strac: What is Generative AI Data Security
Questions worth separating out
Q: How should security teams control sensitive data in generative AI workflows?
A: They should enforce controls at the point data enters and leaves the model session.
Q: Why do traditional DLP tools fail on ChatGPT prompts?
A: Because traditional DLP is optimised for files, email, and known egress paths.
Q: What breaks when organisations rely on static AI governance policies?
A: Static governance breaks when agents can change behaviour, data paths, or tool usage faster than the policy can be reviewed.
Practitioner guidance
- Implement inline prompt inspection Block or redact sensitive data before prompts are submitted to public or internal AI tools, especially for PII, source code, credentials, and regulated records.
- Map high-risk data with DSPM Use DSPM to identify which SaaS, cloud, and collaboration datasets are most likely to be pulled into AI workflows, then prioritise controls on those paths first.
- Treat AI outputs as governed data Inspect generated responses before users copy them into tickets, chat, code repositories, or downstream systems, and log the decisions for auditability.
What's in the full article
Strac's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how Strac applies browser DLP, endpoint DLP, and MCP DLP across AI surfaces
- Implementation-oriented examples of prompt inspection, redaction, and blocking workflows in live AI sessions
- Details on how the article positions DSPM as the visibility layer for AI data governance decisions
- Practical walkthrough of audit logging and remediation for AI output handling
👉 Read Strac's full guide to generative AI data security and runtime governance →
Generative AI data security - are your controls enforcing at runtime?
Explore further
19/08/2026 4:35 pm
Generative AI data security fails when organisations treat AI as a content layer rather than a runtime control problem. The article shows that prompts, uploads, context windows, and outputs all become new exposure paths once AI is embedded in daily workflows. That means governance must operate inline, not as documentation after the fact. The field should stop assuming that policy alone can constrain AI data movement. Practitioners need enforceable controls that act where the exposure occurs, not where auditors hope it will be visible.
A question worth separating out:
Q: How do IAM and NHI controls affect generative AI data security?
A: Identity controls determine who or what can reach the data that AI tools consume. If a user, service account, or connector has broad access, AI can inherit that exposure inside the session. Teams should reduce permission scope, review connector access, and separate human and non-human pathways where possible. That limits how much sensitive data can enter AI workflows in the first place.
👉 Read our full editorial: Generative AI data security demands runtime governance, not policy alone
