Something changed this week for any team using AI to help debug their code — and you need to know about it before your next sprint.
On June 12, researchers at Tenet Security published findings on a new attack class they're calling "agentjacking." The name is deliberately blunt. The attack hijacks your AI coding assistant, uses it against you, and walks out with your AWS credentials and environment variables — leaving behind no trace that your existing security tools will catch.
Here's what happened, how it works, and what to actually do about it.
The attack in plain English
If your team uses Sentry for error tracking — and a huge chunk of dev teams do, it's become near-standard — you've got a Sentry DSN embedded somewhere in your codebase. A DSN is a write-only key that lets your application send error events to Sentry. It's not supposed to be sensitive. It ships in your front-end JavaScript. It ends up in Git history. It's public.
Here's the problem: Sentry's ingest API will accept an error event from anyone who has your DSN. That's by design — it's how the product works.
Tenet Security figured out that if you search GitHub for real Sentry DSNs from real organizations, you find them. Thousands of them. And if you post a carefully crafted fake "error event" to that DSN, it appears in the organization's Sentry dashboard looking exactly like a real application error.
Now comes the AI coding agent part. Most teams using tools like Cursor or GitHub Copilot have the Sentry MCP integration enabled. When a developer asks their assistant "can you check my recent Sentry errors and figure out what's causing this," the agent fetches those events via MCP — including the malicious one the attacker planted.
The fake error event is written to look like legitimate diagnostic output. It contains a "Resolution" section — formatted to be structurally identical to Sentry's own MCP templates — that instructs the agent to run an npm package to "collect diagnostic data." The agent, reading what looks like output from a trusted telemetry source, runs it.
The package quietly harvests AWS keys, environment variables, Git credentials, and private repository URLs — and ships them to the attacker's server.
Why your existing tools won't stop this
This is the part that should make you pause. Tenet Security calls this the "Authorized Intent Chain." Every step in the attack is technically legitimate:
- Querying GitHub for a public DSN? Authorized.
- Posting to Sentry's ingest API? Authorized.
- The agent fetching Sentry data via MCP? Authorized.
- Running an npm package to handle a diagnostic task? Authorized.
Your EDR doesn't flag it. Your WAF doesn't see it. Your firewall doesn't block it. IAM controls don't apply here. Cloudflare is irrelevant. VPN makes no difference.
Tenet tested this against Cursor, Codex, and others, achieving an 85% exploitation success rate. They also confirmed the attack succeeded even when agent system prompts explicitly instructed the agent not to trust untrusted data. The model followed the injected instructions anyway.
The agents weren't fooled — they were doing exactly what they're designed to do: act on information retrieved from connected tools. The problem is that the information had been poisoned before it got there.
How many orgs are exposed right now
Tenet found at least 2,388 organizations with publicly exposed, injectable Sentry DSNs. That's a conservative number — it reflects what was findable through GitHub searches. The real number is almost certainly higher.
They disclosed this to Sentry on June 3. Sentry acknowledged the issue but declined to implement a root-cause fix, describing the attack class as "technically not defensible" at the platform level. They deployed a content filter for specific payload strings — which is trivially bypassed by any attacker who knows about it.
This is, increasingly, the response you get when AI-adjacent attack surfaces get disclosed to vendors whose architectures created them. Not our problem. Known limitation. Inherent to the design.
Small orgs are left holding the bag.
What to do today
If your team uses Sentry and any AI coding assistant with MCP integrations, here's the actual to-do list:
1. Audit your DSN exposure right now. Search your public GitHub repos for SENTRY_DSN, sentry_dsn, or your organization's Sentry project slugs. If they show up in public code — and they probably do — assume they've been scraped. Enable Sentry's "Allowed Domains" setting to restrict which origins can submit events. It won't fully close the hole but it raises the cost for attackers.
2. Treat agent-initiated remediation steps with skepticism. Any time your AI coding agent suggests running a package, executing a script, or making a network call while debugging errors pulled from external monitoring — stop. Read what it's actually proposing. Ask yourself: did this instruction come from me, or did the agent get it from data it fetched?
3. Scope your MCP tool permissions. Most AI coding environments let you control what actions MCP integrations can trigger. Sentry MCP should be read-only. It should not have a path to shell commands or package execution through the agent.
4. Rotate credentials, especially cloud provider keys. If your team has been using AI assistants to triage Sentry errors for the past few months with MCP enabled, rotate your AWS keys and audit IAM activity for anything unfamiliar. Treat it like you would treat finding an unknown device on your network.
The bigger picture
This isn't really about Sentry. Sentry is just the vehicle this week.
What agentjacking exposes is a structural trust problem in how AI coding agents work: they treat data retrieved through MCP-connected tools as trustworthy. That trust is what makes them useful. An assistant that second-guesses every data source it touches would be slow and annoying to work with. But that same trust is a large, mostly unsecured attack surface — and attackers have noticed.
Any external data source your agent can query — error monitoring, log aggregators, analytics platforms, customer feedback tools, incident trackers — is a potential injection point. The highest-risk ones are those that accept writes from the public internet without authentication.
Small and mid-sized teams are adopting AI coding tools fast, usually without a dedicated security team reviewing what integrations are active or what data sources those integrations trust. That gap is precisely what this attack targets.
If you've been adding MCP integrations to your AI dev stack and don't have a clear picture of what data your agent trusts and what permissions it can exercise — that's exactly what we help orgs get clear on before something like this bites them.