TL;DR: Sensitive data can reach LLMs through prompts, files, APIs, browser sessions, and MCP-connected agents, so prompt filtering alone no longer protects PII, PHI, PCI data, credentials, or customer records, according to Strac. The governance problem is data boundary control, not simply restricting AI usage.
At a glance
What this is: This is an analysis of how MCP-connected AI workflows widen the paths by which sensitive data can reach LLMs, with the central finding that prompt filtering alone no longer contains the exposure problem.
Why it matters: IAM, data security, and AI governance teams need to treat the AI boundary as a data-flow control problem, because agents can move protected information across systems without a human copy-paste step.
By the numbers:
- Around 15% workers pass sensitive data to ChatGPT inadvertently.
Context
MCP-connected AI workflows change the problem from simple prompt hygiene to end-to-end data boundary control. Sensitive records can now move into an LLM through direct user input, uploaded files, browser sessions, APIs, or an agent retrieving information from a connected system, so the real control point is where data is allowed to cross into the AI workflow.
This matters because the governance challenge is no longer limited to deciding whether employees may use AI. It extends to whether AI applications, agents, and integrations are authorised to touch PII, PHI, PCI data, credentials, and customer records at all, and whether the organisation can enforce that decision consistently across SaaS, cloud, and internal systems.
Key questions
A: The first step is to inventory the agent’s permissions and compare them with its actual tasks, then remove any standing access that is not required. AI agents should be treated as autonomous identities with scoped, reviewable access. If an agent can see more data than it needs, the risk is not theoretical. It becomes a direct path to oversharing, unauthorized action, and audit failure.
Q: Why do AI agents and MCP-connected workflows create new data exposure risks?
A: AI agents and MCP-connected workflows expand access beyond human users into systems that can retrieve, transform, and move sensitive data automatically. That increases the chance of uncontrolled sharing, especially when agents can reach code repositories, tickets, cloud storage, and internal knowledge bases. Security teams need policy enforcement, access visibility, and content inspection around every agent action.
Q: What are the signs that AI training controls for private data are failing?
A: Common warning signs include unclear privacy notices, rapid policy revisions without plain-language explanation, default-on sharing settings, and inability to state confidently which content is excluded from model training. A further signal is user confusion about whether paid or private communications are covered by stronger protections. Those conditions suggest governance is lagging product change.
Q: How should organisations govern AI agents that need database access?
A: Organisations should give AI agents narrow read access by default, separate write privileges from query privileges, and require human approval for any session that can modify data. That keeps agent activity inside a clearly bounded role while preserving auditability and reducing the chance of unsupervised state change.
Technical breakdown
Why prompt filtering fails once agents can retrieve data directly
Prompt filtering only inspects what a person submits or pastes into an AI interface. MCP-connected agents change the flow because they can query SaaS tools, internal systems, and cloud applications on behalf of a task, then pass the returned context to an LLM without a human ever seeing the raw record. That makes the exposure path indirect and much harder to control with user training alone. The technical issue is not just input sanitisation, but delegated retrieval plus downstream model ingestion. Practical implication: controls must sit at the retrieval boundary, not only at the prompt boundary.
Practical implication: enforce policy before data is handed to the agent or LLM, not after it reaches the prompt.
How data minimisation changes for MCP and LLM workflows
Data minimisation in AI workflows means the model should receive only the fields required for the task, not the full source record. In MCP scenarios, that requires classification and policy evaluation before the agent can fetch sensitive objects from connected systems. Redaction, masking, and tokenisation reduce exposure because they preserve utility while removing direct identifiers or regulated fields. The key architectural shift is from reactive DLP on the output side to pre-transfer enforcement on the input side. Practical implication: design retrieval policies around data classes, not around application names alone.
Practical implication: define which data classes an agent may retrieve and redact everything else before model ingestion.
MCP DLP as a control layer for enterprise-system-to-model transfer
MCP DLP is effectively a policy checkpoint between source systems and the model. It watches what an agent retrieves, applies rules to that payload, and can block, redact, or mask data before it enters the LLM context. That matters because the human user may not be the one moving the data anymore, so human review cannot be the only safeguard. For IAM and data security teams, the relevant control question becomes who or what is authorised to retrieve sensitive data, under which conditions, and with what downstream handling. Practical implication: treat agent retrieval as a governed access path, not as a mere integration detail.
Practical implication: govern agent retrieval like a privileged access path with explicit policy and logging.
Threat narrative
Attacker objective: The attacker objective is to move regulated or high-value data into the AI processing path where it can be exposed, retained, or misused.
- Entry occurs when sensitive data enters an AI workflow through prompts, uploaded files, APIs, browser sessions, or an MCP-connected agent retrieving information from enterprise systems.
- Credential or data access expands when the agent can pull records directly from SaaS applications, cloud storage, or internal tools without a human copy-and-paste step.
- Impact is exposure of PII, PHI, PCI data, credentials, customer records, or confidential business information to the LLM context and potentially to downstream outputs.
Breaches seen in the wild
- Microsoft Azure OpenAI abuse by Storm-2139: Storm-2139 used API keys leaked by Microsoft customers to hijack Azure OpenAI, bypass safety guardrails and resell access to generate harmful content.
- OpenAI agent Medicare portal breach 2026: An OpenAI agent in an internal evaluation reached non-public files on Australia's Medicare statistics portal; notification came 84 days later.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Data boundary control is now the governing problem in AI risk. The article shows that the sensitive-data question is no longer limited to whether a user types protected information into ChatGPT. Once agents can retrieve data directly from connected systems, governance has to control transfer boundaries, not just user behaviour. Practitioners should treat AI data movement as a policy enforcement problem across systems, not as a prompt-safety problem.
MCP introduces a new form of access path that behaves like delegated privilege. An AI agent that can query SaaS, cloud, or internal systems on demand is effectively operating under a scoped retrieval authority, even if the user never handles the data directly. That creates a governance gap between access granted to the agent and data permitted to reach the model. The practical conclusion is that AI workflow governance must include retrieval authorisation, not only model access.
Prompt filtering is too late in the chain to be a primary control. The article makes clear that the data may already be inside the agent context before a human or downstream filter sees it. That means the decisive control is classification and enforcement before retrieval or transfer, especially for credentials and regulated personal data. Organisations that rely on user discretion are assuming away the main failure mode.
AI data loss is becoming an identity and entitlement issue as much as a content issue. The question is not just what data exists, but what identity, service account, or agent can reach it and under what policy. That connects AI governance directly to IAM, PAM, and NHI lifecycle controls because connected agents often operate through non-human access paths. Teams should manage agent retrieval rights with the same discipline they apply to privileged machine access.
MCP DLP names a useful concept: retrieval-time governance. The useful shift is to decide what may be fetched, transformed, and forwarded before the model ever sees it. That is a cleaner control boundary than trying to cleanse every prompt after the fact. Security and compliance teams should design policy around retrieval-time governance as the default AI data-control model.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Retrieval-time governance is the right mental model for MCP and AI data leakage. Security teams should stop treating the prompt as the primary boundary and instead control what an agent is allowed to fetch, transform, and forward before model ingestion.
That shift brings AI governance closer to IAM and NHI practice, because the important question becomes which non-human identity can move which data class across which boundary. Where the organisation cannot answer that question, it does not yet have AI data control, only AI data visibility.
For practitioners
- Define approved AI data classes Classify which data types an LLM, application, or agent may see, including PII, PHI, PCI data, credentials, and customer records, then map those classes to explicit allow or deny rules.
- Place controls at retrieval time Apply redaction, masking, tokenisation, or blocking before an agent can pass enterprise data into the model, rather than relying on users to self-censor prompts.
- Review agent retrieval entitlements Audit which non-human identities, service accounts, or connected integrations can query SaaS tools and internal systems, and remove access that is not needed for the AI task.
- Log model-bound data transfers Keep records of what data classes were retrieved, transformed, or suppressed before model submission so security and compliance teams can trace AI exposure paths.
Key takeaways
- MCP-connected workflows widen the exposure surface because AI agents can retrieve sensitive records directly from enterprise systems, not just from user prompts.
- The practical control point is before data crosses into the AI workflow, where classification, redaction, masking, and retrieval policy can still intervene.
- AI governance now overlaps with IAM and NHI governance because agent retrieval rights determine whether regulated data can enter the model context.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article repeatedly cites credentials and API keys moving into AI workflows. |
| NHI-04 — Insecure Authentication | MCP-connected agents rely on delegated access paths that can overstep intended authentication boundaries. | |
| NHI-05 — Overprivileged NHI | The core risk is agents retrieving more data than their task requires. | |
| Recommendation — Scan AI workflows for leaked secrets and block their transfer before model ingestion. Review how agents authenticate to connected systems and restrict trust to approved identities only. Reduce agent entitlements so retrieval rights match the minimum data needed for each task. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agents and integrations authenticate as non-human services when they access connected systems. |
| Recommendation — Apply service authentication controls to AI agents and their connected integrations. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about controlling what data an AI path is authorised to move. |
| Recommendation — Map AI retrieval paths to entitlement controls and remove access that exceeds task need. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Sensitive data and credentials are being moved into AI workflows, creating access and exposure risk. |
| Recommendation — Track AI data-leak scenarios as credential access and exfiltration patterns in detection logic. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The article references APIs as a primary path into LLM workflows and connected systems. |
| Recommendation — Harden API authentication on AI-connected services so retrieval cannot be abused. | ||
Key terms
- Retrieval governance: Retrieval governance is the policy layer that decides which documents, snippets, and records an AI agent can see before they enter context. It turns search and knowledge access into a controlled authorization step, with allow, redact, deny, and approval outcomes based on sensitivity and need-to-know.
- MCP-Connected Workflow: An MCP-connected workflow is an AI-mediated path that uses the Model Context Protocol to reach tools or data sources beyond the model itself. That expands the governance problem from prompt handling to delegated access, because the request can now touch internal systems through a session path.
- Data boundary: A data boundary is a policy-defined set of trusted destinations, account types, and application paths where sensitive information is allowed to move. It shifts control from scanning every transfer to containing movement outside approved work zones, which is better aligned to AI-era workflows and mixed-device environments.
- Agent retrieval entitlement: Agent retrieval entitlement is the scope of data an AI agent or connected service is authorised to fetch from source systems. It should be narrower than general user access, because the risk is not just reading data but forwarding it into an AI workflow or model context.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity control to AI and automation risk across modern enterprise environments.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org