The Agent in the Middle: How AI-Mediated Access Reshapes Web Vulnerability Exploitation

What happened

Services are starting to expose backends directly to AI agents through protocols like MCP, OpenAPI tool specs and natural-language endpoints, so a user can say "reorder the shoes I bought last week" and the agent calls list_my_orders(), add_to_cart() and checkout(). This paper asks a simple question: do old backend vulnerabilities still work when the attacker goes through an agent instead of the website?

1. The authors built Vela, an executable benchmark of 44 documented vulnerabilities across 12 web application families, mostly real CVEs plus some deliberately vulnerable training apps. Many are authorization and business-logic flaws.
2. For each app they built three agent-facing interfaces from legitimate workflows only, without looking at the bugs: an endpoint-oriented one (OpenAPI style, original parameters), a workflow-oriented one (MCP style, one tool per task with a bounded schema), and a query-oriented one (NLWeb style, a server-side LLM planner fills typed slots).
3. They ran the same attacks three ways on the same backend: direct web access, direct calls to the interface, and through three commercial agents. Independent oracles checked whether each attack really succeeded.
4. Result: in the reference setup the agent carried out every attack that a direct interface call could, and 91% of vulnerabilities stayed exploitable. No attack failed because the agent refused or normalized the input. In one case the agent completed an attack by adding calls the attacker had left out.
5. Interface design mattered far more than the agent. Changing the interface moved retention between 39% and 95%, while switching agents changed it by at most 4.5 points. The tightest interfaces also broke some legitimate workflows.

Why it works

The agent is a confused deputy. It acts with the user's identity and passes along the user's intent, including attack payloads phrased as normal requests. Model safety training targets harmful content, not a crafted ID in an order lookup or a negative quantity in a cart. Those look like ordinary business requests.

The backend still holds the real bug. If an endpoint trusts a client-supplied user_id or skips a price check, it does not matter whether the request came from a browser, curl or an LLM. Only the interface can help, by not exposing the operation or by narrowing what inputs the caller controls.

The bigger pattern

This is defense in depth placed in the wrong layer. Teams may assume the agent is a filter, like a WAF made of judgment. The data says it is a pass-through. The known lesson from API security applies again: the server must enforce authorization and business rules on every call, whatever the client.

What is new is the measurement. It shows that the shape of the tool schema, not the choice of model vendor, decides most of the exposure, and that tighter schemas trade off directly against functionality.

What it means in practice

• Treat MCP servers and agent tool APIs as public APIs. Run the same authz checks, rate limits and input validation you run on REST endpoints.
• Prefer workflow-shaped tools with bounded arguments over exposing raw endpoints with all their parameters.
• Bind identity on the server side. Never let the agent set user_id, tenant_id or price fields.
• Do not count on model refusals as a security control in your threat model.
• Add agent-originated traffic to your security tests: replay known IDOR, mass assignment and business-logic cases through the tool layer, not just the web UI.