Blog Published: Jun 22, 2026

Agentjacking: How Fake Sentry Errors Turn MCP Telemetry into Agent Code Execution

Tenet Threat Labs showed that attacker-injected Sentry events can hijack AI coding agents through the Sentry MCP server. A public Sentry DSN lets an attacker submit a crafted error, the MCP integration returns it as diagnostic context, and Claude Code, Cursor, or Codex may execute a suggested npm command with developer or CI privileges. The control lesson: telemetry is data, not authority; MCP outputs, agent clients, tool gates, sandboxes, and egress policy all need runtime enforcement.

Indirect Prompt InjectionCredential TheftTool AuthorizationRuntime IsolationMCP Security

9 applicable AIDEFEND defenses

Source: One Fake Bug Report Hijacked a $250 Billion Company's AI Agent - Then 100+ More

Authors: Ron Bobrov, Barak Sternberg, Nevo Poran (Tenet Threat Labs)

Original article: Jun 17, 2026

Threat Analysis

The attacker writes to telemetry, not to the developer. Tenet describes an attack that starts with a public Sentry DSN. Anyone who has it can submit events, control event fields, and format a fake Sentry-looking resolution with a suggested npx command.
The agent crosses from issue triage into code execution. When a developer asks an AI coding agent to investigate Sentry issues, the Sentry MCP server returns the crafted event. The agent may treat the fake resolution as trusted guidance and run the package.
The package runs with the agent environment's authority. Tenet reported validation across Claude Code, Cursor, Codex, local machines, WSL, cloud containers, and CI. The package probed environment variables, AWS config, npm config, Docker config, Git credentials, network interfaces, and other sensitive material.
The risk is architectural. Writable telemetry becomes trusted model context through MCP, then crosses into tool execution. Tenet reported that prompt-layer instructions did not reliably stop execution, so durable controls need to live at the MCP output boundary, client boundary, tool dispatcher, sandbox, egress layer, and credential lifecycle.

Applicable AIDEFEND Defenses (9)

AID-H-029.004

Client Response Parsing, Rendering & Execution Surface Hardening

Very High

This is the client-side break point. A Sentry MCP response should be parsed, rendered, and presented as untrusted content; the client must not auto-execute server-suggested commands or terminal text. A normalized read-only confirmation should show the source event, command, package name, and parameters before execution.

AID-H-035.005

MCP Server Output, Resource URI & Elicitation Boundary Controls

Very High

This is the server-output break point. Sentry event messages, context fields, breadcrumbs, and stack traces are externally submitted telemetry. The MCP server should label, bound, and redact them, and prevent resource text or generated prompts from smuggling privileged instructions into model context.

AID-H-019.004

Intent-Based Dynamic Capability Scoping

Very High

The trusted intent is issue triage, not arbitrary package execution. A signed per-request capability scope should expose read-only Sentry inspection and repository analysis, while denying shell, package install, credential reads, and external network actions unless separately authorized.

AID-H-018.003

Decoupled Plan-Then-Execute Architecture

High

Breaks the link between reading the poisoned resolution and running it. The model is confined to emitting a structured plan, and a deterministic Action Selector validates that plan against a role-based allowlist before any tool executes, so an injected npx step never reaches a shell on its own. It sits one layer earlier than the sandbox and egress controls, which contain execution after dispatch.

AID-H-019.003

High-Impact Two-Channel Validator

High

Running npx or installing a package is a high-impact code-execution step. A separate validator should require evidence that the command comes from trusted project policy or human approval, bind approval to the exact command, package, and target, and fail closed otherwise.

AID-I-001.004

Sandbox Network Egress Restrictions

High

Tenet's validation relied on beacon traffic and exposure probes. Tool sandboxes should default-deny outbound connections and allow only reviewed destinations so a package cannot call attacker infrastructure, probe cloud metadata, or exfiltrate evidence after execution.

AID-I-001.003

Ephemeral Single-Use Sandboxes for Tools

High

If a risky diagnostic command must run, it should run once in a fresh sandbox rather than on the developer host or a reusable CI environment. Teardown limits persistence, cross-session contamination, and access to host-level files such as .aws, .npmrc, Docker config, or SSH state.

AID-D-003.003

Agentic Tool Use & Action Policy Monitoring

Medium

Policy monitoring turns attempted and allowed high-risk tool decisions into security events: MCP-derived command proposals, denied package installs, unexpected shell use, and allow/deny bursts. It is detective, not a blocking boundary, but it gives teams evidence to investigate and tune gates.

AID-E-001.001

Foundational Credential Management

Medium

When exposure is suspected, teams need a tested rotation process for long-lived secrets and accounts that the agent environment could reach: Sentry auth tokens, GitHub tokens, cloud keys, npm tokens, SSH material, and database credentials. This is response value, not primary prevention.

What Defenders Should Do Now

Inventory every AI coding agent that can query Sentry or other observability systems through MCP. Record the agent product, MCP server, Sentry project, DSN exposure path, credentials available to the agent, shell access, package-install access, and network egress policy.
Treat Sentry events as untrusted external data. Event messages, tags, breadcrumbs, context keys, user fields, and stack traces should enter the model as data-only fields with provenance, not as diagnostic instructions the agent can obey.
Disable Sentry MCP access where it is not needed. Where it is needed, prefer read-only investigation workflows and require explicit human approval before any MCP-derived text can cause shell execution, package installation, browser navigation, file writes, or outbound network calls.
Make package execution a high-risk action. Before an agent runs npx, npm install, curl, shell, or generated scripts, show the exact command, package namespace, source event, repository context, and expected artifact, then bind approval to that exact plan.
Run diagnostic commands in fresh sandboxes with default-deny egress and no host secrets mounted by default. Do not expose AWS profiles, GitHub tokens, npm tokens, Docker config, SSH agents, production .env files, or cloud metadata endpoints to routine agent triage.
If an agent may have executed an MCP-derived command, collect the agent transcript, shell history, package metadata, network logs, and beacon destinations. Rotate reachable Sentry auth tokens, GitHub tokens, cloud keys, npm tokens, SSH material, and any other secrets that were present in the execution environment.

Conclusion

Agentjacking turns observability data into an agent runtime trust-boundary problem. A Sentry event can help diagnosis, but it is not authority to install packages or run commands. Durable defense preserves that separation through MCP output labeling, client-side no-implicit-execution, tool authorization, sandboxing, egress control, and credential response. Some fixes belong to agent-client or MCP-server vendors; consuming teams should choose products that enforce those boundaries, proxy or self-host where they need provenance control, and apply the approval, sandbox, and egress controls they own.