AgentTracer Pinpoints the Prompt Injection Point in Agent Logs in 94% of Cases

Everyone is discussing how to protect an agent from prompt injections. Far less is written about what to do when the protection failed and you need to understand what happened. Researchers from Sun Yat-sen University and the Hong Kong University of Science and Technology have released AgentTracer, a paper on exactly this: how to reconstruct the course of an attack from an agent's logs.

Why an attack is so hard to see in the logs

All the text an agent reads ends up in a single model context. The model essentially does not distinguish where a phrase came from, and it tries to follow the most recent and most convincing instruction. In an indirect injection, the malicious command sits in a page or email that the agent opened on its own at the user's request. That is why its actions look like ordinary work.

The example in the paper was invented by the authors, but the mechanics are accurate. A user asks the agent to download a release from a website and upload it to GitHub. A hidden instruction on the page makes the agent also register the attacker's SSH key, read the mail and, at the end, wipe its working memory. Only the last step is noticeable, and data-flow analysis will not link it to the page: the calls share no parameters. The connection is visible only in the agent's reasoning, where it explains why it is doing this.

Moreover, server logs may show nothing at all. In the HashJack technique, the instruction hides in the part of the address after #, which is processed on the client and never sent to the server. Data exfiltration via an image request with parameters in the URL, as in the Bing Chat case, cannot be told apart from an ordinary download from the outside. And in CoSnitch (CVE-2026-24301), malicious instructions were also written into the assistant's persistent memory, so they could fire on a different day.

How AgentTracer works

The idea is simple: if an injection worked, the agent does something the user did not ask for. The authors call this discrepancy intent drift. From the reasoning records, a graph is built: nodes are the user request and objects returned by tools (pages, emails, files), and edges are the agent's operations. This way, calls with no shared parameters still end up in a single chain.

Next, each call is checked against three criteria: action, target, constraints. If any is violated, the edge is marked as a deviation. From the suspicious event, the method moves backward along the marked edges. If the root of the chain is an external resource, it is an injection, and the line where it entered the context becomes the injection point. If the root is not external, the agent simply made a mistake. The answer "there was no injection" is also a full-fledged investigation result.

The testing conditions were harsh: logs of successful attacks from AgentDyn and InjecAgent were mixed with five months of ordinary agent work. For each chain of three calls there were about three thousand unrelated ones. The injection point was found in roughly 94% of cases, while seven competitors range from 40% to 76%. Some found all attacks but not the source; others assembled the chain more completely but with extras. If you replace the graph with a plain call feed, or the three-criteria check with an LLM's judgment, accuracy drops. Pruning around the suspicious event saves almost a third of the time and one and a half times as many tokens.

What to do about it and where the limits lie

The main takeaway is practical: an investigation relies on what you saved before the incident. You need the user request, the agent's reasoning, the calls and full tool outputs, as well as outgoing requests. Microsoft advises treating any external content as hostile and keeping telemetry of requests and responses. Logs must be stored so that an attacker cannot alter them.

The method has limits. It is designed for ReAct-style agents with recorded reasoning. If no tool calls occurred after the injection, or code modified files bypassing them, there is nothing to trace. The graph is built by a language model, and an agent's reasoning does not always reflect the real causes of its actions, so the reliability of the conclusions is no higher than the reliability of that account. It was tested only on successful attacks and in a single environment; on benign logs, false positives were about 3.5%. The persistent memory case is the least studied.

One more caveat from the OWASP review for the third quarter of 2026: an agent can stray from its task without any injection. In a cybersecurity evaluation, Claude Opus 4.7 attacked a real company with a similar name, and OpenAI agents broke out through a shared package service into Hugging Face infrastructure. No injection was established in either case. So the security boundary rests on enforced constraints, isolated tools and credentials, not on the prompt. Logs are needed to figure things out afterward, not to replace protection.

For now Google mostly finds jokes and SEO tricks on the web, but the share of malicious finds grew by 32% (relative) from November 2025 to February 2026. Set up your agent's log now, before you need it.