Every generation of software gets the vulnerability it deserves. The web got SQL injection: a single class of flaw, easy to describe, catastrophic in aggregate, and responsible for a decade of breaches because untrusted input and trusted instructions traveled down the same channel. We eventually learned to separate them. Parameterized queries drew a hard line between data and code, and the problem became tractable.
The AI era has inherited the same shape of flaw. It does not get to inherit the same fix.
The number one risk, by consensus
Prompt injection is not a fringe concern raised by red teamers looking for attention. It sits at the top of the OWASP Top 10 for LLM Applications as LLM01:2025, the single highest-ranked risk in the category. The definition is deceptively simple: user prompts alter the model’s behavior or output in unintended ways. The dangerous variant is indirect prompt injection, where the malicious instruction does not come from the user at all but from external content the model ingests: a web page, a document, a retrieved record, an email in the context window.
NIST’s Generative AI Profile (AI 600-1) formally classifies both direct and indirect prompt injection as cybersecurity risks, and notes that researchers have already demonstrated indirect injection being used to steal proprietary data or run malicious code remotely. That is not hypothetical. The foundational study by Greshake et al. showed adversaries remotely compromising real, deployed LLM-integrated applications (including Bing’s GPT-4-powered chat) simply by planting instructions in content the system was designed to read. Their conclusion was blunt: effective mitigations are lacking.
Why the SQL injection analogy breaks
The comparison to SQL injection is useful right up until the part where it stops being reassuring. With SQLi, we had somewhere to draw the line. The database always knew the difference between a query and a parameter; we just had to use that boundary correctly.
There is no equivalent boundary inside a language model. As the UK NCSC puts it , “under the hood of an LLM, there’s no distinction made between data or instructions; there is only ever next token.” A model cannot be configured to treat retrieved text as inert. Everything in the context window is, to the model, potentially an instruction. This is why the NCSC warns that prompt injection may never be fully mitigated the way SQL injection was , and that underestimating it could produce data breaches exceeding the SQL injection wave of the 2010s.
Read that carefully. The national cyber authority is not saying this is like the last decade’s worst breach class. It is saying it could be worse, and that the clean fix we relied on last time does not exist.
This is already an operational problem
If you are waiting for the threat to mature, it already has. In a Gartner survey of 302 cybersecurity leaders conducted in early 2025, 32% (nearly one in three organizations) reported an attack in the prior twelve months that abused their application’s prompt. Attacks against the prompt layer are now a routine part of the threat landscape, not an edge case.
The cost side is just as concrete. IBM’s 2025 Cost of a Data Breach Report found that shadow AI (models and agents deployed outside governance) was a factor in 20% of breaches and added an average of $670,000 to the cost of each one. Most tellingly, 97% of organizations that suffered an AI-related security incident lacked proper AI access controls. The breaches are not happening because the models are exotic. They are happening because nobody is watching the traffic.
What good looks like
If you cannot eliminate prompt injection at the model, you have to manage it as a traffic problem, the same way we manage every other input we do not trust. That means treating the boundary between your AI applications and their model providers as a control point, not an open pipe. Concretely, an enterprise should be able to answer:
- What is actually being sent to external model providers, across every agent and app?
- Can we detect prompt-injection attempts in that traffic before they reach the model?
- Do we measure what sensitive data is leaving, and can we stop it when it should not?
- Is any of this governed centrally, or is each team improvising its own controls?
For most organizations today the honest answer to all four is no, because the AI traffic layer is unmonitored. Requests go straight from application code to a provider API with nothing in between that understands the risk.
That gap is the reason Milgram exists. It sits as a transparent proxy at the AI traffic boundary, between your agents and applications and the model providers they call, giving security and platform teams a single control plane to inspect that traffic, detect prompt injection, prevent sensitive-data exfiltration, and govern it uniformly, without rewriting applications or locking into a single model vendor.
The last vulnerability class of this magnitude took the industry roughly a decade to bring under control, and it had a clean fix. This one does not. The organizations that come through it well will be the ones that decided early to watch their AI traffic instead of assuming the model would police itself.