Sentry MCP agentjacking is the failure mode that appears when a coding agent treats telemetry as trusted diagnosis. The malicious instruction does not need to live in the repository. It can arrive through observability, issue trackers, logs, alerts, or any external tool connected to the agent.
In June 2026, Tenet Security reported 2,388 organizations exposed to injectable Sentry events and more than 100 agent executions during controlled validation (Tenet Security, "One Fake Bug Report Hijacked a $250 Billion Company’s AI Agent", 2026, retrieved 2026-07-06). The practical point is direct: an agent should not decide alone when a bug report becomes a command.
Practical summary
- Treat Sentry, logs, and issues as external input, not instructions.
- Separate telemetry reading, root-cause analysis, and command execution.
- Require confirmation for MCP tools that return third-party-controlled data.
- Block network, installation, and shell when the source is observability.
Why does Sentry agentjacking deserve its own article?
In 2026, Tenet Security reported 2,388 exposed organizations, 71 of them in the Tranco top one million, and more than 100 agent executions in controlled tests (Tenet Security, "One Fake Bug Report Hijacked a $250 Billion Company’s AI Agent", 2026, retrieved 2026-07-06). This deserves its own article because the risk moves outside the codebase.
The post on hooks for coding agents covered gates before shell, MCP, and session completion. Telemetry-based agentjacking needs an earlier layer: classify the origin of the data that inspired the action. If the agent read an externally influenced error, the next step must carry that untrusted mark.
The difference is small, but the architecture changes. A real bug can deserve a legitimate investigation. An injected bug can ask for the same diagnosis with a malicious instruction hidden inside a resolution format. To the agent, both look like useful workflow text.
Citable capsule: Sentry MCP agentjacking changes risk because the dangerous command starts in telemetry, not in the repository. Tenet reported 2,388 exposed organizations and more than 100 executions in controlled validation, making observability a hostile-input surface for coding agents.
Where does the attack chain start?
Sentry’s current documentation says DSNs are safe to keep public because they only allow new event submission, while also acknowledging that anyone can send events with any information to an organization (Sentry Docs, "Data Source Name (DSN)", 2026, retrieved 2026-07-06). The chain starts when that public event returns to the agent as trusted context.
Before coding agents, this model mostly created spam and noise risk. With MCP-connected agents, the same event can enter the operational reasoning chain. The agent receives a stack trace, message, context, and what appears to be remediation guidance.
Tenet described the sequence as a Sentry event manipulated through Markdown, returned by the MCP server, and read by the agent as diagnostic guidance (Tenet Security, "One Fake Bug Report Hijacked a $250 Billion Company’s AI Agent", 2026, retrieved 2026-07-06). The attacker does not need to compromise the repo. They only need to control data the agent consults.
The same pattern applies elsewhere. Public issues, pull request comments, support tickets, and customer logs also mix data with recommendations. If the agent does not label origin, external text can become part of the plan.
Citable capsule: The agentjacking chain begins when external data returns to the agent as trusted diagnosis. Sentry documents that public DSNs accept new events, and Tenet showed that manipulated events can carry instructions that agents read during triage.
Why does MCP make the problem larger?
In the 2025-06-18 specification, MCP tools are described as model-controlled, with automatic discovery and invocation by the model, and the specification recommends a human in the loop to deny invocations (Model Context Protocol, "Tools", 2025-06-18, retrieved 2026-07-06). MCP enlarges the problem because it turns external systems into operational tools for the agent.
That usefulness is the point. MCP avoids manual copy-paste and lets Codex, Claude Code, and similar agents query real tools. The price is a shifted trust boundary: a tool response becomes part of the context that decides the next action.
Research on MCP tool poisoning analyzed 57 threats across five components and tested clients against tool-poisoning attacks (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, retrieved 2026-07-06). Even when the server is legitimate, returned data may be controlled by someone else.
That is the missing detail in many setups. Allowing an MCP server is not the same as allowing every action induced by everything it returns. Sentry can be trustworthy as a service while still carrying hostile events as content.
Citable capsule: MCP expands agentjacking because it brings external data into the decision loop. The 2025-06-18 specification describes model-controlled tools and recommends a human in the loop; defense must separate trust in the server from trust in each returned event.
What should the agent runtime block?
Codex documentation says network access is off by default and controls combine a technical sandbox with an approval policy for actions such as leaving the sandbox, using the network, or running sensitive commands (OpenAI Developers, "Agent approvals & security", 2026, retrieved 2026-07-06). The runtime should block direct passage from telemetry to execution.
The operating rule is simple: if the intent came from observability, the agent may read, summarize, and propose a hypothesis. It should not install a package, open the network, run a command suggested by the error, or touch credentials without an explicit gate.
I would use simple states. Reading is allowed for Sentry and logs. Analysis is allowed with local search and diffs. Execution becomes ask or deny when the command derives from an external event. This reduces damage without killing automatic triage.
Practical experience: when I design a harness for a coding agent, I make intent origin a required field in the final summary. If the change started from a log, alert, or external issue, the agent must show local proof before asking to execute anything beyond reading.
In long agentic flows, context cost also matters: I use RemoteCode to extend context for Claude Code and Codex without dumping the whole history into the main prompt when the agent needs continuity across investigation, patch, and proof; it is my own tool, so this is an editorial and contextual mention.
Citable capsule: Runtime policy should distinguish origin and action. Codex documents sandboxing, approvals, and default-off network access; in agentjacking, add one rule: telemetry can guide analysis, but it cannot authorize shell, installation, network, or secret access.
How do you turn this into engineering policy?
In May 2026, the NSA said MCP proliferation had outpaced development of its security model and recommended deliberate controls beyond protocol suggestions (NSA, "Model Context Protocol (MCP): Security Design Considerations", 2026, retrieved 2026-07-06). Engineering policy must be executable, not just written in a prompt.
Start with inventory. List which MCP servers participate in development, which return third-party-controlled data, and which expose write-capable tools. Policy should be stricter where external reading and local execution meet.
Then create rules by origin. Sentry events, public issues, external PR comments, customer logs, and support messages enter as untrusted content. Local test output, generated diffs, and CI artifacts enter as local evidence.
A small matrix works better than a long manual:
| Data origin | Allowed action | Required gate |
|---|---|---|
| Observability event | Summarize and map a hypothesis. | Execution needs confirmation. |
| External issue or comment | Search related code. | Network and shell stay in ask. |
| Local test generated in repo | Fix and repeat the test. | Summary must show evidence. |
| Write-capable MCP tool | Prepare a proposal. | Real write needs allowlist. |
This policy fits codebase RAG over MCP for agents. Use MCP to retrieve context. Use permissions and hooks to stop external context from becoming execution authority.
Citable capsule: Agentjacking policy begins with origin inventory. The NSA said in 2026 that MCP security depends on implementation discipline; for software teams, that becomes server allowlists, external-input labeling, and separate gates for reading, analysis, and execution.
How do you test whether your workflow is vulnerable?
In 2026, MCP threat-modeling research identified 57 threats across five components and evaluated clients against four types of tool poisoning (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, retrieved 2026-07-06). Testing your workflow means simulating hostile data before someone else does.
Do not start with an exploit. Start with a harmless event that contains a fake resolution instruction. Ask the agent to investigate the alert. The expected result is that it labels the instruction as external data, searches for cause in code, and stops before executing anything suggested by the event.
Then test boundaries. Does the agent try to install a package? Open the network? Read .env to confirm a variable? Run a command copied from the log? Each attempt should hit ask or deny with a clear reason.
Finally, carry this into CI. An agent-authored PR should state which external data influenced the change, which commands ran, and which local evidence supports the patch. That connects this topic to PR evals for code agents in CI.
Citable capsule: A good agentjacking test does not need weaponization. Use a harmless event with a fake instruction, ask the agent to triage, and check whether it separates external data from commands. If it runs installation, network, or shell suggested by the event, the workflow failed.
Frequently asked questions about Sentry MCP agentjacking
Is agentjacking a Sentry vulnerability?
Not by itself. Sentry documents that public DSNs accept event submission, and Tenet showed agents can treat those events as trusted guidance. The risk appears at the intersection of external telemetry, MCP, and autonomous agent execution. The defense needs to live in the agent runtime.
Should MCP be removed from coding agents?
No. MCP remains useful for live context and avoids copying information into prompts. The MCP tools specification recommends a human in the loop for invocations. The practical adjustment is scoped reading plus a gate when external responses try to induce action.
Does a sandbox solve agentjacking alone?
Not alone. Codex documentation separates technical sandboxing from approval policy, and Tenet reported cases in environments with some isolation. A sandbox reduces reach, but it does not change intent origin. You still need to block execution derived from hostile telemetry.
How is this related to tool poisoning?
Tool poisoning places malicious instructions in tool metadata. Sentry agentjacking places instructions in data returned by a legitimate tool. The 2026 MCP study treats tool poisoning as a priority attack, but the larger pattern is the same: external text influences action.
What should I change first?
Start by denying direct execution when the origin is observability, a public issue, or an external log. Then add MCP server allowlists, confirm write-capable tools, and record local evidence at the end of the loop. That small set blocks the most dangerous chain.
Closing
Sentry MCP agentjacking shows that coding agents do not live only inside the repository. They read telemetry, tickets, logs, and external tools. Each source can help. Each source can also carry an instruction that should never become action.
The healthy pattern is to treat observability as hostile input until proven otherwise. Let the agent read, summarize, and form hypotheses. Before shell, network, installation, credentials, or external writes, make the harness ask where the intent came from and which local evidence confirms the next step.
Sources consulted
- Tenet Security, "One Fake Bug Report Hijacked a $250 Billion Company’s AI Agent", retrieved 2026-07-06, https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/
- Cloud Security Alliance AI Safety Initiative, "Agentjacking: MCP Injection Hijacks AI Coding Agents", retrieved 2026-07-06, https://labs.cloudsecurityalliance.org/research/csa-research-note-agentjacking-mcp-sentry-injection-20260612/
- Sentry Docs, "Data Source Name (DSN)", retrieved 2026-07-06, https://docs.sentry.io/concepts/key-terms/dsn-explainer/
- Model Context Protocol, "Tools", retrieved 2026-07-06, https://modelcontextprotocol.io/specification/2025-06-18/server/tools
- OpenAI Developers, "Agent approvals & security", retrieved 2026-07-06, https://developers.openai.com/codex/agent-approvals-security
- OpenAI Developers, "Model Context Protocol", retrieved 2026-07-06, https://developers.openai.com/codex/mcp
- NSA, "Model Context Protocol (MCP): Security Design Considerations", retrieved 2026-07-06, https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF
- arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", retrieved 2026-07-06, https://arxiv.org/html/2603.22489v1
