al-ice.ai

Repeat After Me: ToFu Turns Six Agent Frameworks Into Confused Deputies, Then Finds 253 Bugs in 343 MCP Tools

AI Security Research by al-ice.ai Editorial

A 33-page paper posted to arXiv on 9 October 2026 does two things at once, and both of them are aimed at the same trust assumption. ToFu: Exploiting and Fuzzing the LLM–Orchestrator–Tool Trust Boundary (arXiv:2610.13651v1, by Md Nazmul Islam Ananto, Pierre Prevost-Avenel, Colin Smith, Kyungtae Kim, Taegyu Kim and Arslan Khan; GBHackers reports the authors span Pennsylvania State University, Université Montpellier and Dartmouth College) first shows that attacker-supplied text naming a tool and its arguments can become a live invocation simply by getting the model to repeat it — demonstrated, as reported, against LangGraph, Microsoft Agent Framework, Google ADK 2.0, AutoGen, Strands and CrewAI — and then scales the underlying insight into an automated fuzzer that reports 253 verified semantic security bugs across 343 tools in 118 of 273 open-source MCP servers tested (3,405 tools extracted). The paper’s own appendix includes a Repeat-After-Me transcript on LangGraph.

The core claim, stated in the abstract we read first-hand, is that the orchestration layer creates a boundary “where tool semantics may go unenforced and LLM-generated arguments may be incorrectly treated as trusted.” A request can satisfy a tool’s input schema while violating the security requirements written in the tool’s own documentation — a string accepted as a workspace file path may resolve outside the authorised directory. Schema compliance, in other words, is not trustworthiness. Everything else in the paper is that sentence, weaponised in both directions.

Direction one: the model says it, so the tool does it

The Repeat-After-Me technique is disarmingly simple, and that is the point. In the evaluated configurations, attacker text specifying a tool and its arguments becomes an executable invocation once the model echoes it back: when the output matches the tool-call shape, the orchestration layer fires. No parser exploit, no encoding trick — the model’s repetition is the authorisation. The paper demonstrates this across six orchestration frameworks, and the framework list matters more than the trick: LangGraph, Microsoft’s Agent Framework, Google’s ADK 2.0, AutoGen, AWS Strands Agents and CrewAI are the default scaffolding a large share of production agents are built on. One technique, six codebases, same missing check.

This is the confused-deputy problem wearing an agent costume, and it connects directly to something this site keeps documenting: the component that creates a permission and the component that evaluates it parse the subject differently. Here the orchestrator treats model output as an instruction source while the safety story assumes model output is untrusted data. Until those two agree, every tool with side effects sits behind a gate that opens from the inside.

Direction two: fuzz the tool, not the prompt

Rather than relying on successful prompt manipulation for every test, ToFu separates vulnerability discovery from delivery: it challenges tool implementations directly with adversarial but schema-valid arguments. The framework repurposes tool descriptions, argument names and schemas into security specifications, drawing on a corpus of 74 CWE-guided, semantics-aware sanitisers. An LLM selects the relevant checks and generates the initial fuzzing seeds — but, in a design decision the authors deserve credit for, the model does not judge whether an execution is vulnerable. Verdicts come from coverage-guided mutation (Atheris) checked through runtime introspection and outcome-based oracles: Python tracers watch filesystem, process and network operations, while outcome checks test whether tools reject prohibited inputs or return safe fallbacks. A tool can complete normally and still be flagged.

That design is what lets ToFu catch what crash-based fuzzing misses, and the triage funnel is unusually honest about it: 508 candidate bugs went in, 103 non-vulnerable findings and 152 duplicates came out under manual review, leaving 253 verified bugs. A single underlying defect can affect multiple tools, which is why the affected-tool count (343) exceeds the bug count (253). Papers that publish their discard pile are easier to trust than papers that only publish hits.

What 253 bugs look like

The verified breakdown, as reported: 115 reflected-output bugs, 64 path-traversal flaws, 58 log-injection issues, 7 SSRF vulnerabilities, 5 data-exfiltration bugs, 3 OS command-injection flaws and 1 leftover temporary-file issue — which sums to 253 exactly. Two caveats the coverage itself volunteers: reflected output was not automatically counted as exploitable cross-site scripting (impact depends on whether downstream software renders the content unsafely), and reachability was bounded by missing credentials, unavailable backends and startup failures, with static analysis covering what execution could not observe. The standard 60-second fuzzing budget found 231 verified bugs; deeper testing added 22 more, which is a useful calibration curve for anyone planning to run this class of tooling themselves.

The case study worth remembering is webpage-screenshot-mcp: its screenshot-page tool accepted file:// URLs and returned images of readable local files and directory listings. Its URL parser validated syntax; navigation went straight to a browser with nobody enforcing the advertised webpage-only boundary. Syntax validation standing in for semantic enforcement is the miniature version of the whole paper.

The fix the authors want, and the audit that falls out

The researchers argue that tool metadata should become an enforceable security contract and that implementations must validate model-generated arguments independently instead of delegating security to the LLM. Their evaluation also documents tools reaching files, terminal sessions and processes outside intended boundaries — a reminder to sandbox the security testing itself, not just the agent.

For defenders, the actionable reading is threefold. First, treat every MCP tool’s input handling as untrusted-input code, because the prompt-injection half of this paper proves attackers can dictate the arguments and the fuzzing half proves the tools do not check them — the unbounded body read in mcp-go and the missing authorisation in JeecgBoot’s AI rag module are the same disease at different layers. Second, distrust repetition as authorisation: any pipeline where model output is parsed into tool calls needs a provenance check on who authored the arguments, not just a shape check on the output — the SSRF pivot surface across MCP servers shows what attacker-chosen arguments buy once they are inside. Third, run ToFu-shaped testing before your adversaries do: schema-valid adversarial arguments against your own tools, with outcome oracles, on a 60-second budget per tool. The paper just showed that 231 of 253 bugs cost one minute each to find.

Verification note. The paper title, arXiv identifier (2610.13651v1), submission timestamp (9 October 2026, 14:27:32 UTC), author list, page/figure/table counts, abstract claims, corpus size (273 servers, 3,405 tools), verified-bug totals (253 bugs, 343 tools, 118 servers) and the appendix contents were read first-hand from the arXiv abstract page. Author affiliations, the six-framework Repeat-After-Me list, the 508/103/152 triage funnel, the 74-sanitiser corpus, the Atheris/mutation/oracle design details, the per-class breakdown, the webpage-screenshot-mcp case study and the 231-plus-22 budget figures are relayed as reported by secondary coverage (CyberPress, GBHackers, CSO Online, daily.dev) and the paper’s reporting therein — we did not fetch the full 33-page PDF or execute ToFu, and the framework-bypass and tool-bug claims are the researchers’, not ours. Cross-references to our own MCP coverage are our editorial analysis. We have no evidence of in-the-wild exploitation of any specific finding and imply none.

Sources: