Agentjacking: how one fake error report hijacks your coding agent

TL;DR

• Agentjacking is an attack in which someone injects a fake error report into your monitoring, so that an AI coding agent asked to fix the error runs the attacker's instructions instead.
• It works because a public Sentry DSN, a key that is meant to sit in frontend code, is all you need to submit an error. No phishing, no break-in.
• The agent cannot tell data from instructions. A prompt telling it to ignore untrusted data did not stop the attack in the researchers' tests.
• Everything an agent reads is untrusted input, including your own tooling. Test what it reads, what it runs without confirmation and which secrets sit on that machine.

A developer opens a coding agent and types "fix the open errors in Sentry". The agent reads a report with a tidy "Resolution" section and a command, and runs it. Except that error never came from the application. An attacker put it there. That is agentjacking, and in June 2026 Tenet Security showed it worked against most of the coding agents they tried.

We test that chain in a penetration test: which sources the agent reads, what it runs while nobody is watching, and what sits on the laptop it runs on. In a red team engagement we go one step further and try to get an error report in from the outside, one that a real agent on your team gets to see. The exercise does not need to be spectacular to hurt.

What agentjacking is

Sentry collects errors from applications. Every application submits those errors with a DSN, an address with a key in it. The DSN is public on purpose: it sits in your website's JavaScript because every visitor's browser has to be able to report a crash. So anyone who knows the DSN can submit an error of their own, and Sentry processes it like any real crash.

The Tenet Security researchers put a piece of text in such a fake error that looks like a fix: a short explanation and a command that installs a package. When a developer later asks a coding agent to clear the open errors, the agent fetches the report through the Sentry integration (an MCP server), reads the command and runs it. The package belongs to the attacker. The code runs with the developer's privileges, next to everything stored on that machine: cloud keys, GitHub tokens, access to internal networks.

According to the researchers, they found 2,388 organisations with a usable DSN, and the attack succeeded in about 85 percent of their tests across more than a hundred targets. We have not measured those numbers ourselves. The pattern is what keeps us busy.

Everything an agent reads is untrusted input, including your own tooling

When people hear prompt injection they picture strange web pages or emails from outside. This attack arrives through your own monitoring. The agent trusts Sentry because Sentry is your tool, and the data looks the way Sentry always shows it. That is the whole point: the agent cannot see whether an error came from a real crash or from an attacker.

Logs, monitoring, tickets, bug reports, comments on pull requests, error responses from an API: anything an agent pulls in may have been written by someone else. The question is not whether you trust those sources. The question is who can write to them. We wrote before about why prompt injection does not go away with one line in a system prompt, and about how attackers abuse MCP to get in through such an integration. Agentjacking is both at once.

What to test before an agent reads your logs

A pentest of a coding agent does not start with the model. It starts with five questions you can ask yourself as well.

Which sources does the agent read? Every MCP server, every tool, every integration that returns data. For each one: who can write to it from the outside? For Sentry that is anyone with the DSN, and the DSN is on your website.

Which commands does it run without confirmation? Many agents ask permission the first time and remember the answer. A developer who once clicked "always allow" for npm or pip has allowed every attacker's package along with it.

Which secrets sit on that machine? Cloud keys in environment variables, tokens in config files, SSH keys, session cookies. In the hijacked environments from the research, live cloud keys and GitHub tokens were there for the taking.

What privileges does it have? Does the agent run as the developer, with access to internal networks and production repositories? We covered AI agents with production access earlier; a coding agent on a laptop often has more access than those agents do.

Can someone on the outside submit error reports? Which DSNs, API keys and webhooks sit in public code, and what happens when we send a message to them? That is the step a red team takes: we submit a harmless report and watch whether it reaches an agent.

Measures that hold up

Least privilege: run a coding agent in an environment without production keys and without access to your internal network. What is not there cannot be stolen.

Confirmation for commands: every command that installs, executes or sends something out gets a click from a human. No "always allow" for package managers. That feels slow. It is faster than rotating a stolen cloud key.

Shielded secrets: keys in a vault the agent cannot read, not in environment variables or dotfiles. Short lifetimes, so a leaked key loses its value quickly.

Runtime monitoring: log what the agent executes and which connections it opens. The attack in the research contained nothing a virus scanner or firewall recognises. The only place you still see it is the moment the agent runs the command.

And that line "ignore untrusted data" in your system prompt? Keep it. Do not count on it.

Validation stays human work

A scanner does not find agentjacking. There is no vulnerability in the classic sense, because every step works as designed. The DSN is supposed to be public, Sentry is supposed to accept reports, the agent is supposed to read errors and fix them. Only when someone tries the chain as a whole do you see where it breaks. Our ethical hackers do that in an AI systems penetration test: we rebuild the chain in your environment with a harmless payload and write down how far we get. A person reproduces and confirms every finding.

Frequently asked questions

What is agentjacking?

Agentjacking is an attack in which an attacker places fake data, such as an error report, in a source an AI agent reads. The agent carries out the injected instructions as a real task, with the user's privileges.

Why can an attacker submit error reports at all?

Because the key used to report errors (the DSN, in Sentry's case) is public by design. It sits in your website's JavaScript so that every browser can report a crash. Anyone who reads it can submit reports too, with no further authentication.

Does telling the agent to ignore untrusted data help?

Not reliably. In the researchers' tests, agents ran the command even with that instruction in the prompt. A language model weighs all the text it sees, and an instruction and a fake error report compete with each other.

Is agentjacking the same as prompt injection?

It is a form of it, indirect prompt injection. What differs from the familiar examples is the source: not a stranger's web page, but your own monitoring tool, through an MCP integration the agent trusts.

What does a penetration test of a coding agent cover?

Which sources the agent reads and who can write to them, which commands it runs without confirmation, which secrets and privileges sit on the machine, and whether someone on the outside can submit error reports. See our AI systems penetration test.

Should I stop using coding agents?

No. Put them in an environment without production keys, make them confirm every command and log what they do. Then test whether that holds.

Related services and resources

If you want to know whether your coding agents can be hijacked through the tools they read, our AI systems penetration test is the place to start; it belongs to our wider penetration testing services. If you want the whole chain tried from the outside in, we do that in a red team engagement. For background, read our posts on prompt injection, how attackers abuse MCP, AI agents with production access, the agentic AI supply chain and hijacking an AI browsing agent.