Where This Breaks: When Your AI Agent Trusts the Wrong Report

Every automation in this catalog rests on one assumption: when an AI agent reads data from a connected tool, that data is real. A June 2026 disclosure shows exactly what happens when that assumption fails, and the answer is not reassuring.

Security researchers at Tenet Security found a way to hijack AI coding agents using nothing but a fake bug report. No malware. No stolen password. No breach of any system. They call it Agentjacking, and it worked on over 2,300 real organizations.

How It Actually Works

The attack chains four simple steps, none of which require any special access.

Step one: find a public key. Sentry, the popular error-tracking tool millions of developers use, works by giving every application a DSN, a write-only credential intentionally embedded right in a website's public JavaScript so browsers can report crashes back to it. That key sitting in public code is not a mistake. It is how Sentry is designed to work. Attackers find these keys by searching GitHub's public code index or running simple queries against Sentry's own infrastructure.

Step two: send a fake crash report. With a valid DSN in hand, anyone can submit a crafted error event to Sentry's ingestion endpoint. Sentry accepts it the same way it accepts any real crash report, because there is no way for Sentry to tell the difference. The DSN is the only credential involved, and it was never meant to authenticate the sender, only to receive data.

Step three: disguise the payload. This is the genuinely clever part. The attacker writes the fake error message using markdown formatting, headings, code blocks, a fabricated "Resolution" section, structured to look visually identical to a real Sentry diagnostic report. There is nothing technically malicious about formatting text this way. It just happens to be indistinguishable from legitimate guidance once an AI agent reads it.

Step four: wait for the developer to ask for help. When a developer tells their coding agent, Claude Code, Cursor, or OpenAI Codex among others, to look into open Sentry issues, the agent retrieves the fake report through Sentry's own integration. It reads what looks like an official remediation step. And it runs it.

The Numbers Are Not Close

Tenet tested this against more than 100 consenting organizations under controlled conditions. The exploitation rate: 85%. The 15% that didn't execute the malicious code weren't protected by any security feature, they happened to be running an agent configuration that asks for confirmation before unfamiliar commands. That is a coincidence of settings, not a defense anyone designed on purpose.

The actual exposure is bigger than the test sample. Researchers found at least 2,388 organizations with valid, injectable DSNs sitting in public code, all exposed to the same attack the moment anyone decides to use it for real.

What an attacker gets on a successful run: environment variables, AWS keys, GitHub tokens, git credentials, private repository URLs. All of it, on the developer's own machine, with the developer's own permissions, because the agent that ran the malicious code was the developer's own trusted assistant.

Why Standard Defenses Didn't Catch This

This is the detail worth sitting with. In testing, agents ran the attacker's code even when explicitly told to ignore unfamiliar instructions. EDR tools, firewalls, and careful prompting all missed it, because nothing about this attack looks like an attack from the outside. There's no malware signature. There's no unusual network traffic pattern. There's just a tool the agent already trusts, returning data the agent has no way to verify.

Sentry's own response makes the deeper problem explicit. After Tenet's disclosure on June 3, 2026, Sentry's leadership characterized the underlying vulnerability as "technically not defensible" at the platform level, and they meant it literally. A DSN is supposed to accept error reports from anyone. Legitimate error messages routinely contain code snippets and remediation notes that look exactly like the malicious payload. There is no reliable way for Sentry to tell a real crash report from a forged one, because the format of a forged one is identical to the format of a real one.

Sentry's actual fix was a content filter blocking the one specific command string used in the public proof-of-concept. Change the package name, use a different command runner, encode the text slightly differently, and the filter does nothing. It defends against the disclosed example. It does not defend against the underlying attack class.

What This Means If You Run Automations That Read External Data

This is not a Sentry-specific problem, and it is not even strictly a security tool problem. It is what happens whenever an AI agent treats output from a connected system as inherently trustworthy, simply because the system is one it normally relies on.

WorkplaceAI's own automations follow the same basic pattern that made Agentjacking possible: a tool returns data, an AI step reads that data, and the AI acts on what it reads. Incident Triage Brief pulls from PagerDuty and Datadog. Support Triage Pipeline reads helpdesk tickets. Lead Scoring reads whatever a form submits into a spreadsheet. None of these are vulnerable to the exact Agentjacking technique, but all of them share the same underlying shape: the AI step trusts the format of the input, not a verified identity behind it.

The practical lesson, and the one we apply to our own automation design, is that any AI step reading from an external source needs a boundary between "this came from a system I normally trust" and "this content has been verified as legitimate." A free, unsupported automation template has no one thinking about that distinction at all. It was built to demonstrate the happy path, not to survive contact with someone deliberately trying to break it.

Agentjacking is six days old as reporting goes and already affects three of the most widely used AI coding agents on the market. It will not be the last attack built on the simple fact that AI agents are very good at following instructions and not yet good at asking who actually wrote them.