Agentjacking: When Error Logs Become Remote Code Execution
Your error tracker just became an instruction source for agents.
The latest Agentjacking disclosure shows a clean, uncomfortable pattern: an attacker does not need to breach your infrastructure if they can plant instructions in data your coding agent already trusts.
In June 2026, Cloud Security Alliance published research on Agentjacking, an attack where a fake Sentry error is injected through a public write-only DSN, returned through an MCP integration, and interpreted by an AI coding agent as remediation guidance.
The attack is not a traditional intrusion. There is no stolen password, no malware attachment, no exploit against the target application, and no direct access to the developer workstation.
Instead, the attacker writes to an observability system that is designed to accept events. The agent reads from that system through a trusted integration. Then the agent runs the instruction using the developer’s own privileges.
The bigger lesson is not “Sentry is dangerous” or “MCP is broken”. The lesson is sharper: observability data is now executable influence when an agent is allowed to turn diagnostics into shell commands.
How Agentjacking Works
The attack chain is short enough to fit on a whiteboard.
That last phrase matters: as the developer.
Endpoint tools see a trusted process. IAM sees an authorized identity. The network sees normal package manager traffic. The observability platform accepted a normal event. Every link in the chain can look valid in isolation.
CISO translation
Agentjacking is a provenance failure. A system designed to collect untrusted telemetry is being connected to a system designed to take action. If the boundary between “data about an error” and “instructions to execute” is not explicit, the attacker gets to write the runbook.
Why This Is Different From Normal Prompt Injection
Most prompt injection examples start with a user asking an assistant to read a malicious page, email, document, issue, or pull request.
Agentjacking starts somewhere more operational: the debugging workflow.
A developer says, “Fix the unresolved errors.” That is a legitimate request. The agent queries a legitimate integration. The fake content is already sitting inside a legitimate error queue. The malicious instruction looks like a resolution block, not like a random adversarial prompt.
| Traditional view | Agentjacking view | Security consequence |
|---|---|---|
| Logs and error events are operational data. | Logs can become instructions once an agent reads and acts on them. | Treat telemetry as untrusted input, not neutral evidence. |
| A public DSN is low sensitivity because it is write-only. | A write-only key is enough to inject agent-visible content. | Write-only can still be high impact if downstream readers execute. |
| MCP server review focuses on code, auth, and network exposure. | The data sources exposed by the MCP server are part of the attack surface. | Review provenance classes, not just server binaries. |
| Human approval protects risky commands. | The agent can frame the command as standard remediation. | Approval prompts need source context and risk labels. |
This is why “just tell the model not to follow untrusted instructions” is not enough. The agent is not only parsing text. It is operating inside a workflow where source identity, trust level, and action authority are blurred.
The Observability Blind Spot
Security teams usually harden observability systems for confidentiality and availability:
- Who can read logs?
- Who can modify dashboards?
- Are tokens redacted?
- Can alerts be spoofed?
- Are retention and access controls correct?
Agentic systems add a new question:
Can externally supplied observability data cause an agent to act?
If the answer is yes, then your telemetry pipeline is part of your agent execution boundary.
Bug reports become prompts
Stack traces, error messages, breadcrumbs, custom context, tags, and user fields can all carry attacker-controlled text into the agent’s reasoning context.
Runbooks become spoofable
Markdown sections labeled as resolutions, diagnostics, or recommended commands can look operationally useful even when they were written by an external party.
Developer identity becomes the payload carrier
The impact comes from the agent using the developer’s local environment, package credentials, cloud tokens, SSH keys, and repository access.
Detection becomes semantic
Traditional tools see allowed actions. Defenders need to know why the action happened, which source influenced it, and whether that source was trusted.
Mapping To OWASP Agentic Top 10 (2026)
Agentjacking is a multi-category failure under the OWASP Agentic Top 10 (2026):
- ASI01 - prompt injection, because attacker-authored event content becomes agent instruction.
- ASI02 - tool misuse, because a trusted MCP integration becomes a pathway to command execution.
- ASI03 - privilege compromise, because the agent acts with the developer’s local and cloud privileges.
- ASI05 - supply chain and dependency risk, because the payload can be delivered through normal package installation paths.
- ASI07 - inadequate observability, because most logs capture what ran, not which untrusted source convinced the agent to run it.
The key shift is that provenance has to become a runtime security control. It is not enough to know that “the agent called the terminal”. You need to know which external artifact influenced that decision.
Controls That Actually Help
The fix is not to disconnect every useful integration. It is to stop pretending every integration output has the same trust level.
Practical policy
If a data source accepts content from outside your trust boundary, an agent may read it but cannot execute from it. It can summarize, classify, and propose. It cannot install, run, write, deploy, rotate, or exfiltrate without a provenance-aware gate.
Questions To Ask This Week
Security leaders should ask five concrete questions before letting agents touch operational data:
- Which MCP integrations are enabled across developer machines and CI environments?
- Which of those integrations expose user-controlled, customer-controlled, public, or unauthenticated content?
- Can the agent execute shell commands or install packages based on output from those integrations?
- Do approval prompts show where the instruction came from, or only what the agent wants to do?
- Can incident responders reconstruct the source content that led to a risky tool call?
If the answer to question two is “we do not know”, the agent inventory is incomplete. If the answer to question four is “only what the agent wants to do”, human approval is mostly theater.
Bottom Line
Agentjacking is a preview of how enterprise AI incidents will look when agents are wired into real workflows.
The attack does not need to break your perimeter. It does not need to defeat your identity provider. It does not need a malicious binary at the start of the chain.
It only needs a place to write data that your agent later treats as operational truth.
That makes provenance the new control plane. Every agent-connected data source needs a trust label. Every high-risk action needs to carry the source that influenced it. Every “fix this issue” workflow needs to distinguish evidence from instruction.
Your logs were never harmless. Now they can talk to the terminal.
References
- Cloud Security Alliance, June 12 2026: Agentjacking: MCP Injection Hijacks AI Coding Agents
- The Hacker News, June 2026: Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code via Fake Error Reports
- OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications 2026
Rogue Security helps teams enforce provenance, tool policy, and runtime controls around autonomous AI systems. Learn more at rogue.security.