PACE: a provenance-aware tool-call mediator that cuts agent attack success at ≤3 points of utility
A new arXiv defense argues admission-time vetting of skills and MCP schemas is unsound, and mediates every tool call at the last boundary before it executes.
PACE, a new defense for tool-using agents, argues that vetting skills and MCP schemas before admitting them is fundamentally unsound — and instead mediates every tool call at the last boundary before it executes. On eight executable agent-security benchmarks, the authors report strictly lowest attack success in 62 of 79 eligible attack columns (ties in 14), with native utility dropping at most three points.
What shipped
PACE (Provenance-Aware Capability Enforcement) is a paper from KAUST's PRADA Lab, RIKEN AIP, the University of Macau, the National Institute of Informatics, and UESTC, posted to arXiv on October 1, 2026 (arXiv listing). The failure mode: a tool-using agent reads retrieved pages, tool returns, files, and third-party skill descriptions into the same context that picks the next action, so poisoned tool metadata, MCP schemas, reusable skills, and memory can steer a call that sends mail, writes files, or spends money (intro).
The core argument: admission-time vetting cannot be sound. The motivating example is a mail skill whose code always calls send_email(body). A benign specification uses a fixed template; a malicious one asks the model to copy a credential out of context — and the code and interface are identical either way. Because a safe variant and a leaking variant produce the same admission evidence, "a sound gate then cannot relax that site for either." The security-relevant object is not the artifact itself but its behavior family — the set of trajectory distributions it induces across attacker-supplied contexts — which no audit of the artifact enumerates (Section 2.1).
The mechanism. PACE mediates every tool call immediately before it executes. Four things meet at that boundary: the concrete proposal, the authenticated request, the observed provenance, and a hook that can still change the outcome. Two checks do the work:
- Path confinement proposes an executable cut of the represented influence paths from untrusted content to the call; the final action must preserve the certified cut.
- Capability and effect verification checks schema-defined effects against authority compiled from the authenticated request.
The paper distinguishes the certified execution contract, which preserves the cut and rechecks the final call, from the evaluated configuration, which may restore a blocked call or apply a declared repair — noting that restoring a blocked call can discard separation, and rewriting an authorized call can change its effects. The defender is deliberately weak: it acts only at the tool boundary, reading proposals and returns and weakening or blocking calls. It cannot retrain the model, instrument a tool's interior, or enumerate contexts (Section 2.1).
Results (self-reported). Across eight executable agent-security benchmarks and three target-model families, the evaluated configuration achieves strictly lowest attack success in 62 of 79 eligible attack columns and ties in 14; full-benchmark native utility loses at most three points relative to the undefended agent. A complete ablation over 1,167 paired cases attributes most security gains to effect verification, and refusal control to boundary adaptation. A reduced-scale adaptive search succeeds on 0 of 30 out-of-authority targets against the defense (abstract).
Why it matters
For engineers building tool-using agents, the contribution is a reframing: stop treating admission-time review of plugins, skills, and MCP servers as the security boundary, and mediate the egress instead. The paper targets deployments where tool descriptions reach the planning context — "as MCP tool descriptions and marketplace skills do today" (intro). If the trust-inversion argument holds, spec review of a skill is reviewing the attacker's own text, and the last enforceable boundary is the tool call itself.
The practical hook is the utility number. A defense that cuts attack success in 62 of 79 attack columns while losing at most three points of native task performance is a trade engineers can actually take. The design point also differs from the four existing defense families the paper surveys — flow control anchored in a trusted plan, declarative privilege, detection-and-re-execution, and instruction/data separation — by deciding at the last tool boundary with provenance in hand, rather than trusting a plan or a learned distinction between instructions and data (intro).
Caveats
- All results are self-reported by the authors. The paper states "source code is in the supplemental material"; no public repository or independent replication was found as of writing.
- The experiments section — the names of the eight benchmarks, the three model families, the exact utility metric, and what makes an attack column "eligible" — sits beyond what I could extract from the paper's HTML, so this post does not name them.
- The guarantees concern "represented chains": they are bounded by what the schemas represent. Probabilistic noninterference is used as the yardstick the authors measure against, not a property they claim.
- The adaptive evaluation is explicitly reduced-scale (0/30 out-of-authority targets), not a claim of general robustness.