An AI agent can be pointed in the wrong direction without anyone telling it to break a rule. Give it a convincing but false result, a misleading hint, or a decoy endpoint, and it may spend its time investigating the wrong thing.

That is the problem examined in AgentLSD: Evaluating AI Security Agents Under Adversarial Task Contamination. The researchers call it adversarial task contamination: changing what an agent sees as evidence while leaving the task itself unchanged.

The distinction from prompt injection is useful. The two can overlap, but prompt injection focuses on instructions embedded in content. Task contamination also includes evidence that makes no request at all. A fake status message can look like confirmation. A decoy route can look like the next useful lead. The agent may reach a bad conclusion on its own.

What the AgentLSD researchers tested

The study used 11 web security Capture the Flag challenges built for the experiment. Each challenge had a known solution and a flag checker, so the researchers could compare an ordinary version with one containing a trap. They evaluated six models in clean conditions. Across those baseline trials, agents captured 41% of the flags.

For the trap experiments, the researchers focused on challenges where agents had shown they could succeed without a trap. They added artifacts to web pages through the Document Object Model, or DOM. Examples included fake flags, misleading hints, decoy endpoints, apparent validation, and hidden cues. The researchers designed the traps so the real vulnerability and intended solution remained the same.

This is not a study of every AI agent or every kind of attack. The testbed was a set of web security puzzles. The traps were static, appeared through the DOM, and were generally activated one at a time. Most experimental cells had five trials; four GPT-5 trap cells had four because of infrastructure problems. The authors did not run significance tests. Those details matter when interpreting the numbers.

Still, the comparison reveals a practical testing issue. Success rates changed by model and challenge. Some model and challenge pairs were little affected, while others followed decoys or submitted incorrect flags. Across successful trap trials, the typical extra effort was about 20 interaction turns and 2,000 reasoning tokens compared with clean runs. That measure applies to agents that still recovered the correct flag. It describes the added effort of successful recovery, not a universal average for all runs.

In other words, a misleading clue can have a cost even when the agent eventually gets the answer right. It may consume time, tool calls, and compute while chasing a lead that should have been checked earlier.

The evidence around an agent is part of the test

Security researchers deliberately inspect material that may have been created or altered by an attacker. The same basic concern can arise in other agent workflows, although the AgentLSD study did not test enterprise systems.

An assistant that reads a support ticket may encounter a false claim that an account was verified. A coding agent may see a test result or code comment that points toward the wrong cause. An operations agent may receive a status message that says a change has completed when the underlying service says otherwise. These are examples to consider when designing assurance tests, not findings from the CTF experiment.

Alongside checking whether an agent follows unsafe instructions, teams need to check whether it can tell a trustworthy observation from a plausible but unverified one.

That calls for tests that vary the quality and consistency of the evidence. A useful scenario might give an agent two sources that disagree, or a success message that conflicts with the system state. The expected behavior should be clear: check an authoritative source, explain the conflict, or stop before taking an irreversible action.

Questions for an agent evidence test

  • Does the agent distinguish a user instruction from information found in a page, file, log, or tool result?
  • When two sources disagree, which one does it trust, and can it explain why?
  • Does it verify that an action succeeded by checking the resulting state?
  • Can it recognize when an apparent confirmation is only a message, rather than independent evidence?
  • How many times will it pursue an unproductive lead before changing course?
  • If it discovers a clue was false, can it return to the original task and correct its assumptions?
  • Does a decoy increase tool use, elapsed time, or cost even when the final answer is correct?

The AgentLSD paper suggests ideas such as preserving source information, requiring independent evidence before accepting success, and setting limits on repeated unproductive exploration. The authors present these as design implications for future study, not as mitigations validated by their experiments.

Make success depend on evidence, not confidence

A check that asks only whether the agent produced the right final answer can miss how it got there. It can also miss false completion, when the agent says it finished but the system has not changed as expected.

For actions that matter, test the outcome against a trusted source outside the agent's own explanation. If an agent says it updated a record, inspect the record. If it says a test passed, confirm which test ran and what result it returned. If it reports a security finding, check whether the evidence supports that finding.

This does not mean every decision needs a second system or a human approval. The amount of verification should match the possible consequence of being wrong. A low-impact research task can tolerate uncertainty and ask for a review. A workflow that changes permissions, sends money, or closes a security incident needs stronger evidence before it acts.

It is also useful to include effort in the evaluation. A decoy may not change the pass/fail result, but it might cause repeated calls, unnecessary file changes, or long detours. Track those costs alongside task completion. They affect reliability and can create operational risk of their own.

Prompt injection tests need an evidence check too

Prompt injection remains an important risk. Teams testing agents should continue to check whether untrusted content can override their instructions. See what prompt injection is for that threat. The AgentLSD work adds another kind of question: can misleading information change which hypothesis an agent follows, even when the information contains no instruction?

Some of the paper's traps overlap with indirect prompt injection. The authors distinguish the broader contamination problem by including non-instructional cues, such as fake validation and plausible decoy routes. Treating the two as separate test categories can help a team see whether it has tested both instruction handling and evidence quality.

The practical test design will depend on the system. A browser agent, coding assistant, or internal research tool will rely on different evidence sources and have different consequences when misled. Use realistic examples from the system's own logs, APIs, documents, status messages, and retrieved content. The broader guide to testing LLM applications covers related checks across the application.

Testing this well calls for people who understand software test design and how AI agents use tools and evidence. If you work with AI systems or want to build that capability, ASTQB AI Assurance Pro offers a structured path covering ISTQB Foundation Level, ISTQB AI Testing, and ISTQB Testing with Generative AI. Those skills can help you design and evaluate agent tests. Read what the designation covers and the three required certifications to see whether the path fits your goals.