Every security program has a map of where sensitive data lives and how it moves: databases, file shares, email, SaaS connectors, the endpoints DLP watches. There is now a data path that most of those maps do not include: the prompt. Every time an employee, an internal app, or an autonomous agent sends a request to a model provider, it can carry customer PII, health records, source code, credentials, or unreleased financials out of your control boundary and into a third party’s inference pipeline. Almost no one is auditing that traffic. That is the gap.

Why the prompt is a data path, not a chat box

Treating LLM usage as “people typing questions into a chatbot” understates the exposure by an order of magnitude. In practice, prompts are assembled programmatically: a support agent pulls a customer record into context, a coding assistant ships a repository slice to a hosted model, a RAG pipeline stuffs retrieved documents into the request. The sensitive payload is often invisible to the human who triggered the call.

The standards bodies have caught up faster than most enterprises. OWASP now ranks Sensitive Information Disclosure as the #2 risk in its 2025 Top 10 for LLM Applications , up from #6 in the prior list, and defines it explicitly to cover PII, financial details, health records, confidential business data, and security credentials. NIST’s Generative AI Profile treats Data Privacy as a distinct GenAI risk area , covering leakage and unauthorized disclosure of personal and sensitive data. When two independent frameworks name the same failure mode this prominently, it has stopped being theoretical.

The exposure is already showing up in breach data

This is not a forward-looking worry. Stanford HAI recorded 233 AI-related incidents in 2024, a 56.4% increase over 2023 and a record high. The financial and privacy consequences are landing where you would expect.

IBM’s 2025 Cost of a Data Breach Report is the sharpest signal. Among the findings:

  • Shadow AI (unsanctioned AI use outside IT’s visibility) was implicated in one in five breaches , and organizations with high levels of it paid roughly $670,000 more per breach than those with little or none.
  • Only 37% of organizations had policies to manage AI or detect shadow AI.
  • Of organizations that suffered an AI model or application breach, 97% lacked proper AI access controls , and 63% either had no AI governance policy or were still writing one.

Crucially, the data that leaks through AI is disproportionately the data you most need to protect. Shadow-AI-related incidents exposed compromised PII in 65% of cases versus a 53% global average, and intellectual property in 40% versus 33% . The AI path does not leak generic noise. It leaks the crown jewels.

The regulatory clock is running

Enforcement is arriving on the same curve. Italy’s Garante fined OpenAI €15 million in December 2024 for GDPR violations tied to processing personal data without an adequate legal basis and failing to report a breach. The decision concerned training data specifically, but the principle generalizes cleanly: regulators consider LLM data handling to be in scope, and they are willing to price non-compliance.

Cross-border flow is the next pressure point. Gartner predicts that by 2027, more than 40% of AI-related data breaches will be caused by improper cross-border use of generative AI . When a prompt containing EU resident data hits a model endpoint in another jurisdiction, that is a data transfer, one your DPO probably cannot see and your controls almost certainly do not gate.

Why existing controls miss it

Traditional controls fail here for structural reasons, not for lack of effort:

  • DLP watches the wrong channels. Email and file-transfer inspection does not parse a JSON request body en route to a model API, and does not understand that a retrieved document just became part of an outbound payload.
  • Network egress rules are too coarse. Allowing traffic to a provider’s domain is a binary decision; it says nothing about what is inside the request.
  • Provider-side settings are not your control plane. Retention toggles and enterprise agreements are contractual assurances, not enforcement you operate or can prove in an audit.

The common thread across the IBM data is an absence of controls at the point where AI traffic actually leaves the enterprise. You cannot govern a data path you cannot observe.

What good looks like

The fix is not to slow down AI adoption: it is to give AI traffic the same treatment every other egress channel already gets: a control point at the boundary. Concretely, a mature program can answer these questions on demand:

  • What sensitive data classes are leaving through prompts, from which apps and agents, to which providers?
  • Which of those flows crossed a jurisdictional line?
  • What is the enforced policy when a request carries data it should not, and where is the audit record?

Milgram sits as a transparent proxy at that AI traffic boundary, between your agents and apps and the model providers they call. It gives security and platform teams the visibility and control layer that this data path has been missing: the same posture you already expect at every other point where regulated data crosses your perimeter.

The prompt became a production data path faster than most controls could follow. Closing the gap starts with being able to see it. milgram.dev