AI Agent Tool-Use Security

An AI agent that can only talk is limited in how much damage a bad prompt can do. An AI agent that can also read files, send email, call an API, or run a shell command is a different animal entirely — every one of those tools is a lever an attacker can try to pull from the outside, through nothing more than the words in a page it reads or a message it's asked to summarize.

This is the core problem behind the current wave of agent-security research (and the live red-teaming competitions built around it, several backed by the major model labs): agents fail in a handful of well-understood SHAPES, not an infinite space of clever prompts. Once you know the shapes, you can test for them systematically — as an attacker building a red-team suite, or as a defender building the guardrail that has to hold against one.

We run Cleanor's own MCP tool server for AI builders, so this is directly our problem too, not just an academic exercise. Below are the four failure classes, and we've published the full pattern breakdown — 24 generalized techniques, 6 per class, each with the mechanism it exploits and a concrete mitigation — as an open dataset (linked at the bottom) for anyone building a red-team suite or a defensive checklist of their own.

1. Exfiltration: sensitive data leaves through a tool call

The most direct failure: something sensitive — a credential, a file's contents, an internal record — ends up leaving the agent's boundary through an otherwise-ordinary tool call, like a network request or an email.

What makes this hard to catch isn't the leak itself, it's how many ways there are to make the leaving data LOOK unremarkable to a scanner:

• Clean-sink smuggling — put the sensitive value in a field the guardrail doesn't happen to inspect (a URL parameter instead of the request body, say), rather than the one it was built to scan.
• Reversible obfuscation — ask the agent to reverse, encode, or spell out a value before sending it, so the literal string a keyword scanner is looking for never appears in the outbound call.
• Split-secret staging — send the value across two or more separate, individually-benign-looking calls that only reconstruct the secret downstream.
• Source laundering — read an unrelated, harmless file immediately before the sensitive one, so a trace-level "where did this come from" check attributes the action to the decoy.

The common thread: per-call, keyword-based scanning loses to anything that spreads the signal across space (multiple fields, multiple calls) or transforms it (encoding, reversal). A defense has to reason about the whole trace and canonicalize before it matches, not just grep the literal payload of one call.

2. Confused deputy: the agent's own privilege, used against its owner

An agent that's allowed to send notifications or write files has a REAL privilege. The confused-deputy failure is getting the agent to spend that privilege on the attacker's behalf while it still looks, structurally, like the agent doing its normal job.

• Routine-task framing — ask for "the weekly summary sent to the usual list" instead of naming the actual effect; a judge that keys on words like "share" or "send" misses the same effect described as routine housekeeping.
• Recipient substitution — the notification itself is completely normal; only the destination has been quietly redirected.
• Escalating small asks — a sequence of individually-reasonable requests (grant access, then widen scope, then export) that only add up to a violation in combination — invisible to any check that only looks at one turn at a time.
• Impersonated authority — untrusted content claims to be "IT support" or "the account owner" to unlock an action the agent would otherwise decline, even though the claim came from the same unverified channel as the request.

The fix pattern here is consistent across all six: judge the STRUCTURAL effect of an action (a privileged sink was reached, a destination changed) in addition to the words used to ask for it, and never let an authority claim from an untrusted channel unlock the very channel it came from.

3. Destructive write: protected state gets overwritten or deleted

Same shape as confused deputy, aimed at deletion or overwrite instead of disclosure. The pretexts are almost always about LEGITIMACY of the change, not permission for it:

• Deprecation framing — "this is old, it's been rotated, replace it" — a claim the agent has no independent way to verify.
• Cleanup framing — "free up space, clear the temp files" pointed at something that isn't actually temporary.
• Chained verify-then-fix — have the agent "check" a fabricated problem, then "fix" it with a write, when the problem never existed outside the request that invented it.

A general-purpose delete/overwrite capability with no path-level allowlist treats every path as equally eligible; the practical defense is a protected-path list a destructive tool checks BEFORE acting, independent of how convincingly the request is worded, plus requiring the "problem" a fix-write responds to be something the system can verify on its own.

4. Untrusted-to-action: the agent obeys content it was only asked to read

This is the classic indirect-injection shape, and it's the one most people have already heard of: a web page, an email, or a document the agent is summarizing contains an instruction written as if it were part of the content — "ignore the above and do X" — and the agent, which has no reliable way to tell "content to describe" apart from "instructions to follow" once both are just tokens in its context, does X.

The variations matter because they defeat the OBVIOUS fix (just don't follow instructions in fetched content):

• Nested delegation — the untrusted content doesn't give the instruction directly, it tells the agent to do whatever a SECOND linked or quoted source says, one hop further than a naive taint check looks.
• Cross-channel handoff — the instruction was read on a web page but asks for an action through a completely different tool, outside the scope of a guard that only watches the channel content arrived on.
• Corroboration pressure — the same instruction shows up, reworded, across several untrusted sources at once, because agreement across sources reads as credibility even when every source is equally untrusted.
• Benign-wrapper injection — the actual instruction sits in a footer, alt-text, or a formatting field that both a scanner and a human reviewer tend to skim past.

The structural fix: taint has to propagate through every hop of delegation, apply to whatever tool the agent uses next regardless of channel, and never gain authority just because more untrusted sources happen to agree with each other.

Why the taxonomy, not a prompt list

A collection of jailbreak strings has a shelf life measured in days — the moment one is seen, it gets patched, and a slightly reworded variant slips through again. A taxonomy of MECHANISMS doesn't expire the same way: "per-call scanning misses split-secret staging" is still true after any specific wording built on it stops working.

That's the frame we used to build the open dataset: 24 patterns, 4 categories, and for every one of them the underlying mechanism it exploits and a concrete mitigation — reference material for red-teaming a tool-using agent or building a defensive checklist for one, not a payload library. It's compiled against the predicate taxonomy used in current live agent-security evaluations and cross-referenced with the published academic lineage (AgentDojo's tool-use attack suite, InjecAgent's indirect-injection taxonomy), and every pattern is written generically from scratch rather than copied from any one benchmark's scored strings.

The full dataset (CSV, methodology, and mitigation-per-pattern) is published on Kaggle under CC BY 4.0, free to use for a hackathon red-team suite, a classifier's training labels, or a defensive checklist for your own MCP server or agent stack.

This is an active research area for us, not a one-off post — see our ongoing security-research competition work for what else we're building on the same problem.