Notifications
Clear all
Topic starter
18/08/2026 2:09 pm
TL;DR: AI privacy risk now appears at the prompt, browser, endpoint, SaaS integration, and MCP layer, because employees and agents can move PII, credentials, and confidential data into AI tools before vendor policies ever apply, according to Strac. The real control point is detection and redaction before data reaches the model, since policy alone does not stop exposure.
NHIMG editorial — based on content published by Strac: AI Data Privacy: What Every AI Tool Collects, Keeps & Trains On (2026)
Questions worth separating out
Q: How should security teams stop sensitive data from being uploaded into public AI tools?
A: Security teams should enforce endpoint controls that block sensitive files and clipboard content before they reach public AI tools.
Q: Why do AI agents create new data privacy risks?
A: AI agents can move data across tools and systems without a fixed human checkpoint, so they widen the number of places where sensitive information can be copied, transformed, or retained.
Q: What do organisations get wrong about enterprise AI privacy settings?
A: They assume vendor privacy tiers solve the problem, but those settings do not stop an employee from pasting sensitive information into an approved tool.
Practitioner guidance
- Deploy pre-model redaction at every AI ingress point Inspect prompts, uploads, browser flows, endpoint copy-paste, and API submissions before content reaches the model so sensitive data is masked or blocked at source.
- Classify MCP-connected tools as governed data pathways Map which AI agents can reach which tools and data sources, then apply explicit approval, logging, and inspection to each MCP connection.
- Extend DLP policy to shadow AI discovery Find unsanctioned AI tools in the estate, then apply controls that stop PII, credentials, and regulated data from leaving through those services.
What's in the full article
Strac's full article covers the operational detail this post intentionally leaves for the source:
- Per-tool privacy behaviour across ChatGPT, Perplexity, Gemini, Copilot, Cursor, and Claude, including where training defaults differ.
- The four AI data surfaces Strac maps in practice: browser, endpoint, MCP, and shadow AI discovery.
- Examples of DLP, redaction, masking, and proxy enforcement before data reaches an AI model.
- Implementation detail for integrating AI-facing controls into SaaS and browser workflows.
👉 Read Strac's analysis of AI data privacy across prompts, agents, and MCP connections →
AI privacy controls across prompts, agents and MCP connections?
Explore further
18/08/2026 3:02 pm
AI privacy has become a governed data-exchange problem, not a model-setting problem. The article correctly shifts attention from vendor privacy promises to the actual data paths employees and agents use. That matters because the control boundary is now the prompt, the browser, the endpoint, and the MCP connection, not just the AI service itself. For practitioners, the implication is clear: privacy governance must move upstream into the access path.
A question worth separating out:
Q: Who is accountable when AI-driven automation touches sensitive personal data?
A: The organisation remains accountable, even when access is executed by workloads, service accounts, or automated workflows. Governance must cover the identity behind the action, the data touched, and the evidence produced. If automation can access personal data, it must sit inside the same access and audit model as human users.
👉 Read our full editorial: AI privacy is a data security problem, not just a policy problem
