Retrieval-Saturation Tool Attack

Problem

An adversary who can register tools does not need to defeat the agent's selection or output handling; they can attack the retrieval step itself. By crafting a few tools whose embeddings are placed to cover the query space, the attacker makes those tools rank at the top for almost any request, saturating the top-k so the benign tools the agent needs are pushed out and never loaded. The agent then chooses only from attacker-controlled tools, and every selection-time and output-time defense downstream is bypassed because the safe options were never in context to begin with.

Solution

Treat tool retrieval as an attack surface, not a neutral ranking. Vet and trust-rank registered tools so contributions from outside the trust boundary cannot rank as freely as vetted ones, and cap how many of the top-k slots any single contributor or low-trust source can occupy so a few injected tools cannot fill the result. Monitor the embedding space for tools placed to cover the query space — a hallmark of a saturation attack — and exclude or downrank them. Guarantee a path for the benign tools a request needs to reach context, for example by reserving slots for vetted tools or retrieving from a trusted subset first. The retrieval layer itself has to be defended, because selection-time and output-time controls cannot protect tools that were never loaded.

When to use

• Recognising this failure when an agent retrieves tools from a large or open registry and a few sources dominate the results.
• Reviewing a tool-retrieval layer that ranks contributions from outside the trust boundary the same as vetted ones.
• Diagnosing why an agent keeps selecting unexpected tools while the right ones never appear in context.