Originally published as part of VerifyClaw's internal security research into LLM-facing attack surfaces — adapted here for a general audience.
It's tempting to treat "the model called the right tool" as the security-relevant question. It isn't the whole question. Selecting write_file when the task calls for writing a file is correct; supplying /etc/passwd as the path is not. Tool selection and argument manipulation are separate decision points, and manipulating the second one doesn't require touching the first at all.
Why it matters for MCP agents
Guardrails that only check "is this an allowed tool" miss this class entirely, because the tool is allowed — it's the value going into one of its parameters that's the problem. Path traversal, unexpected recipients, and altered destination fields are all argument-level manipulations that ride along inside an otherwise unremarkable, correctly-chosen tool call.
How we study it
The relevant measurement scores complete candidate strings — full paths, full recipients — rather than a single leading token, because two attacker-relevant strings often share a prefix and only diverge later. Comparing the sequence-level likelihood of a benign argument against a restricted one, at the same decision boundary, separates "the model considered doing this" from "the model actually emitted it" — and only the latter is evidence of anything happening in a real system.
Related reading
Our SAF-MCP audit exercises tool calls with adversarial arguments inside a sandbox, so the blast radius stays contained to the test.