AgentJacking.
The Trick You Cannot Stop.
The Prize You Can.

In June 2026, researchers hijacked AI coding agents at an 85% success rate by planting a fake bug report. No identity product would have stopped the trick. The reason the attack pays off is the pile of standing credentials the agent was holding. That part is governable.

On June 3, 2026, Tenet Security notified Sentry of a new attack they named AgentJacking, then published the research publicly on June 12. The mechanics are almost dull. The result is not. A researcher plants a fake error in a Sentry project using a public client key. An AI coding agent, wired to Sentry through MCP, picks up that error as a real bug to fix. The suggested fix is a command. The agent runs it. On the developer’s own machine, with the agent’s own access.

Tenet tested it against the leading coding agents and reported an 85% success rate. They found 2,388 organizations carrying the kind of exposed key the attack depends on. The command the agent runs reads what is sitting on the machine, environment variables, the contents of ~/.aws/config, npm tokens, git and Docker credentials, and sends it out.

What is hard to look at is the list of things that would not have stopped it. Not EDR. Not the firewall. Not IAM. Not the VPN. Not a system prompt telling the agent to distrust external input. Every step in the chain was authorized, because the agent was doing exactly what a coding agent is meant to do: read a bug report and act on it.

Sentry was direct about the limit. They shipped a content filter for the one payload string in the proof of concept, then said plainly that the underlying problem cannot be solved where the data comes in. They are right. This is not a Sentry bug. It is a property of letting an autonomous agent act on untrusted input.

Could Arkion Have Stopped It

We will be straight about this, because the honest answer is more useful than a flattering one.

Arkion governs identity. It does not sit inside the agent’s reasoning. It does not read the prompt, inspect what arrives over MCP, or decide which commands the agent runs. So Arkion would not have stopped the agent from being tricked into running that command. Stopping the trick belongs to a different control: validating what crosses the MCP boundary, treating tool output as untrusted, and sandboxing what an agent is allowed to execute. If a vendor tells you their identity product blocks the injection, be skeptical.

So Ask the Better Question

Why does AgentJacking pay off at all?

Because the agent was sitting on long-lived secrets it could read and hand over. A static AWS key in a config file. An npm token that never expires. Git credentials with broad reach. The trick is only the delivery. The standing credential is the prize.

Arkion is built to take away the agent’s own share of that prize: its credential no longer has to be a standing secret. The agent holds a scoped identity of its own, issued by an administrator once the agent is registered, and valid for 10 minutes. Because that credential is short-lived and centrally issued, you revoke the identity at the source (the AI Gateway refuses it from then on) and the short TTL closes the window, instead of chasing a leaked static key for days wherever it was copied. When the agent’s access runs on that identity instead of a static key in a file, the agent’s own credential is worth far less to steal. Run the same command against an agent whose access runs on an identity issued by AgentID, and the agent credential it can hand over is close to worthless: narrowly scoped and about to expire. Coding agents running on a developer’s own machine are not on AgentID’s discovery list today. Other secrets on the box, including the developer’s own keys and tokens, are their own hardening job. What Arkion removes is the standing agent credential that made the agent worth hijacking in the first place.

One caution, so we do not oversell it. Catching this by behaviour is hard. A coding agent that runs a package command and reads local files looks like a coding agent doing its job. Do not lean on anomaly detection to catch AgentJacking. Lean on the two things that hold under pressure: the agent’s own credential is worth far less to steal, and you can revoke its identity the moment you know.

Closing

AgentJacking is not really a Sentry problem, and filtering one payload string will not end it. It is the predictable result of handing an autonomous agent broad, standing access with no governed identity underneath. The same shape recurs in every agentic-system breach we have on file (see FN-01): the access was real, the credential was standing, and no one could see or revoke what happened next.

You cannot un-trick an agent. You can make the agent’s own credential close to worthless and its identity revocable. That is the difference between a stolen agent credential that can stop working within minutes and a static key you are still chasing a year later. AgentJacking is what the disease looks like in production.