Every major model provider ships safety filters, and they are good at what they were built to do: keep the provider out of the headlines. They block the outputs that create brand and legal risk for the vendor: bioweapon recipes, CSAM, obvious jailbreaks. That is a real and useful job. It is also not your job.

Your threat model is different. You are not trying to stop the model from writing something embarrassing. You are trying to stop a customer database from leaving through a chat completion, stop an attacker from turning your support agent against your own systems, and stop regulated data from crossing a border it was never allowed to cross. Provider filters were not designed around those failure modes, and assuming they cover you is how the gap becomes a breach.

The filter protects the vendor’s risk, not yours

A provider’s content policy is enforced on their terms and tuned to their liability. It has no model of your data classification scheme, your tenancy boundaries, your contractual data-residency commitments, or which of your agents is allowed to touch which internal system. It cannot, because it does not have that context and is not supposed to.

The consequences of that gap are now measurable. IBM’s 2025 Cost of a Data Breach report found that among organizations that reported a breach of AI models or applications, 97% lacked proper AI access controls . The same report put the cost of ungoverned “shadow AI” at an average of $670,000 in higher breach costs per incident, and found that 63% of breached organizations had no AI governance policy or were still building one . None of those controls live inside a provider’s safety filter.

Prompt injection is not a solved problem, for anyone

The industry has been candid about this. OWASP ranks prompt injection as LLM01, the number-one risk for LLM applications, and states plainly that it is “unclear if there are fool-proof methods of prevention” given how the models fundamentally work. This is not a bug a provider patches once and closes.

The dangerous version is indirect: the malicious instruction is not typed by a user, it arrives inside content the model was asked to summarize: an email, a support ticket, a web page, a document in a retrieval store. EchoLeak (CVE-2025-32711) was exactly this: a zero-click AI command-injection flaw that could make Microsoft 365 Copilot disclose information over a network with no user action, scored as high as 9.3 critical by the vendor. A provider safety filter tuned for disallowed content has no reason to flag a well-formed summary request that happens to smuggle an instruction to exfiltrate data. It looks like normal traffic, because it is.

Sensitive data and the border problem

The exfiltration risk cuts both ways: what goes in and what comes out. NIST’s Generative AI Profile warns that models “may leak, generate, or correctly infer sensitive information about individuals,” and that generative AI “expands the available attack surface” through vectors like prompt injection . Once a prompt containing regulated data leaves your perimeter, you have made a data-transfer decision, often without logging it, classifying it, or checking where the inference actually runs. Gartner projects that by 2027, more than 40% of AI-related data breaches will stem from improper cross-border use of generative AI . That is a governance and routing failure, and no provider filter is positioned to enforce your residency rules on your behalf.

The trend line is not reassuring either. Stanford HAI’s 2025 AI Index counted a record 233 reported AI-related incidents in 2024, a 56.4% jump over the prior year . Adoption is outrunning controls.

What actually belongs to you

The uncomfortable structural fact is that in a multi-provider world, no single provider can be your control plane. You use OpenAI, Anthropic, and Google. You have internal fine-tuned models. Each has its own filter, its own policy surface, its own blind spots. If your security posture is the union of vendor defaults, you have no consistent, auditable boundary: you have a patchwork you don’t own and can’t fully see.

The controls that map to your threat model have to sit where your traffic actually crosses into model territory:

  • Inspection of every request and response, not just the ones a provider chose to flag.
  • Data-loss and exfiltration measurement against your classification scheme, not the vendor’s content policy.
  • Injection detection applied uniformly, including the indirect kind riding inside retrieved content.
  • Routing and residency enforcement so cross-border and cross-tenant rules are decisions you make, not accidents.
  • One audit trail across every provider, so governance is something you can prove.

That is a control-plane function, and it belongs to the enterprise. The natural place to put it is the same place a firewall has always lived: at the boundary, as a transparent proxy that every request and response passes through, independent of which model sits on the other side. Providers will keep protecting themselves. The gap between their threat model and yours is the part you have to own.

This is the boundary Milgram is built to sit on.