For a decade, application security had a comfortable assumption baked in: the model reads, the human acts. A recommendation engine could be wrong, but it couldn’t wire money, delete a bucket, or email your customer list. That firewall between inference and action is gone. The moment you hand a model tools, permissions, and a loop, its output stops being a suggestion and becomes an instruction that something downstream will faithfully execute.

This is not a hypothetical shift you have time to plan for. Gartner projects that task-specific AI agents will be embedded in 40% of enterprise applications by the end of 2026, up from less than 5% in 2025 . Most of that surface is being deployed by teams optimizing for capability and time-to-ship, not for containment.

The multiplier is agency, not the model

The vulnerability class here has a name. OWASP formally defines Excessive Agency (LLM06:2025) as the risk that an agent’s granted tools, permissions, and autonomy turn a manipulated or ambiguous model output into a damaging real-world action. The model doesn’t have to be “hacked.” It just has to be wrong about who it’s taking orders from, once, while holding a token that can do something expensive.

And it will be wrong, because the underlying substrate cannot tell your instructions apart from an attacker’s. The UK NCSC puts it plainly: under the hood, an LLM makes no distinction between data and instructions, there is only ever the next token , which is why prompt injection cannot be fully mitigated the way SQL injection was. This isn’t a bug awaiting a patch. Greshake et al. established the harder version of the problem years ago: integrated applications blur the line between data and instructions, so an attacker can hijack an agent remotely by seeding instructions into content the agent is likely to retrieve : a document, a web page, a support ticket, a calendar invite. The payload doesn’t come through your login form. It arrives as data your own agent went and fetched.

Chain those two facts together and the threat model is stark. Every tool you grant an agent is a new privilege. Every external source it reads is a new injection vector. The attack surface isn’t the model; it’s the product of permissions and untrusted inputs, and agentic architectures inflate both at once.

The exposure is already showing up in the numbers

This is landing in incident data, not just threat papers. Reported AI-related incidents hit a record 233 in 2024, a 56.4% increase over the prior year . And the organizations getting hit are, overwhelmingly, the ones that shipped AI without controls around it. IBM found that 97% of breached organizations that experienced an AI-related security incident lacked proper AI access controls, and 63% had no AI governance policy at all .

The governance gap is expensive on its own. Shadow AI (agents and integrations running outside sanctioned oversight) was a factor in 20% of breaches and added an average of $670,000 to breach cost . If you can’t see the AI traffic leaving your environment, you can’t govern it, and you’re already paying the premium.

There’s a supply-chain dimension too. Verizon’s latest DBIR found third-party involvement in breaches doubled to 30% . Every agent that calls an external model provider or a third-party tool is a new dependency in that chain, one that carries your data outbound on every request.

What good looks like

You cannot solve this inside each application. Prompt-level guardrails, per-agent allowlists, and framework-specific mitigations are worth having, but they’re distributed, inconsistent, and invisible to security. The pattern that scales is the one that worked for every prior class of traffic: put a control point at the boundary where the traffic already flows, and make it uniform.

For AI, that boundary is the connection between your agents and the model providers they call. A control layer sitting there should give you, independent of which app or framework generated the request:

  • Visibility: a complete, auditable record of what your agents send to and receive from external models, so shadow AI stops being invisible.
  • Inspection: detection of injection and manipulation attempts in the traffic itself, before a poisoned output becomes an action.
  • Egress control: measurement and prevention of sensitive-data exfiltration, whether it leaves through a prompt or gets pulled in through a compromised tool.
  • Policy: one enforceable place to set what is and isn’t allowed, rather than trusting every team to get it right in code.

Milgram is that layer: a transparent, vendor-neutral firewall at the AI traffic boundary. It sits between your agents and their providers, inspects the traffic in both directions, flags manipulation and data exfiltration, and gives security a single control plane over AI usage that no longer routes around them. Because it’s a proxy, adoption doesn’t require rewriting agents or coupling to any one model vendor.

None of this makes prompt injection go away; nothing does. As NCSC and OWASP both argue, the realistic goal is to reduce the blast radius of an output you can’t fully trust. That means assuming the model can be turned against you, and building the surrounding controls so that when it happens, the damage is bounded and visible instead of silent and total.

Agentic AI multiplied your attack surface whether or not you planned for it. The question is whether you have a control point standing at the boundary it crosses. See milgram.dev .