Sentry's own engineering leadership looked at a live, working exploit running against their customers' AI agents, told the researchers it was "technically not defensible," shipped a content filter for one specific payload string, and called it a day. I'll grant them the first half of that, sincerely: it isn't their bug, and I'll explain in a minute why it isn't. But a one-string filter against an entire class of attack is a shrug with a changelog entry, not a fix.
Here's what they were shrugging at. Tenet Security's Threat Labs published research showing how a single fake Sentry error report hijacked the AI coding agent inside a $250 billion Fortune 100 company, then did the same thing to more than 100 other organizations across six continents. The attack, which Tenet calls Agentjacking, needed no breach, no stolen credentials, and no phishing email. An attacker posts a crafted error event to Sentry using a public DSN, the same write-only credential Sentry intentionally embeds in frontend JavaScript on countless production websites. The error carries a fake "Resolution" section formatted to look exactly like Sentry's own remediation guidance. A developer asks their coding agent to triage the bug, the agent reads that fake resolution as a trusted instruction, and it runs the attacker's code, with the developer's own credentials, on the developer's own machine. Tenet found 2,388 organizations exposed and confirmed agent execution at more than 100 of them, spanning finance, healthcare, government, and a cloud security vendor that should've known better.
Not a Sentry Bug. A Property of How Agents Are Built.
None of this needed a clever exploit, and that's the uncomfortable part. Any AI coding agent connected through MCP treats whatever a tool returns as authoritative system output, the same way it'd treat a developer's own typed instructions. The agent's got no way to tell the difference between an error message generated by a real application crash and one an attacker typed into a public API. That's how MCP-connected agents are built, full stop, not a Sentry bug, and it shows up anywhere an agent reads externally influenced data and acts on it.
So Sentry's diagnosis was correct. What I can't get past is what they did with it. If you're sitting on a mechanism that turns your product into a delivery vehicle for arbitrary code execution at a couple thousand of your customers, "technically not defensible" is the beginning of the conversation, not the end of it. Filtering one string is filtering one string. The next payload doesn't use that string.
Sandboxing and Prompt Defenses Both Failed
Tenet ran the payload against Cursor, Claude Code, and Codex; eighty-five percent of agents executed it. Sandboxing didn't help. A network-restricted CI agent running inside a CircleCI pipeline got hit anyway, because the malicious instruction rode in through data the agent was specifically asked to read, not through some open port an EDR tool would flag. Prompt-layer defenses failed too. Tenet tried telling agents explicitly, through system prompts and skills, to ignore untrusted data, and the agents executed the payload regardless.
Every step in that chain is authorized by design. EDR, WAF, IAM, and the firewall all watch it happen and see nothing wrong, because nothing wrong happened. A developer asked for help and got it.
Air-Gapped Closes the Cloud Category. It Doesn't Close This One.
This is where the sovereignty argument's got to be precise instead of convenient, so I'll draw the line where it belongs even though it costs me. Running your AI agent on hardware you own, inside a network you control, with no cloud provider sitting between your prompts and the model, closes off an entire category of exposure: nobody's harvesting your queries for training data, nobody's logging your proprietary source code on someone else's servers, and a breach of OpenAI's or Anthropic's infrastructure doesn't touch you.
But Agentjacking doesn't care whose GPU is doing the inference. If your local coding agent still queries a public Sentry instance over MCP, the same fake resolution gets read the same way and the same npx command runs with your developer's same credentials. Air-gapped hardware solves the cloud exfiltration problem. It doesn't, by itself, solve the problem of an agent that can't tell trusted data from an instruction. Anybody selling you otherwise is selling.
The Missing Layer: Trust Gated by Origin, Not Appearance
The piece that's missing across the entire industry, mine included, is a layer that decides whether an agent's allowed to execute something based on where that something came from, not just what it looks like. Markdown formatted to resemble system output is going to keep fooling models trained to follow instructions wherever they find them. That's a property of how these models reason, not a configuration error somebody's going to patch away.
I've been building Lamprey MAI around exactly that gap, an inference governance layer that gates trust at the architecture level instead of hoping the model behaves. It isn't finished, and nobody serious should claim a governance layer "solves" prompt injection. What it can do is shrink the blast radius and put a checkpoint between an agent's decision and its execution, which is more than most stacks have today. That's the honest size of the claim and I'm not going to inflate it.
What to Ask Any AI Vendor Right Now
If you're a tribal government, a law firm, or a hospital system evaluating AI tooling, air-gapped is necessary and it isn't sufficient. Ask any vendor, me included, what their agent's allowed to execute and who decided it could. Ask whether the agent treats every connected tool the same way it treats a developer typing at the keyboard, because Tenet just proved most of them do. That single question'll tell you more about a vendor's security posture than any compliance checklist they hand you.
Then go look at your own site. The Sentry DSN sitting in your website's JavaScript right now is exactly the kind of public, "safe by design" credential this attack runs on. Check it before somebody else does.
I don't have a clean answer to Agentjacking, and neither does anyone else. What I do have is hardware that keeps the rest of your exposure off someone else's cloud while the industry figures out the next layer. That's a smaller promise than the one Sentry declined to make, and it's one I can keep.