Public Sentry keys can hijack Claude Code and Cursor

A public Sentry key can be abused to inject malicious MCP data into AI coding tools.

A single exposed integration key can turn a trusted observability feed into an attack path for Claude Code, Cursor, and Codex. The attack matters because these tools are increasingly used with the Model Context Protocol, which lets agents pull in external data and act on it.

The New Stack’s report describes a technique called agentjacking, where an attacker abuses a public Sentry key to poison the data an AI coding assistant sees. Instead of breaking into the app directly, the attacker targets the agent’s inputs and waits for the model to trust the wrong thing.

Why this attack works

The core problem is trust. AI coding assistants are built to ingest context from tickets, logs, docs, and connected services, then turn that context into code or actions. When one of those sources can be manipulated, the model may treat attacker-controlled content as if it came from a legitimate internal system.

That is especially dangerous in developer workflows where the agent can read from one system and write to another. A poisoned log line, issue description, or event payload can influence what the assistant summarizes, what it suggests, and in some setups what it executes.

In practical terms, this is less like a classic exploit and more like supply-chain poisoning for agent inputs. The attacker does not need to own the model. They only need a path into the context the model trusts.

• A public key can expose an integration endpoint.
• An exposed endpoint can accept attacker-controlled content.
• An agent can treat that content as trusted context.
• Trusted context can shape code suggestions or actions.

What Sentry changes in the picture

Sentry is normally a defensive tool. Teams use it to collect errors, traces, and performance data, then fix bugs faster. In this case, the issue is that a public key can make a Sentry project easier to target if the surrounding agent workflow accepts that data without enough validation.

The vulnerability is not that Sentry itself is malicious. It is that the data path from monitoring system to AI assistant can become a weak link. If the assistant consumes that stream automatically, a public identifier becomes a handle for abuse.

"The main issue is not the model itself, but the untrusted data that gets fed into it," said Simon Willison, who has written extensively about prompt injection and AI tool security.

Willison’s warning fits this story well. Agent security is turning into a data-validation problem, and the old habit of trusting internal tools by default is now risky when an LLM is in the loop.

That matters for teams using observability data as agent context. A monitoring alert that used to land in a dashboard can now become part of an instruction chain for a coding assistant, which means every field needs to be treated with more suspicion.

Claude Code, Cursor, and Codex are exposed in different ways

These tools are not identical, but they share the same basic weakness: they can pull in external context and act on it. Claude Code is designed to work closely with codebases and developer workflows. Cursor integrates AI into the editor. Codex is built around code generation and developer assistance.

Once an assistant can read from connected services, the question becomes whether it can tell the difference between a real signal and a planted one. The answer, in many agent setups, is: not reliably enough.

• Claude Code is tightly coupled to coding tasks and repo context.
• Cursor mixes editor actions with AI-generated suggestions.
• Codex sits close to code generation and task execution.
• MCP expands the number of external systems an agent can read.

That combination is powerful, but it also widens the attack surface. The more systems an assistant can query, the more places an attacker can try to plant misleading data.

What developers should do now

The fix is not to abandon AI coding tools. It is to put hard boundaries around what they can trust. Teams should review every connector, every public key, and every data source that can feed agent context. If a system can accept outside input, it needs validation before an assistant sees it.

Security teams should also separate read access from actuation. An assistant that summarizes logs is one thing. An assistant that can open tickets, edit code, or trigger deployments needs a much stricter policy layer.

There is also a governance issue here. If your organization uses MCP, then every server and connector becomes part of the trust model. That means inventory, review, and revocation processes matter just as much as model prompts.

For a deeper look at related agent risks, see OraCore’s coverage of agent security risks and MCP security guidance.

Here is the short version: if a public key can influence what your agent sees, then your agent is only as trustworthy as the weakest data source in its chain. The next obvious test for vendors is whether they can prove their assistants ignore poisoned context before that context turns into code.