The OWASP Top 10 for LLM Applications is now the closest thing the industry has to a shared threat model for generative AI. It is a good list. But a list of vulnerability classes is not a control strategy, and most enterprises are reading it as a developer checklist when the real exposure sits at the infrastructure boundary: the point where your agents and applications talk to a model provider. This is a practical read of the top of that list for the people who own the risk, not just the code.

LLM01 is not a code smell, it’s a traffic problem

OWASP ranks Prompt Injection as LLM01 , the number-one risk, and defines it simply: user prompts that alter the model’s behavior or output in unintended ways. The instinct is to treat this as an application bug: sanitize inputs, harden the system prompt, ship a fix. That framing badly underestimates it.

Prompt injection is a property of the language, not of a particular endpoint. There is no schema to validate against, because the payload and the legitimate instruction are the same medium. NIST’s Generative AI Profile names it a primary attack vector and draws the distinction that matters most for enterprises: direct injection, where a user manipulates the model, versus indirect injection, where the malicious instruction rides in on retrieved content: a document, a web page, an email the agent was asked to summarize. NIST notes researchers have already used indirect injection to steal proprietary data and run code remotely.

Indirect injection is the enterprise-scale version of the problem, and it is why per-application patching does not scale. Every agent that reads untrusted content is an entry point. The only place you can see and govern all of them at once is the traffic layer they share.

LLM02 is your data classification policy, restated as an attack

LLM02, Sensitive Information Disclosure , reads like a compliance officer’s inventory: PII, financial details, health records, confidential business data, security credentials, and legal documents. That enumeration is the point. These are the exact classes your existing DLP and governance programs already cover, except now they can leave the building inside a model prompt, in free text, over an API call that traditional egress controls were never designed to inspect.

The failure mode is bidirectional. Sensitive data flows out in prompts your own applications construct, and it can be pulled out of the model by an injection crafted to make it disclose training data or context. Both directions cross the same boundary.

The breach data has caught up

This is no longer theoretical. Stanford HAI recorded 233 AI incidents in 2024, a record high and a 56.4% year-over-year increase . The economics are now measurable too. IBM’s 2025 Cost of a Data Breach report found that 13% of organizations suffered breaches of AI models or applications, and 97% of those breached lacked proper AI access controls . That second number is the finding to sit with. Nearly every AI breach traced back to an absence of controls at the AI boundary, not a clever exploit, just an ungoverned path.

The unsanctioned version of the problem is worse. Shadow AI (employees using tools no one approved) drove one in five breaches and added roughly $670,000 to average breach cost for organizations with high shadow-AI use. Verizon’s DBIR shows how routine this has become: 15% of employees were regularly using generative AI on corporate devices, and 72% of them did so through non-corporate email accounts , meaning that activity, and the data going with it, was invisible to the enterprise entirely.

And the governance gap is structural. IBM reports 63% of breached organizations either have no AI governance policy or are still developing one . Policy without an enforcement point is a document, not a control.

What good looks like

The OWASP list, read alongside the breach data, points to a consistent conclusion: the mitigations that generalize are the ones that live at the AI traffic boundary rather than inside each application. Concretely, a mature program can answer these questions across every model call the enterprise makes:

  • Visibility: which applications, agents, and users are sending traffic to which providers, sanctioned or not?
  • Inbound inspection: is untrusted content being screened for injection before it reaches a model with tools and data access?
  • Outbound inspection: are the LLM02 data classes being detected and stopped before they leave in a prompt?
  • Uniform enforcement: does policy apply the same way whether the traffic comes from a flagship app or an intern’s script?

None of this requires rewriting your applications, and it should not depend on each team implementing controls correctly and consistently. It requires a control plane at the point where AI traffic already converges.

That boundary is exactly where Milgram sits. As a transparent proxy between your AI applications and their model providers, it gives security and platform teams a single place to see, inspect, and govern LLM traffic, turning the OWASP threat model and your own governance policy into enforcement that actually holds.

The Top 10 tells you what can go wrong. The breach data tells you it already is. The open question for most enterprises is not whether these risks are real, but whether there is a single place to control them. There should be: milgram.dev .