Fuzzing Tool-Call Sequences in Agentic Systems

Fuzzing tool-call sequences in agentic systems means testing behavior that is assembled at runtime. New coverage-guided, sequence-aware, and semantic methods find failures that conventional fuzzing misses. Testing before deployment can uncover dangerous chains, but it cannot replace runtime monitoring and policy enforcement.

Why tool-call sequences create a testing problem that traditional fuzzing cannot solve

An LLM agent chooses tools and constructs their arguments at runtime, so the same user input can produce different tool chains across runs. The path is not fixed in advance. Traditional fuzzers depend on repeatable execution paths and observable signals such as crashes or changes in code coverage. Those signals become less reliable when the system can choose a different plan, and a completed operation can still be wrong.

Multi-agent systems add to that uncertainty because their behavioral space grows combinatorially as the number of agents and message types grows. A fixed evaluation dataset cannot span those interactions. Worse, the rules against which results should be judged are scattered across prompts, agent descriptions, code comments, and YAML/JSON configurations. There is no consolidated, machine-readable specification for the whole system. A tester may therefore lack both a stable route through the application and a clear definition of success.

How multi-step tool chaining turns a single data value into a cross-boundary hazard

A value fetched from the web may be written to a file and later reused as an argument to an execution tool. Each tool can do its job correctly while the chain leads to a dangerous outcome. The security boundary therefore spans the sequence.

The “EchoLeak” zero-click attack against Microsoft 365 Copilot showed that progression through a specially crafted email that caused autonomous exfiltration of corporate data without user awareness. AppOmni’s research on ServiceNow’s Now Assist documented a different crossing of boundaries. A malformed request to a low-privilege agent caused it to direct a higher-privilege agent to copy and exfiltrate sensitive corporate data, bypassing normal checks. SMTP-enabled instances could send the data by external email.

CVE-2025-46059 describes indirect prompt injection through crafted emails in LangChain’s GmailToolkit, enabling unauthorized email exfiltration and, according to the CVE description, arbitrary code execution. LangChain disputes whether the code-execution risk stems from the toolkit itself or from user misconfiguration. MalTool, by Hu et al. in 2026, documents a separate supply-chain vector in which an uploaded malicious tool executes on the user’s device when selected and can exfiltrate credentials. The mcp.so platform has hosted more than 20,000 tools since its launch.

What coverage-guided fuzzing for multi-agent systems actually measures — and what FLARE built to do it

FLARE, by Hui et al. in April 2026, adapts coverage-guided fuzzing to track what agents do as well as which code lines they execute. Inter-agent coverage asks whether the relevant agents communicated. Intra-agent coverage asks whether each agent traversed its behavioral space. Both are needed to find failures that arise between agents that otherwise work as they should.

FLARE takes multi-agent application source code as input and extracts specifications and behavioral spaces from agent definitions. It then builds test oracles, uses coverage feedback to guide fuzzing, and analyzes execution logs to judge pass or fail. An oracle is the test’s correctness judge. Here, that judge must make sense of behavior as well as spot a crash.

FLARE’s evaluation on 16 diverse open-source applications achieved 96.9% inter-agent coverage and strong intra-agent coverage, outperforming baselines and uncovering 56 previously unknown failures requiring agent interaction. Its ShortsMaker example involved a director agent trapped in an infinite loop because a communication-mode misconfiguration prevented it from speaking twice in a row. A single-agent test would miss the interaction failure. Yet judging whether an unusual result is a genuine failure still requires LLM-as-judge or human review, both noisy substitutes for an unambiguous specification.

How greybox fuzzing uses tool-call sequences as the feedback signal — VeriGrey's approach to indirect prompt injection

VeriGrey, by Zhang, Kang, Meng, Böhme, and Roychoudhury, uses tool-invocation sequences as its feedback function. This targets a different problem from broad multi-agent behavioral coverage. It explores indirect prompt injection by observing which tools an agent invokes and in what order. Unlike a black-box approach without sequence feedback, it can steer testing toward infrequent but dangerous invocations.

The mutation design makes the attack part of the job. VeriGrey mutates prompts to link an injection task to the legitimate task, presenting the unwanted action as a necessary step toward completion. The detour is presented as the route.

VeriGrey’s evaluation on AgentDojo with a GPT-4.1 backend achieved 33% additional efficacy in finding indirect prompt injection vulnerabilities over a black-box baseline. Its case studies found attack scenarios in Gemini CLI and OpenClaw that black-box approaches could not identify. On OpenClaw, it discovered malicious skill variants with full success on Kimi-K2.5 and near-full success on Opus 4.6. Those results hold for the settings used in the tests.

How ChainFuzzer traces source-to-sink dataflow to find and reproduce multi-tool vulnerabilities

ChainFuzzer centers the dataflow from an input source to a consequential operation, or sink. That framing keeps attention on how a value travels through a workflow, rather than only which tools appear. It also confronts a practical obstacle left open by discovering a dangerous sequence. Finding a path once is not reliable reproduction.

ChainFuzzer’s prompt-synthesis mechanism synthesizes stable prompts that drive the agent toward target chains even when guardrails are active. Its guardrail-aware fuzzing raises the payload-level trigger rate from under a fifth to nearly nine-tenths. A security team needs to reproduce the chain to demonstrate the vulnerability, triage it, and assess a patch.

The payload needs to reach the relevant sink despite changes in the agent’s planning and guardrail responses.

Fuzzing specification violations that require no attacker — what SEFZ finds in deployed skill marketplaces

SEFZ, by Li, Wen, Chen, Liu, Tian, and Feng in May 2026, examines failures that do not require malicious input. A routine request can cause a skill to violate its own documented safety rules. The problem may be a guardrail whose meaning is undefined for autonomous execution, or an implementation that silently ignores the constraint. No attacker needs to supply the missing instruction.

SEFZ found specification violations in 120 of 402 real-world skills from the OpenClaw marketplace, including 26 zero-day violations in deployed skills that people were actively using. Fuzzing converged in an average of 11 minutes per skill, which suggests that screening skills at admission time could be practical. The consequences extend beyond an inaccurate response. A skill can silently delete documents, leak credentials, or transfer funds while carrying out an ordinary request.

Injection-focused testing does not directly address this failure class because the unwanted behavior comes from the skill’s own mismatch with its rules. SEFZ instead tests reachability queries derived from natural-language guardrails. That translation is a critical hinge in the method. Its validation gap limits what the resulting findings can establish, even when execution reaches the behavior being tested.

Testing skill compositions before deployment — how SkillFuzz uses Monte Carlo Tree Search to find implicit intents

SkillFuzz moves from individual skill compliance to the behavior of combinations. SEFZ tests skills against their own specifications, while SkillFuzz tests what multiple vetted skills can imply together. Individual safety guarantees do not automatically compose. A combination can steer an agent toward goals that none of its skills was individually designed or permitted to pursue.

SkillFuzz uses structured skill contracts and contract-guided Monte Carlo Tree Search to prioritize risky combinations before deployment. Rather than sample combinations without direction, the search uses the contracts to guide which branches deserve attention. It can skip the full runtime cost of running every candidate. This is useful when exhaustive search would be impractical.

SkillFuzz’s contract-guided search strategy found 41% more high-severity implicit intents than random sampling. The result rests on the information in planning artifacts. Contracts that describe what skills do can help predict dangerous compositions without full simulation, so the approach can work across a whole marketplace. The test subject is no longer simply a skill’s conduct, but the goal that a collection of skills makes possible.

How agentic fuzzing uses historical bugs to find logic vulnerabilities that coverage signals miss

AFuzz, by Park and Yun at KAIST, turns agentic reasoning toward logic bugs in underlying software. Such bugs may cause no crash and leave no coverage feedback that stands out. The V8 team’s account identifies this as a central difficulty in finding V8 vulnerabilities, which are rarely memory corruption bugs and instead involve logic. Executing the code does not prove that its reasoning is sound.

AFuzz uses a four-stage agent pipeline to find a reference bug’s root cause, propose other scenarios with that cause, generate proof-of-concept code, and run it to check those hypotheses. Its DPP-MAP scheduler orders seeds by how different they are to avoid looking into similar causes over and over. Historical bugs become starting points for reasoning that allows the search to follow a flaw beyond its original trigger path or code structure.

AFuzz ran on V8 for roughly one month and found 40 bugs, including three duplicates, earning substantial bounties and two CVEs. It also found additional bugs in SpiderMonkey and JavaScriptCore using V8 seeds. Root-cause reasoning transferred across different implementations. The same detection difficulty arises in agent testing: a logic error in software and a semantic failure in agent behavior can both look like ordinary execution to a coverage counter.

Where these methods break down — the shared limitations of fuzzing nondeterministic systems

These methods inherit uncertainty from the systems they use to test. LLMs generate and mutate inputs, so their biases influence which failures receive attention and which remain unexplored. Small prompt changes can alter plans, tool choices, argument bindings, or runtime outcomes. A good coverage result shows the paths the tests took, while another run might take other paths.

Shared models can compound those blind spots. VeriGrey’s evaluation raises the circular-dependency concern of using GPT-4.1 to attack agents running GPT-4.1. More generally, none of these methods supplies a universal oracle for semantic correctness. SEFZ’s translation from natural-language guardrails into reachability queries has no reported validation, so the test may assess a formalization that does not faithfully capture the stated rule.

Resources impose another limit on the search. ChainFuzzer’s token-cost metric makes explicit that reproducing multi-tool vulnerabilities has an operational cost, while stable prompt-to-chain mappings remain difficult. A 2026 paper on resource-exhaustion attacks shows that tool-calling chains can themselves be exploited to exhaust compute budgets, a failure class coverage-based fuzzers have no mechanism to detect. These are structural limits. They define where additional controls must take over.

Why pre-deployment fuzzing and runtime monitoring are complementary controls, not substitutes

Shahriar et al.’s agentic security survey, updated June 2026, concludes that agentic systems are structurally fragile by default and require defenses across the full agent lifecycle. Pre-deployment fuzzing explores the behavioral space available to its tests. Runtime monitoring addresses actions that occur beyond that exploration. In EchoLeak and the ServiceNow case, the dangerous chains depended on attacker-controlled inputs that arrived while the systems were running, outside a predefined test corpus.

The practical runtime responsibilities are to discover every agent running in the environment, monitor approved AI traffic in real time, detect anomalous tool-call behavior, enforce policy, and produce complete audit logs. Agents inherit human-scale permissions but exercise them at machine speed. Access models built for human users do not account for the same rate, autonomy, or chaining behavior.

CODE-AUGUR, by Luo, Zafar, Wolff, and Roychoudhury in June 2026, points toward a closer connection between specification and testing. Its specification-first approach exposes tacit agent assumptions as explicit in-source assertions that a guided fuzzer attempts to falsify at runtime. That supports continuous refinement.