Imagine you run a restaurant kitchen. You have a head chef (the LLM) who takes orders from customers (user instructions) and shouts commands to line cooks (tools). Now imagine a diner slips a note onto a plate coming back from the table that says "add peanuts to every dish." The chef reads it, thinks it's a legit order, and starts poisoning allergic customers. That's indirect prompt injection against tool-using agents. ToolFence doesn't try to teach the chef to spot forged notes — it installs a ticket system where every ingredient change must match a pre-approved menu before it reaches the line. The committed claim: ToolFence is the first system to compile a typed authorization blueprint before execution that distinguishes user-authorized values from untrusted observations at argument-level granularity, enforced by a deterministic monitor — reducing attack success rate to near zero on the AgentDojo benchmark while maintaining practical speed. This isn't content filtering or output voting. It's a provenance-tracking authorization layer that treats the problem as access control, not content moderation. The paper positions itself squarely against two families of defense. Multi-path consensus methods (like running multiple LLM paths and voting) still leave high attack success rates because they examine content rather than authorizing effects — they're especially weak against "within-tool" attacks where the attacker preserves the intended tool but manipulates its arguments. CaMeL, the strongest prior work using data-flow control, provides better guarantees but incurs substantial latency because it invokes a judge LLM on every single call. ToolFence's key architectural move is splitting authorization into a fast deterministic path (blueprint-match) and an expensive slow path (capability-level grants from a judge), so the judge is called only when the blueprint is genuinely incomplete — not on every execution step. The architecture belongs to the static-analysis-plus-runtime-monitor family, closer to capability-based security systems in operating systems than to the adversarial-robustness tradition most LLM safety work inhabits. Before any tool executes, ToolFence compiles a typed blueprint from the user's request — essentially a whitelist of which tools can be called with which argument types and value ranges. At runtime, a deterministic monitor checks each call against the blueprint. Only when a call falls outside the blueprint does the system escalate to an LLM judge, and crucially, the judge grants a capability (a class of permission) rather than adjudicating one concrete call. This amortizes the expensive inference cost across future similar calls. Integrity-wise, the evaluation uses AgentDojo — a community benchmark specifically designed for tool-use attacks — with Qwen3-max as the backbone LLM. The headline numbers: overall ASR reduced to near zero, with only a 3.80 percentage-point drop in clean utility. The paper explicitly targets within-tool attacks, which is the harder variant that content-filtering approaches systematically miss. The benchmark choice is strong; the single-model evaluation is a limitation. There's no independent replication yet, and the paper doesn't report results across multiple LLM backbones, which would be the obvious stress test. The milestone that matters here isn't a single number — it's deployment viability. The field needs tool-use authorization that works at production latency with <5% utility cost across diverse LLM backbones. ToolFence's 3.80pp drop is close to that threshold on one model. The next concrete bar: demonstrating the same ASR-near-zero result on 3+ frontier models (GPT-4o, Claude, Gemini) with latency under 200ms per tool call in a real agentic deployment. That's probably 12-18 months away if the approach generalizes. The experiment the authors didn't run — and should have — is a multi-backbone evaluation. They tested on Qwen3-max only. The honest read: this is likely (a) compute budget, since running AgentDojo across multiple frontier APIs is expensive, possibly combined with (c) saving it for the next paper where they can show generalization as a separate contribution. The absence of an adaptive attacker who specifically targets the blueprint compilation phase is also notable — that's the obvious red-team follow-up.
