For years, your monitoring stack has been the most boring software you own. Sentry catches the exceptions. Datadog graphs the latency. Jira holds the tickets. PagerDuty wakes someone up at 3 a.m. None of it touches production directly. It just watches. That was the whole point — read-only plumbing you could safely ignore.
That assumption broke this month. According to VentureBeat's security reporting, researchers demonstrated an attack that hijacked Claude Code at a Fortune 100 company — and the entry point was a single, forged error event in Sentry. No breach. No stolen password. Just a crafted message sitting in a tool everyone treats as harmless. The moment an AI coding agent read it, the agent did what the attacker said.
The uncomfortable part is the generalization. Sentry was the proof of concept, not the boundary. Once you wire an AI agent into Datadog, Jira, or PagerDuty so it can “investigate” issues, every alert payload, ticket comment, and stack trace those tools ingest becomes a channel for untrusted instructions. Your observability layer just quietly became an attack surface for the agents you gave the most privilege to.
Key Takeaways
- A fake Sentry error report — injected using nothing but a public DSN key — tricked Claude Code, Cursor, and Codex into running attacker-controlled code with an 85% success rate in testing.
- The flaw is architectural: AI agents treat data pulled from connected tools (via MCP) as trusted instructions, not as untrusted input that happens to contain text.
- Datadog, Jira, and PagerDuty share the exact same exposure — any monitoring tool that ingests attacker-reachable text and feeds it to an agent is in scope.
- This is not the OAuth-scope problem. The mechanism here is poisoned content, not over-broad permissions — and most teams have no control for it.
- The fix is a content-trust boundary plus credential isolation between your integrations and any agent that can run commands.
- Mid-market dev shops, manufacturers, and MSPs in Fort Wayne and Northeast Indiana are bolting agents onto Atlassian and Datadog stacks right now — usually with no boundary at all.
This is the kind of failure mode we sit between every day with a Secure AI Gateway: untrusted integration data on one side, an agent holding real credentials on the other. Below is what actually happened, why every monitoring tool inherits the same flaw, and a concrete connected-tool audit you can run this week.
What Actually Happened: How a Fake Sentry Error Hijacked Claude Code
The attack has a name now — “agentjacking” — and the mechanics are almost insultingly simple. The team at Tenet Security (researchers Ron Bobrov, Barak Sternberg, and Nevo Poran) laid out the full chain.
Sentry's error reporting works through a DSN — a connection string that client-side JavaScript uses to POST error events. By design, that DSN is public; it ships in your website's front-end code so browsers can report crashes. Anyone who views source can read it. Normally that is fine, because the worst an attacker can do is submit junk error events.
Except now a developer asks their AI coding agent to “look into the Sentry issues.” The agent connects to Sentry through the Model Context Protocol (MCP), pulls the error events, and reads them as context. And here is the break: the attacker has already POSTed a forged error whose body is carefully formatted markdown that imitates Sentry's own “Resolution” guidance — complete with a recommended fix that says, in effect, run this command to diagnose the issue. To the agent, that injected text is structurally indistinguishable from legitimate remediation advice. So it runs the command, with the developer's full privileges.
The numbers are what make this more than a lab curiosity. The researchers identified 2,388 organizations with exposed, injectable DSNs, 71 of them in Tranco's top-one-million sites. In controlled testing the injection achieved an 85% success rate across Claude Code, Cursor, and OpenAI Codex, and they confirmed more than 100 AI agents executing the payload across real companies. As The Hacker News reported, the cleanest summary of the whole thing is the researchers' own line: “The attacker never touches the victim's infrastructure. The malicious instruction arrives disguised as a legitimate ‘Resolution’ inside an ordinary error.”
The headline victim was a Fortune 100 technology company valued at roughly $250 billion, whose coding agents on corporate devices confirmed execution of the test payload. Disclosed to Sentry on June 3, 2026, the response was notable: Sentry acknowledged the issue but declined a root-cause fix, calling the attack class “technically not defensible” and pointing to model-vendor middleware as the appropriate layer. They shipped a reactive content filter for one specific payload string. The structural problem remains.
This is the next chapter in a story we have been tracking all spring — the same pattern that drove our Fort Wayne vendor audit of leaking coding agents. The agents keep changing. The lesson does not.
Why Is Your Monitoring Stack Now an Attack Surface?
The instinct is to read “Sentry vulnerability” and wait for Sentry to patch it. That instinct is wrong, and understanding why is the whole point.
Sentry didn't do anything unusual. It accepts external input (error events) and surfaces that input to an AI agent through MCP. That is the normal job of a monitoring tool. The flaw lives in the seam, not the product. As the Cloud Security Alliance noted in its research note, “MCP's trust model was designed for tool invocation, not arbitrary data retrieval.” When an observability platform pipes external, user-controlled text through MCP, it “introduces injection surfaces at the protocol level that tool-level controls cannot address.”
Now apply that test to the rest of your stack:
- Datadog ingests log lines, error messages, and span tags — much of it derived from user input that hits your application.
- Jira holds ticket titles, descriptions, and comments that customers, contractors, and form submissions can populate.
- PagerDuty carries alert payloads and incident notes assembled from upstream systems an attacker may be able to influence.
Every one of those is a tool whose contents an AI agent will happily read as authoritative context the moment you connect it. The forged-Sentry-error trick is just the first published instance of a pattern that applies to all of them. VentureBeat's broader analysis of prompt injection across enterprise AI makes the same point at the architecture level: agents, RAG pipelines, and model routers all share the design flaw of mixing untrusted data with trusted instructions in the same channel.
This is exactly the risk class the OWASP GenAI Security Project ranks as LLM01:2025 — Prompt Injection, its single highest-priority LLM risk. OWASP specifically calls out indirect prompt injection: “malicious content embedded in external sources the LLM processes.” Your monitoring stack is now one of those external sources. We walked through the autonomous-agent version of this in why your browser agent will get hijacked; the monitoring-tool version is the same wound in a different limb.
How Is This Different From the OAuth-Scope Problem?
If you have been following our security coverage, you might be tempted to file this next to the Vercel OAuth-scope blind spot. Don't. They are different failures, and conflating them means you will deploy the wrong control.
The OAuth-scope problem is about permissions — a connected app holds a token that grants more access than it should, so when something goes wrong the blast radius is huge. The fix is scoping tokens down. Agentjacking is about content — the data flowing in carries instructions, and the agent obeys them. You can scope every token perfectly and still get hijacked, because the attack rides in on data the agent was supposed to read.
| Dimension | OAuth-scope sprawl | Content injection (agentjacking) |
|---|---|---|
| What's abused | Over-broad permissions on a token | Trusted-by-default data from a tool |
| Attacker needs | A compromised or over-scoped app | A public DSN or any writable field |
| The agent's mistake | Acts with too much authority | Treats data as instructions |
| Primary fix | Least-privilege token scoping | Content-trust boundary + approval gate |
| Does the other fix help? | Doesn't stop injection | Doesn't stop scope abuse |
Both belong in your threat model, and a mature program needs both controls. But if you only hardened token scopes after the Vercel story, you closed one door and left this one wide open. The credential-isolation argument we made in “the credential, not the model” is necessary here too — but on its own it limits damage rather than preventing the hijack.
What Can Attackers Actually Steal Once an Agent Is Hijacked?
The reason this is a board-level concern and not a developer footnote is what the agent has access to at the moment it executes. An AI coding agent runs in a developer's environment, which is one of the most credential-dense places in any company. When the Tenet researchers' test payload phoned home, it documented exactly what was reachable:
| Asset class | Examples captured in testing |
|---|---|
| Cloud credentials | AWS secret access keys, cloud infrastructure tokens |
| Source control | GitHub OAuth tokens, git credentials, private repository URLs |
| Orchestration | Kubernetes tokens, CI/CD pipeline credentials |
| Local secrets | SSH agent sockets, environment variables, developer identities |
A single forged error event, in other words, can put your cloud root keys, your private source code, and your deployment pipeline in an attacker's hands — without anyone clicking a phishing link or touching your servers. And because the agent did the work using legitimate credentials, much of the activity looks like normal developer behavior in your logs.
That is the part worth sitting with: the attack is quiet. There is no malware signature on the wire, no anomalous login. The defensive posture cannot be detection-first. It has to be a boundary that prevents the agent from treating monitoring data as a command in the first place.
How Do You Build a Content-Trust Boundary?
Here is the honest part: there is no single setting that fixes this, and anyone selling you one is overselling. The realistic defense is layered, and most of the layers are things you can start this week. The Cloud Security Alliance's recommendations and OWASP's LLM01 mitigations converge on the same shape, and it lines up with the architecture behind our Secure AI Gateway work.
The principle: treat every connected tool that ingests external text as an untrusted input channel, and put a boundary between that channel and any agent that can run commands, install packages, or make network requests.
A concrete connected-tool audit, in order of effort-to-impact:
- Inventory which integrations feed your agents. List every MCP server and connector your developers have wired into Claude Code, Cursor, or Codex. Most teams cannot produce this list, which is itself the finding.
- Flag which integrations carry attacker-controlled text. Sentry, Datadog, Jira, PagerDuty, support inboxes, webhooks — anything where an outside party can populate a field. These are your injection surfaces.
- Require human approval for consequential actions sourced from tool data. CSA's guidance is explicit: require “explicit human approval before executing any shell command, installing any package, or making any outbound network request sourced from MCP-retrieved content.” This is the single highest-leverage control.
- Isolate the credentials. Run agents in sandboxed environments that cannot read “credential files, cloud metadata service endpoints, and environment variables containing secrets.” This is the credential-isolation pattern — it doesn't stop the injection, but it shrinks the blast radius to near zero.
- Rotate and relay exposed keys. Rotate any public Sentry DSNs and route client-side error reporting through a server-side relay so the ingest endpoint isn't openly writable.
- Gate new MCP servers like dependencies. Subject every MCP installation to a “review process equivalent to the organization's software dependency approval workflow.” A new connector is new attack surface; treat it like one.
If you want the full decision grid for which agent actions need which gate, our confused-deputy audit matrix maps the action-to-control pairings row by row. The throughline across all of it: the boundary, not the agent's good judgment, is what keeps you safe. An agent that “usually” ignores a malicious instruction is an agent that fails 15% of the time — and 15% at scale is a breach.
What This Means for Fort Wayne and Northeast Indiana Businesses
The national headlines name $250 billion companies, and it is easy for a Fort Wayne dev shop or an Allen County manufacturer to read this and assume it is somebody else's problem. It is the opposite. The mid-market is more exposed, not less.
Here is why. The Fortune 100 victim had a security team that caught the test payload. The typical Northeast Indiana scenario looks different: a small dev team or an MSP in Auburn or Fort Wayne adopted Claude Code or Cursor this quarter, wired it into the Atlassian and Datadog stack the company already ran, and shipped faster overnight. Nobody added a content-trust boundary, because nobody knew one was needed. The integration “just worked,” which is exactly the problem — it worked for the attacker too.
DeKalb and Allen County businesses in professional services, manufacturing, and home services are running real cloud credentials, customer data, and source code through these environments. A poisoned Jira comment from a customer-facing intake form, or a forged alert in a monitoring tool exposed to the public internet, is a plausible path into any of them. The defense is not “stop using AI agents” — these tools are a genuine productivity unlock, and we deploy them ourselves. The defense is putting the boundary in before the incident, not after.
That is local, hands-on work: inventorying your connectors, classifying your injection surfaces, and standing up the approval and isolation layers. It is exactly the kind of engagement our team handles for Northeast Indiana businesses, and it does not require ripping out the tools your developers already love.
Put a Boundary Between Your Tools and Your Agents
If your developers are running AI coding agents connected to Sentry, Datadog, Jira, or PagerDuty — and most are, whether or not IT signed off — you have this exposure today. The good news is that the fix is architectural and well-understood, and you do not have to choose between speed and safety.
Cloud Radix builds the content-trust boundary for you: a Secure AI Gateway that sits between your untrusted integration data and the agents holding real credentials, plus the human-approval and credential-isolation layers that turn an 85%-success attack into a non-event. Get in touch for a connected-tool audit of your own stack. We will help you keep the productivity and lose the attack surface.
Frequently Asked Questions
Q1.What is “agentjacking”?
Agentjacking is an attack where someone plants malicious instructions inside data that an AI agent reads from a connected tool — such as a forged Sentry error event — so the agent executes attacker-controlled commands. In the 2026 research that named it, the attack needed only a public Sentry DSN key and achieved an 85% success rate against Claude Code, Cursor, and Codex.
Q2.Is this only a Sentry problem?
No. Sentry was the demonstrated example, but the flaw is in how AI agents treat data from any connected tool as trusted instructions. Datadog, Jira, PagerDuty, support inboxes, and webhooks share the same exposure: any tool that ingests attacker-reachable text and feeds it to an agent with command privileges is in scope.
Q3.How is this different from the OAuth-scope risk everyone talked about after Vercel?
The OAuth-scope problem is about permissions — a token granting too much access. Agentjacking is about content — data carrying instructions the agent obeys. You can scope every token perfectly and still be hijacked, because the attack rides in on data the agent was supposed to read. They require different controls, and a mature program needs both.
Q4.Can't Sentry or the AI vendors just patch it?
Only partially. Sentry called the attack class “technically not defensible” at the source and shipped a filter for one specific payload string rather than a root-cause fix. Model vendors run middleware against known patterns, but indirect prompt injection is an open research problem. The reliable defense is a boundary you control, not a vendor patch you wait for.
Q5.What is the single most important thing I can do right now?
Require explicit human approval before any AI agent executes a shell command, installs a package, or makes an outbound network request based on data it pulled from a connected tool. The Cloud Security Alliance flags this as the highest-leverage control, and it stops the attack chain at the step that matters most.
Q6.Does isolating credentials prevent the attack?
It does not prevent the hijack, but it dramatically shrinks the damage. If the agent runs in a sandbox that cannot read AWS keys, git tokens, or cloud metadata endpoints, a successful injection has little to steal. Credential isolation is a damage-control layer that belongs underneath the content-trust boundary, not a replacement for it.
Q7.We are a small Fort Wayne business — is this really our risk?
Yes, arguably more so. Large enterprises that were targeted had security teams that caught the payload. Smaller Northeast Indiana teams that recently adopted AI coding agents typically wired them into existing Atlassian and monitoring stacks with no content-trust boundary at all, while still running real cloud credentials and customer data through those environments. The exposure is the same; the safety net is usually thinner.
Sources & Further Reading
- VentureBeat: venturebeat.com/security/the-attack-that-hijacked-claude-code — The attack that hijacked Claude Code came through Sentry. Datadog, PagerDuty, and Jira have the same exposure.
- VentureBeat: venturebeat.com/security/prompt-injection-is-exploiting-enterprise-ai — Prompt injection is exploiting enterprise AI's biggest design flaws by targeting agents, RAG pipelines and model routers.
- Tenet Security: tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors — Agentjacking: Hijacking AI Coding Agents With Fake Sentry Errors.
- The Hacker News: thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html — Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code.
- Cloud Security Alliance: labs.cloudsecurityalliance.org/research/csa-research-note-agentjacking-sentry-mcp — Research Note: Agentjacking via Sentry MCP.
- OWASP GenAI Security Project: genai.owasp.org/llmrisk/llm01-prompt-injection — LLM01:2025 Prompt Injection.
Get a Connected-Tool Audit of Your AI Stack
If your developers run AI coding agents wired into Sentry, Datadog, Jira, or PagerDuty, you have this exposure today. Cloud Radix builds the content-trust boundary — so you keep the productivity and lose the attack surface.
