Agentjacking is one of those security stories that sounds fake until you remember how many "safe" software habits were designed before autonomous coding agents started reading every scrap of operational text as if it came down from Mount Root.

Tenet Security disclosed the attack on June 9, 2026. The ingredients were ordinary: Sentry error tracking, public Data Source Names, the Sentry Model Context Protocol server, an AI coding agent, and a developer asking the agent to investigate unresolved production errors. No password theft. No phishing email. No compromised application server. The attacker only needed a public Sentry DSN, which is the write-only credential many front-end apps intentionally expose so browsers can report errors back to Sentry.

In the pre-agent world, that design made sense. A public DSN lets the application send telemetry. An attacker can submit junk events, but the usual damage is noisy dashboards and annoyed engineers. Once an AI coding agent starts consuming Sentry events through MCP and treating tool output as trusted operational context, that same public write path turns into an instruction channel.

The fake fix

The attack was simple in the deeply irritating way good attacks often are. Tenet submitted crafted Sentry events whose fields contained markdown formatted to look like diagnostic remediation advice. The fake event included a "resolution" step that pointed the agent toward an npm command. When a developer asked the agent to fix unresolved Sentry issues, the agent queried Sentry through MCP, read the malicious event, accepted the fake remediation as part of the tool response, and ran the command.

That command executed with the developer's own privileges. Tenet's controlled package did not steal secrets, but it proved the path to the interesting stuff: environment variables, AWS configuration files, npm credentials, Docker config, Git tokens, private repository URLs, VPN context, and whatever else the developer account could reach. This is the quiet horror of agentic developer tools. They do not merely suggest code. They sit next to terminals, credentials, source trees, build systems, and cloud access, waiting for instructions dressed up as work.

Tenet reported 2,388 organizations with injectable DSNs and said it observed more than 100 controlled agent executions, with an 85 percent success rate against injected errors in its validation set. Those numbers matter less as exact epidemiology and more as proof that the attack condition is widespread. Public Sentry DSNs are not a corner case. Developers asking agents to inspect production errors are not a corner case either.

Why the usual controls missed it

Traditional security tools are trained to look for unauthorized behavior. Agentjacking exploited authorized behavior in the wrong order.

The event submission to Sentry was permitted. The agent's MCP query was permitted. The developer had asked the agent to work on Sentry issues. Running terminal commands may have been within the agent's normal delegated authority. Even the npm download looked like the sort of thing developer workflows do constantly, because the modern JavaScript supply chain has apparently decided that "run remote code as a lifestyle" is fine as long as the package name has enough slashes.

Prompt-layer defenses also struggled because the attacker was not talking directly to the model through the user prompt. The malicious instruction arrived through a tool result. To the agent, it was part of the operational material it had been asked to process. This is indirect prompt injection: the attacker places instructions inside content the AI will read later, and the system fails to keep "data to inspect" separate from "orders to obey."

Sentry reportedly acknowledged the issue but declined to fix it at the root, characterizing the source-side problem as not technically defensible. That response is understandable in the narrow sense: Sentry cannot reliably know which text inside arbitrary user-submitted errors is malicious for every downstream AI agent. It is also exactly why the story belongs here. A tool integration that was harmless enough for human dashboards became dangerous when plugged into agents that can execute actions.

The trust boundary moved

Agentjacking is not really a Sentry bug in the conventional sense. Sentry accepted telemetry through an endpoint designed to accept telemetry. The failure sits in the trust boundary created by agent integrations. MCP made error data available to an AI agent in a form that the agent could act on. The agent then treated that data as if it were trusted guidance from the system, rather than untrusted evidence from the outside world.

Human developers have a crude but useful instinct here. When a stack trace says "run this random npm package," most of us at least squint. AI agents do not squint unless the product forces them to. They can be instructed to be cautious, but the attack worked because the model could not reliably separate a malicious instruction from legitimate diagnostic text once both landed in the same context.

The practical fix is not "write a sterner prompt." The fix is architectural: tool outputs need provenance, action policies, confirmation gates, allowlists, sandboxing, and runtime monitoring. An agent should be able to read a Sentry event without being allowed to execute arbitrary package-manager commands suggested by that event. External text should not get to promote itself from evidence to command.

The lesson

Observability data is no longer passive when agents consume it. Tickets, bug reports, logs, crash reports, docs, GitHub issues, support chats, and monitoring dashboards can all become instruction surfaces if an agent reads them and acts. That is the uncomfortable bit. Companies built years of automation around the assumption that these systems were places to store facts about work. AI agents turned them into places where attackers can write down what they want the agent to do.

Agentjacking is useful because it is not cinematic. Nobody kicked down a firewall. Nobody cracked encryption. The attack used public plumbing, a normal developer workflow, and an agent trying to help. That is precisely why it is dangerous. The blast radius follows the authority given to the agent, and developer authority is rarely small.