agents · review · first seen Oct 27, 09:33 UTC

Vela finds web vulnerabilities persist through agent interfaces

The VELA study announced that 91% of the vulnerabilities it examined remained exploitable through its reference agent-facing interface. Builders should check which operations and inputs their interfaces expose, rather than treating an agent as a security boundary.

L0 · primary1 source4 claims checked4 min read

What shipped

This is an announced study and executable benchmark, not a reported fix to any service. VELA covers 44 vulnerabilities across twelve Web application families. It preserves vulnerable backends and derives agent-facing interfaces from legitimate workflows. The question is whether a service operation gives an agent a route to an existing vulnerable backend. [1]

The study evaluates three commercial agents across multiple interface configurations. It uses controlled comparisons to separate interface effects from agent behavior, and independent oracles to verify attack outcomes. Those choices put the interface comparison at the center of the finding. They do not establish that every agent, service, or possible interface behaves the same way. [1]

In the reference configuration, the agent realizes every attack that direct interface invocation realizes. The reported result is that 91% of the benchmark vulnerabilities remain exploitable under the reference design. The excerpt attributes no case-level loss there to agent refusal or input normalization. I read that as a result for this benchmark and configuration, not a rate to apply to an untested deployment. [1][2]

The counterexample is also in the study: interface restrictions prevent some attacks when they remove required operations or limit input control. The excerpt says exploitability remains high across vulnerability classes, so a narrower interface is not a blanket cure. The useful question is whether the particular operation and input an attack needs are still reachable. [1]

Why it matters if you build

A builder adding an agent interface to a Web service should review it as an exposure path to the backend, not just as a description of legitimate tasks. VELA’s interfaces come from legitimate workflows, yet the reference design leaves most benchmark vulnerabilities exploitable. A workflow can be legitimate while an operation or input within it still reaches a vulnerable path. [1][2]

The practical review is operation by operation. Compare what the agent can invoke with what direct invocation can do, then ask which operations the workflow requires and how much input control the agent needs. Removing an operation or limiting input control prevented some attacks in the study. Either restriction also changes what the interface can do, so I would test the intended workflow after each change rather than assume the narrower interface remains usable. [1][2]

Do not base today’s decision on an expectation that the agent will filter away a vulnerable route. In the reference configuration, the agent realized all attacks realized by direct interface invocation, and no case-level loss was attributed to refusal or input normalization. That does not prove agents never refuse or normalize inputs elsewhere. It points this review first toward interface design and existing backend vulnerabilities. [1][2]

How to try it today

1. List the service operations your agent-facing interface exposes for each legitimate workflow.
2. For each operation, record which inputs the agent controls and which backend operation it invokes.
3. In an authorized test setting, compare agent-mediated access with direct interface invocation for a known vulnerable path.
4. Remove a required operation or limit input control in a test configuration; check whether that attack path remains available.
5. Check that the legitimate workflow still works after each restriction.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. announced L0 · primary

   VELA covers 44 vulnerabilities across twelve Web application families.

   per arXiv cs.CL/cs.AI/cs.LG (L0)
2. announced L0 · primary

   The study evaluates three commercial agents across multiple interface configurations.

   per arXiv cs.CL/cs.AI/cs.LG (L0)
3. announced L0 · primary

   91% of vulnerabilities remain exploitable under the reference interface design.

   per arXiv cs.CL/cs.AI/cs.LG (L0)
4. announced L0 · primary

   Interface restrictions prevent some attacks by removing required operations or limiting input control.

   per arXiv cs.CL/cs.AI/cs.LG (L0)

What is not confirmed

The supplied results do not establish an exploitability rate for your service, an interface other than those studied, or agents beyond the three evaluated. They do not identify in the supplied excerpt which restrictions stop which individual attacks, or measure the cost to legitimate workflows after a restriction. The reported 91% belongs to the reference design in this benchmark; it is not a deployment forecast. [1][2][3][4]

Who should act, who should wait

Move now if you expose backend operations to an agent and can review or test the operations and input control it receives. The study gives a reason to check existing vulnerable paths and try narrower interfaces where an operation or input can be restricted. Wait before claiming a general protection rate, choosing a specific restriction as a proven fix for your service, or attributing safety to agent refusal. Those conclusions need evidence beyond the supplied results. [1][2][3][4]

Sources

• The Agent in the Middle: How AI-Mediated Access Reshapes Web Vulnerability Exploitation — arXiv cs.CL/cs.AI/cs.LG L0 · primary