Parameter Poisoning: The Prompt Injection That Keeps the Right Tool and Changes the Argument

Most prompt injection defenses ask one question: did untrusted text make the agent do something new? A November 3, 2026 arXiv paper, "Right Tool, Wrong Parameters: Defending LLM Agents Against Parameter Poisoning," asks a different one. What if the agent makes the exact call the user wanted, and an attacker only changes one argument, such as who receives the money? The authors call this parameter poisoning. On their benchmark, it succeeded in 93.06% of cases against an undefended agent built on Qwen3.6-27B.

I read the full HTML version of the paper (arXiv 2611.04673v1, cs.CR). I did not run the code or the benchmark. All numbers below are the authors' own results, from a single preprint that has not been peer reviewed as far as I can tell.

What the attack is

The paper's example is a banking task. The user asks the agent to pay a bill. The agent reads a document, finds a payee record, and calls the transfer tool. An attacker who controls some text the agent reads, such as an email body, a review or a transaction note, plants an account number. The tool call is the expected one, with the attacker's account as the destination, and the protected payee record is unchanged.

The authors say this is hard to catch for two reasons. No new action appears, and parameter changes are a normal part of real tasks. Their threat model gives the attacker control over external content only. The attacker cannot change the user's request, the system instructions, the tool interfaces or the protected records outside their permission. A call counts as a successful attack when an attacker-intended value shows up in an executed tool call.

What the defense does

The proposed defense, AuthorityFlow, sits at the orchestration layer. It can see the user task, the tool specification, the interaction history and the pending call, and it can block or repair the call. It has three stages:

• Task-aware authority. It splits each tool output into spans with the same provenance and gives each a base authority of High, Low or Unknown. Claims inside untrusted text do not raise a span's authority. Then it compiles the user task, tool specs and spans into a relation saying which source may support which fact, and freezes that relation before any parameter is checked.
• Parameter support tracing. For each argument, it finds the facts the value depends on and the evidence for each fact, keeping the original source span.
• Verification. A fact passes only when the evidence semantically supports it and the source is authorized for that fact under the frozen policy. The call runs only if every task-critical parameter passes.

The key idea in the paper is that trust depends on the task, not only on the source. The same document can be fine for identifying an entity and not allowed to set a payment destination.

The benchmark and the numbers

The benchmark, FactAuthBench, extends AgentDojo with four scenarios (Banking, Slack, Travel, Workspace) and 144 paired cases. Each pair has a clean run and an attack run for the same user task. Agent models are Qwen3.6-27B, Llama-3.3-70B and GPT-4o, and Table 1 reports Qwen3.6-27B and GPT-4o. The verifier model is Qwen3.6-27B by default.

From Table 1, with benign utility (BU), utility under attack (UA) and attack success rate (ASR):

• No defense, Qwen3.6-27B: BU 90.28%, UA 3.47%, ASR 93.06%. On GPT-4o: BU 81.94%, UA 27.78%, ASR 57.64%.
• Spotlighting, Qwen3.6-27B: ASR 69.44%. Sandwiching: 72.22%. MELON: 79.17%.
• DRIFT, Qwen3.6-27B: ASR 39.58%, BU 86.11%.
• CaMeL with policies: ASR 0.69% on Qwen3.6-27B and 2.08% on GPT-4o, but BU falls to 43.75% and 39.58%.
• AuthorityFlow: ASR 9.03% and BU 82.64% on Qwen3.6-27B, ASR 5.56% and BU 73.61% on GPT-4o.
• AuthorityFlow with a purification step: UA rises to 58.33% on Qwen3.6-27B and 60.42% on GPT-4o, with the same ASR.

With 144 cases, one case is about 0.7 percentage points, so small gaps between methods are within a few cases. That is my arithmetic, not a claim from the paper.

What the ablations say

On Qwen3.6-27B, removing source authorization raises ASR from 9.03% to 62.50%. Removing semantic support raises it to 28.47%. Removing parameter support tracing lowers BU to 56.94%. Removing the task-use authorization lowers BU to 59.72% while ASR stays near 7.64%. The authors read this as: source authorization blocks attackers, and task-aware authority avoids over-blocking.

The verifier matters too. With Llama-3.3-70B as the verifier, ASR is 24.31% and BU is 62.50%. With GPT-4o, ASR is 15.28% and BU is 75.69%. The defense is only as good as the model doing the checks.

What the authors say it does not solve

The limitations section names three things. Ambiguous user input or incomplete tool metadata can make the authority boundaries uncertain. The design uses a separate verifier model, so its robustness against complex adversarial reasoning and its inference cost remain open. And the paper focuses on detecting and intercepting unauthorized parameter influence, with task recovery left as future work.

What I would check

These are my untested suggestions for anyone building agents with tools that move money, send messages or change records.

• List the tool arguments where a wrong value costs real money or trust: recipients, amounts, destinations, dates. Those are the ones to guard first.
• For each, write down which source is allowed to set it. If the answer is "the user's request or a protected record," then a value that traces to an email body should fail.
• Log where each argument value came from, not only the call. Without provenance, you cannot tell a legitimate change from a poisoned one.
• Add a confirmation step for sensitive arguments that did not come from the user message. This is cheaper than a verifier model and may catch the example in the paper.
• Test with paired runs, as the paper does: same task, once clean and once with attacker text in a document the agent reads.

What I would not conclude

• That AuthorityFlow is ready to deploy. It is a preprint, evaluated on 144 cases in one benchmark, and I found no independent replication.
• That the numbers carry over to your agent. Results differ a lot between the two models in the table.
• That CaMeL is a bad choice. Its low ASR comes with a large drop in benign utility in this benchmark, which may depend on how the policies were set up.
• That the attack is new in practice. The paper shows it works in a benchmark. I have no data on how often it happens in production.

Frequently asked questions

What is parameter poisoning?

An attack where attacker-controlled content changes one or more arguments of a legitimate tool call, such as a recipient, without adding a new action.

How is it different from ordinary prompt injection?

Instruction-level injection tries to make the agent do something new. Parameter poisoning keeps the intended action and changes a value inside it.

What is AuthorityFlow?

The paper's defense. It builds a task-specific trust map over information sources, traces where each argument value came from, and blocks a call when the supporting source is not authorized for that argument.

What is FactAuthBench?

A benchmark the authors built on AgentDojo with 144 paired clean and attack cases across Banking, Slack, Travel and Workspace.

How well did it work?

On Qwen3.6-27B, attack success fell from 93.06% to 9.03%, and benign utility went from 90.28% to 82.64%. On GPT-4o, ASR was 5.56% with the defense and 57.64% without.

Does a stronger input filter stop this?

In the paper's results, input-level defenses such as Spotlighting and Sandwiching still left attack success rates between 52% and 72% on the two models.

Did you run it?

No. I read the paper and its tables. I did not run the benchmark or the code.

Sources

All read on November 4, 2026.

• Right Tool, Wrong Parameters: Defending LLM Agents Against Parameter Poisoning, arXiv 2611.04673v1 (abstract)
• Same paper, HTML version

Not read: the appendix, the cited baseline papers, the AgentDojo benchmark itself, and any released code.