Query-agnostic injection: hijacking coding agents whatever you ask
A late-2025 paper showed a payload planted in a coding agent's tool descriptions fires under any user request — because it exploits the invariant context, not the query. A June 2026 defense fights back at the syntax-tree level.
What is this?
Most indirect prompt injection studies inject a malicious instruction and then hope the user’s task is close enough for it to trigger. QueryIPI, described in a paper first posted to arXiv on October 27, 2025 (2510.23675), flips that assumption. It builds a payload that fires regardless of what the user asks the coding agent to do. The authors call this query-agnostic indirect prompt injection, and present it as the first such method aimed at realistic coding agents.
The trick is to stop targeting the part of the prompt that changes — the user’s request — and target the part that never changes: the agent’s system prompt and tool descriptions. Those are loaded on every turn, so a payload anchored there is present for every task, not just the one the attacker guessed.
How it works
A coding agent assembles its context from three layers: a fixed system prompt, a set of tool descriptions (increasingly delivered over MCP), and the variable user query. QueryIPI uses a tool description as its injection channel. Because that description is read into the model’s context on every invocation, an instruction hidden there sits next to the agent’s real orders permanently.
The hard part is making a single description reliably override arbitrary user intent. QueryIPI does this with an iterative, prompt-based search: it repeatedly refines the malicious description, measuring whether the agent follows it across a spread of unrelated user tasks, and keeps the variants that generalize. The paper notes this search becomes tractable thanks to a common weakness — coding agents tend to leak their own internal prompt, which turns a blind black-box guessing game into a constrained, near-white-box optimization. The concrete strings are withheld here; the mechanism, not a copy-paste payload, is the point.
The result is a poisoned tool that behaves normally on inspection but steers the agent toward the attacker’s action — for instance running a shell command — no matter whether the user asked it to refactor a function, write a test, or explain a file.
Why it matters
Coding agents are a near-perfect fit for Simon Willison’s lethal trifecta: they hold access to private source and secrets, they ingest untrusted content (dependencies, tool outputs, fetched files), and they can act via shell and filesystem. Query-agnostic injection removes the attacker’s biggest source of unreliability. They no longer need the victim to phrase a request a particular way; any interaction with the poisoned agent is an opportunity.
It also relocates the risk into the supply chain of tool descriptions. A single malicious or compromised MCP server, a rug-pulled tool, or a poisoned marketplace entry can carry a payload that works against every downstream user and every task. That is a very different threat model from a one-off document that has to line up with a specific query.
Defenses
The reflex fix — filtering the user’s message — misses the point entirely, because the payload lives in the tool layer, not the query. Defenders should instead:
- Treat tool descriptions as untrusted input. Pin and review descriptions, diff them on every update to catch rug-pulls, and prefer signed or attested tool servers over anonymous MCP endpoints.
- Apply architectural separation. Shell and filesystem capability should be activatable only in response to verified-owner instructions from a trusted channel — never off the back of content or descriptions retrieved from external sources. This is the Agents Rule of Two applied concretely: don’t let untrusted input and a sensitive capability share a context without a human gate.
- Reduce prompt leakage. Since the attack’s search is bootstrapped by the agent exposing its own system prompt and tool schema, minimizing that leakage raises the attacker’s cost.
- Add code-context detection. A June 2026 defense, CodeSentinel (2606.19235, posted June 2026), targets exactly this surface. It treats injection in code as a sanitization problem at the level of individual concrete-syntax-tree nodes, combining static structure, node-level likelihood anomalies, and logits-level behavioral influence. The authors report it outperforming earlier defenses (CodeGarrison, DePA, KillBadCode) across six recent attack families.
No single layer is sufficient; the durable answer is keeping untrusted description content away from privileged action.
Status
| Item | Detail |
|---|---|
| Attack (QueryIPI) | arXiv 2510.23675, first posted Oct 27, 2025 |
| Injection channel | Tool descriptions (invariant context) |
| Key enabler | System-prompt / tool-schema leakage in coding agents |
| Defense (CodeSentinel) | arXiv 2606.19235, posted June 2026; CST-node sanitization |
| Affected class | LLM coding agents with tool/MCP access and shell capability |