synodic-ai AI SECURITY
AI Security Desk · Agent Security

Three Trust Boundaries Agents Cross Without Checking: Tool Arguments, Workspace Content, and Their Own Evidence

2026-10-12

Three papers posted to arXiv on 2026-10-09 examine different places where an LLM agent treats something as trusted that it should not: the arguments it hands to tools, the files and messages it reads in a shared workspace, and the evidence it generates about a vulnerability it is trying to fix. Read together they describe one control gap, with a measurement for each boundary.

The orchestrator-tool boundary: arguments are not trusted input

ToFu, from Md Nazmul Islam Ananto, Pierre Prevost-Avenel, Colin Smith, Kyungtae Kim, Taegyu Kim, and Arslan Khan, starts from the architecture that nearly every agent deployment now shares. A language model produces output, an orchestration layer translates that output into structured tool invocations, and the tools act on external software. The authors identify an LLM-orchestrator-tool trust boundary at the seam between those layers, where tool semantics may go unenforced and LLM-generated arguments may be incorrectly treated as trusted.

The framework derives semantic security checks for LLM tools automatically, using two inputs the tools already carry: their existing metadata, and a corpus of sanitizers organized by CWE weakness class. ToFu specializes those checks to individual tools, then generates fuzzing harnesses and semantic oracles for each one using runtime introspection and outcome sanitization. The point is to test whether a tool actually enforces the input semantics its own documentation describes.

The evaluation ran across 273 MCP servers containing 3405 tools. ToFu identified verified bugs corresponding to CWE weakness classes in 343 tools across 118 of the servers, which is 118 of 273 servers, roughly two in five. The authors' conclusion is direct: real-world tools frequently fail to enforce their documented input semantics, which makes it unsafe to treat LLM-generated arguments as trusted.

The workspace boundary: a correct deliverable is not evidence of safe behavior

APEX-Harm, from Ziyi Yang, Adel Bibi, Guohao Li, Bernard Ghanem, and Carlos Hinojosa, moves the question from a single tool call to a long-horizon task. Professional agents increasingly work through command-line interfaces and multiple tools over shared workspaces that contain files, messages, and business applications. The authors observe that these environments create safety risks that are difficult to capture with attacks placed at a single, known read location, which is how most prompt-injection benchmarks have been built.

The benchmark evaluates prompt and script injection against agents performing finance, consulting, and legal tasks in large workspaces. Each task contains 115 to 328 files, together with email, calendar, chat, document, spreadsheet, PDF, and code-execution tools exposed through MCP servers. Six attack categories cover static and dynamic injections, task-specific script replacement, and attacker-provided generic scripts. The benchmark measures attack success, exposure, and task performance separately, so a model cannot hide an unsafe action behind a good deliverable.

The authors evaluate 12 frontier models on 180 task instances per model. The two most robust models had the lowest overall attack success rates, 8 percent and 20 percent. Task-specific script replacement and attacker-provided generic script attacks remained substantially more effective than the average, at 81 to 84 percent and 73 percent attack success respectively. The model with the highest mean task score, 0.877, still exhibited a 33 percent attack success rate. The paper's stated conclusion is that completing the requested task is not sufficient evidence of safe behavior: an agent can produce a correct deliverable while also performing an unauthorized action in the workspace.

The evidence boundary: what the agent believes about the bug

EviRepair, from Yilian Shi, Qingyu Liu, Tianyi Zhou, Wende Tan, Chenyang Si, and Yueming Lyu, examines a boundary inside the agent rather than at its edge. Agent-based approaches to repository-level automated vulnerability repair (AVR) have shown promising repair capabilities, but the authors identify a question that has received limited attention: whether the evidence an agent generates during the repair process is reliable enough to support accurate vulnerability understanding and patch generation.

The framework introduces an explicit evidence review stage. Multiple agents collaboratively collect vulnerability evidence, verify that the evidence is consistent, and construct a reviewed vulnerability model that is then used for patch synthesis and validation. The patch is generated from a reviewed model of the bug rather than from whatever the first pass of investigation happened to conclude.

On the PatchEval and SecBench benchmarks, across multiple agent frameworks and LLMs, EviRepair consistently outperformed existing agent-based baselines, with average improvements of 16.37 percent and 40.33 percent in resolved rates respectively. The authors state that their code is available. The size of the gain on SecBench suggests that a meaningful fraction of failed repairs in the baselines were failures of understanding rather than of patch synthesis.

One gap, three measurements

Each paper measures a different instance of the same structural flaw: a downstream component accepts an upstream artifact without verifying it. In ToFu the tool accepts the model's arguments. In APEX-Harm the agent accepts workspace content as if it carried the user's authority. In EviRepair the patch generator accepts the agent's own unreviewed account of the vulnerability. The remedies have the same shape as well, an explicit verification stage with its own oracle, placed at the boundary rather than inside the component being constrained.

What to do with these numbers

For teams that publish or operate MCP servers, ToFu's result is a direct audit finding: the documented input semantics of a tool are a specification, and about two in five servers in the sample shipped at least one tool that did not meet its own specification. Tool authors should treat every argument as untrusted regardless of which model produced it, derive checks from the metadata they already publish, and fuzz the tool against those checks before exposing it to an agent.

For teams deploying agents over shared workspaces, APEX-Harm's design is the evaluation template: distribute injections across a large file set rather than at a known location, include code-execution tools in the environment, and report attack success and exposure as first-class metrics next to the task score. The 73 to 84 percent success of script-based attacks argues for treating any tool that executes code from workspace content as requiring a separate authorization path from the task itself.

For teams building security automation on agents, EviRepair reports average resolved-rate improvements of 16.37 percent on PatchEval and 40.33 percent on SecBench from an evidence-review stage between investigation and action. The broader lesson is that an agent's own intermediate conclusions are an input to be verified, not a trusted state. Across all three boundaries the engineering answer is the same: the verification lives outside the component that produced the artifact, and the component does not get to decide whether it ran.

Sources