A new attack called ToolSiphon can recover an average of 74.3% of the source records sitting behind the knowledge-based tools that LLM agents use to answer questions, according to a preprint posted on arXiv on 31 August 2026 by researchers at Shandong University's School of Cyber Science and Technology S¹P². The attacker sends only queries, no stolen credentials, no direct database access. Just questions, asked in a specific sequence, until the private contents of a tool's underlying files, databases, or search indexes start leaking through the agent's responses. What exactly does this break, and can anything stop it?

My read: This is the first attack I've seen that treats the agent's tool-calling layer as an extraction channel rather than a security boundary. The 74.3% figure is striking, but I'd hold off on panic until the paper clears peer review; the numbers are self-reported, the authors ran their own experiments, and version 1 of a preprint can change substantially. What concerns me more than the headline number is the claim that representative defenses didn't help. If that holds up under review, every team shipping an agent with a proprietary knowledge tool needs to rethink their threat model.

How the attack works

LLM agents commonly connect to knowledge-based tools: search indexes, databases, file stores S¹. A customer support agent might query a product database. A legal research agent might search a case-law index. The agent sends a query to the tool, gets back results, and folds them into its response. That is the normal flow.

ToolSiphon turns that flow into a drain. The core idea is that source content exposed to an agent for legitimate responses can be progressively recovered from its outputs S¹. Ask enough carefully crafted questions, and the agent's answers start to reconstruct the knowledge source behind the tool.

Two problems make this harder than it sounds. First, tool-selection uncertainty: when an agent has access to multiple tools, it might call the wrong one S¹. Second, tool-argument compression: the agent may lose fine-grained query details when it generates the arguments it passes to the tool S¹. Think of it like asking someone to relay a message, but they paraphrase it on the way through and sometimes deliver it to the wrong person.

ToolSiphon solves both. It uses Tool Contrastive Analysis, a signal that steers queries toward the target tool by comparing how different tools respond S¹. Then it uses Evidence Chained Feedback, a method that grounds each new query in facts already extracted from prior responses, gradually expanding what it can recover S¹.

The numbers

Across three types of knowledge-based tools and six domain-specific datasets, ToolSiphon recovered 74.3% of source records on average when the attacker had coarse-grained information about the non-target tools available to the agent S¹. Textual recovery hit 83.2%. Semantic similarity, a measure of how closely the extracted content matches the original meaning, reached 90.2% S¹.

ToolSiphon extraction rates across tools and datasets

Strip away the advantage of knowing about competing tools, and the attack still pulled out 66.3% of source records S¹. That is the number that should worry tool providers: even with minimal prior knowledge, an attacker can recover roughly two-thirds of proprietary content.

The paper also reports that ToolSiphon remained effective against representative defenses and on three real-world agent platforms S¹. The authors do not name the platforms or the defenses in the abstract, and the paper has not been independently verified.

Why this matters now

The agent ecosystem is expanding fast, with frameworks training agents across thousands of real-world tools. The more tools an agent can call, the more knowledge sources it can reach, and the more surface area exists for an attack like this.

The threat is not theoretical for any company that has built a proprietary knowledge tool and exposed it through an LLM agent. A legal tech startup with a custom case-law search tool, a medical AI company with a curated drug-interaction database, a financial services firm with a proprietary market-data index: each is handing an agent access to content that represents their competitive edge. ToolSiphon suggests that access can be siphoned back out through the agent's own responses.

What to do about it

Consider a pathology lab that built a custom diagnostic reference tool for its LLM agent, drawing on years of curated test results and diagnostic criteria. The lab exposes this tool to an agent that clinicians query for second opinions. Under a ToolSiphon-style attack, a competitor could send a stream of diagnostic queries through the agent and gradually reconstruct the lab's reference database, the product of years of clinical work.

The practical steps, based on what the paper reveals:

  • Rate-limit and monitor query patterns. ToolSiphon depends on sending many queries in sequence. Unusual query volume from a single user or session is the most visible signal.
  • Restrict what the agent returns. If the agent echoes large chunks of tool output verbatim, it leaks more. Summarisation or response length caps reduce extraction yield.
  • Treat tool outputs as privileged. The fact that an agent can read a tool's contents does not mean every user should be able to reconstruct them. Access controls should apply at both the tool layer and the agent layer.

One thing to check this week: review the logs on your agent's tool calls. Look for a single user or session sending an unusually high volume of similar queries to the same tool. That pattern is the fingerprint of a query-only extraction attempt.

What we don't know yet

The paper is a preprint, version 1, with no peer review and no independent replication S¹. The 74.3% figure and the defense-bypass claim are self-reported. The three real-world agent platforms are not named in the abstract, so we cannot verify which systems were tested or how they were configured. The representative defenses that failed are similarly unspecified.

We also do not know how the attack performs against the largest commercial agent platforms, which may have their own rate-limiting and output-filtering layers that were not tested.

The next signal: the peer-review process for this paper, likely through a security conference submission in late 2026 or early 2027. If the defense-bypass claim survives review, it changes the threat model for every agent deployment. We will check this claim against the reviewed version when it appears.

If this kind of reporting is useful, subscribe to get the next one delivered.

Sources: S1 — Extracting Knowledge from Tools in LLM Agents · P2 — Extracting Knowledge from Tools in LLM Agents · P3 — yifanfeng97/Hyper-Extract · P4 — LLM Agents Making Agent Tools · P5 — HKUDS/AutoAgent

More from Not A Tech Guy

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.