Defending the execution boundary for agent actions

Research track

TL;DR

• Indirect prompt injection reaches an agent through whatever the agent reads: a web page, a tool result, a file, a skill. The carriers keep multiplying, so a defence built on recognising attack patterns has to be rebuilt for each new carrier.
• Three recent papers defend a different point: the execution boundary, where an agent's internal state becomes an external action such as a tool call, a file write, or a sent message.
• APEX, which checks each action against a single authorisation contract written before any untrusted content runs, reported 0% attack success on five of six benchmarks and 0.56% on the sixth ¹.
• CounterSteer, which steers the model's internal activations on every tool result, cut held-out attack success from 0.21–1.00 to 0.00–0.17 across five open-weights models, and it reports its own blind spot plainly: attacker-chosen arguments inside otherwise legitimate calls ².
• Boundary auditing, which decides Pass or Block on a fully specified pending tool call before the call takes effect, reached 86% block recall at a 6–8% false-block rate in the third paper, against 44–47% recall at a 16–33% false-block rate for the comparison system ³.
• Our own authorisation work has the same shape as APEX and the boundary audit: a record of what a task permits, checked before each consequential action. CounterSteer's blind spot tells us where that check is thinnest, which is the provenance of tool arguments.

How we got there

An agent that reads untrusted content can be steered by it. A page the agent fetches, a document it summarises, or a result one of its tools returns can carry an instruction the user never gave. The instruction does nothing while it sits in the context. It matters at the moment the agent acts on it. Each of the three papers starts from that moment and builds the defence there, in three different places.

A contract written before the attack arrives decides what may run

APEX compiles a single authorisation contract before untrusted execution begins ¹. The contract states what the task is allowed to do. When the agent reaches for an action, the action is admitted only when the contract justifies it. The paper adds a second mechanism: unendorsed use of runtime information is arranged to reveal itself before the effect commits, so an action that depends on content the contract never endorsed exposes itself at the boundary rather than after it.

The evaluation compared APEX against 13 baselines across six benchmarks. Attack success was 0% on five benchmarks and 0.56% on the sixth. Under adaptive attacks, where the attacker knows the defence and adjusts, attack success stayed at 0% on all three capability-unit types the paper tests. The result held across defender backbones, and the authors released their code.

Read the shape of the result, not only the zeroes. A pattern-based defence scores well until the carrier changes, because the score measures yesterday's attacks. A contract scores against a different question: was this action among the ones the task permitted? That question has the same form whether the steering arrived in a web page, a tool result, or a skill file.

Steering inside the model removes the detection decision

CounterSteer works inside the model instead of at the action ². The authors fit a direction in the model's residual stream from paired episodes that differ only in whether an embedded instruction gets followed. At deployment, that direction is subtracted from every tool-result token while the model reads its inputs. The defence is always on. It needs no fine-tuning, no auxiliary model, and no added tokens, and it makes no detection decision, so there is no classifier verdict for an attacker to route around.

Across five open-weights models from 8B to 106B parameters, from five vendor lineages, held-out attack success fell from 0.21–1.00 undefended to 0.00–0.17 defended. On the AgentDojo benchmark, compromise fell from 0.10–0.49 to 0.006–0.079, while benign utility stayed at 93–100%. White-box gradient attacks, the strongest case the paper tests, compromised at most 2 of 52 episodes, and none of 2,052 replayed human red-team attacks succeeded.

The paper then reports where it still fails, and the failure is instructive. CounterSteer remains weak on parameter-manipulation attacks, where the agent makes an otherwise legitimate call using arguments the attacker chose. Steering can stop the model from obeying an instruction it should ignore. It cannot judge whether the arguments of a permitted call came from a trustworthy place, because that judgement is about provenance, and provenance lives outside the model's activations.

An audit before each consequential action catches what screening misses

The third paper names the attack form the other two imply ³. In staged prompt injection, the injected instruction exploits task-specific context, propagates across connected stages of a long task, and changes a consequential action while the workflow around it continues normally. Screening inputs cannot locate where to intervene, because the payload may be assembled across stages. Reviewing a completed run is too late for the same reason: the action has already taken effect.

The authors formulate the defence as boundary action auditing. Given the starting context, the trajectory so far, and one fully specified pending message or tool call, an auditor decides Pass or Block before the call's effect occurs. Their attack pipeline confirmed staged attacks against two widely used coding agents in their native runtimes, across eight workflow scenarios, seven attack goals, and six injection surfaces. The authors released a benchmark of 479 pairs covering 3,112 audited units. Their attribution method, Path-Aligned Attribution, reached 86% block recall at a 6–8% false-block rate. The comparison system, ARGUS, reached 44–47% recall at a 16–33% false-block rate.

The false-block figures deserve as much attention as the recall. A boundary check that blocks one legitimate action in six will be switched off, and a switched-off check defends nothing. An audit that blocks roughly one in fourteen legitimate actions while catching six of seven attacks is a control a team might actually keep running.

The three approaches, side by side:

The same comparison in text form:

• APEX: acts at the action, before it commits; checks whether a pre-compiled authorisation contract justifies the action; reported result 0% attack success on five of six benchmarks, 0.56% on the sixth; known limit is that the contract has to be written, and written well, before execution.
• CounterSteer: acts inside the model, on every tool result; checks nothing at decision time, because a fitted steering direction is always applied; reported result held-out attack success 0.00–0.17, down from 0.21–1.00; known limit is attacker-chosen arguments in legitimate calls.
• Boundary action auditing: acts at each pending tool call, before its effect; checks the pending call, its context, and the trajectory so far; reported result 86% block recall at a 6–8% false-block rate; known limit is false blocks: about 6–8 of every 100 legitimate calls stopped.

Figure 1. APEX attack success rate across its six benchmarks. Look at the sixth bar: the contract held to 0.56% there rather than zero, which is the honest version of the result. The source summary does not name the individual benchmarks, so they are numbered 1 to 6.

The same numbers as a list:

• Benchmarks 1 to 5: 0% attack success each.
• Benchmark 6: 0.56% attack success.

What this means for our work

Our own systems give agents real tools, so the boundary question is practical for us. We keep an authorisation ledger for agent work: for a given task, the ledger records which actions are permitted, and each consequential action is checked against that record before it takes effect and is allowed or blocked on the spot. A reader running a single coding agent meets the small version of the same choice the first time the agent proposes a command the reader did not expect: approve it, refuse it, or find a rule that decides next time without a human reading every call.

The three papers map onto that work in three distinct ways.

APEX is the closest relative. A contract compiled before execution and a ledger written for a task are the same design decision: write down what is permitted while the instructions are still trusted, then check actions against the writing. The APEX numbers are evidence that the design can hold under adaptive attack, at least on the benchmarks its authors chose, which we note because authors choose benchmarks their systems do well on.

Boundary auditing supplies the procedure our ledger checks follow: decide on the fully specified pending call, with its context, before the effect. The staged-injection result is the reason the check cannot move earlier, to ingestion, or later, to review. By the time a run completes, a staged instruction has already spent itself in an action.

CounterSteer contributes the warning. Our boundary check examines the call and whether the task permits it. The parameter-manipulation result says an attacker may not need a forbidden call at all: a permitted call with supplied arguments does the work. So the check also has to ask where the arguments came from. Provenance of tool arguments is the complementary control the CounterSteer authors point at, and it is now the next thing on our own list to make explicit in the ledger: which parts of a pending call were written by the task, by the user, or by content the agent read along the way.

We hold one reservation about all three results. Each paper evaluates on benchmarks and test rigs its own authors built, so the scores are reports from those rigs rather than measurements on a shared one. The boundary principle is supported by three independent groups arriving at adjacent designs in the same season, which is stronger evidence than any one score.

References

1. "APEX: Active Protection at Execution Boundaries for LLM Agents" — Zheng, X. et al., arXiv:2610.06966
2. "CounterSteer: Suppressing Indirect Prompt Injection with Activation Steering" — Russinovich, M., arXiv:2609.36570
3. "Blocking at the Boundary: Auditing Long-Horizon Agents against Staged Prompt Injection" — Liu, J., Han, Y., Lyu, X., Wang, W., Yu, T., arXiv:2610.05163