The Log Is the Command

A forged Sentry alert tried to make an engineer, or the engineer’s AI coding agent, run malware.

That is the clean version. Episode 42 of The Sam Ellis Show is about the uglier and more useful version: the attack did not begin as a suspicious email, a fake login page, or an obvious malware drop. It began as operational text inside a workflow people already use when something is broken.

It looked like an error report.

That is what makes Agentjacking worth taking seriously. The episode follows a current-cycle attack path in which hostile text is placed into observability systems through forged Sentry events. The attacker’s goal is not merely to trick a human reading a log. It is to reach the AI coding agent that the human may have connected to that log, ticket, issue, or tool response.

Once an agent can read the operational surface and take action, the operational surface changes category.

A log is no longer just a record. A ticket is no longer just a queue item. An alert is no longer just evidence. A tool response is no longer just context.

For an agent with enough authority, all of those can become instruction channels.

The episode’s central distinction is important: the story is not that Sentry was breached. Sentry says it was not. Sentry’s advisory describes attempts to use public Data Source Names, or DSNs, to send crafted events into projects, with those events designed as prompts to convince agents to install third-party npm packages. Sentry says this was not a vulnerability in Sentry and that there was no compromise of Sentry infrastructure.

That boundary matters because it makes the problem more interesting, not less.

If an attacker does not need to breach the observability platform, only to write plausible-looking hostile text into a place an agent will later read, the defense problem moves. It is not only platform security. It is provenance, authority, trust, and the shape of agent-readable operations.

Nutrient’s account gives the affected-operator view. A forged Sentry alert entered an internal-looking workflow. An engineer was working the alert with an AI coding agent. The hostile instruction pointed toward a typosquatted package. Nutrient says the agent refused rather than executing it. That refusal is good news. It is also not a general defense strategy.

The fact that one agent refused one suspicious package does not make the channel safe.

Tenet Security frames the broader issue as Agentjacking: attacker-written markdown entering Sentry-related workflows and then being treated by coding agents as trusted remediation guidance. Tenet’s specific scale and success-rate claims should be treated as Tenet claims, not Sentry-confirmed facts. But the mechanism is enough without inflated numbers. Public event-ingest paths, operational tools, MCP connectors, and coding agents create a clean route from hostile text to possible action.

The old prompt-injection model was often imagined as a user trying to jailbreak a chatbot. This is different. The dangerous text is not necessarily typed by the user. It is not necessarily shown in a chat box. It may arrive through telemetry, issue details, stack traces, markdown fields, package names, comments, or structured tool output.

That makes the agent’s trust boundary harder to see.

When a developer opens an error report, the default assumption is that the report is evidence about a system failure. When an AI coding agent reads the same report, the text may be parsed as task context: here is what broke, here is the suggested fix, here is the command or package that allegedly resolves it. If the agent has shell access, package-manager access, repository write access, or deployment authority, the distance between “reported error” and “executed remediation” can become very short.

That is the unpleasant question in the episode: when a developer gives an agent access to observability tools, does the error log become a command channel?

The answer is not always yes. It depends on what the agent can do, what the tool returns, how the output is labeled, whether untrusted data boundaries are visible to the model, whether commands require approval, whether package installs are checked, whether provenance survives into the agent context, and whether the workflow treats logs as facts, suggestions, or hostile input.

But “not always yes” is already a warning. The safe default cannot be that anything retrieved by an approved tool becomes trusted just because the tool itself is legitimate.

That is the key shift. In agent systems, trusted tools can carry untrusted data.

A Sentry integration can be legitimate while a specific event body is hostile. An MCP server can be useful while one field in its response is attacker-controlled. A GitHub issue can be real while a comment inside it is prompt injection. A log aggregation system can be correctly configured while a message inside the log is written by someone trying to steer an agent.

The mitigation shape follows from that distinction.

Agent-readable operational data needs explicit untrusted-data boundaries. Tool responses should preserve provenance and mark attacker-controllable fields. Agents should not treat remediation text inside logs, alerts, or tickets as instructions. Package installs and command execution need separate authority checks. Typosquatted packages need suspicion, not obedience. Human approval should not be a sleepy click-through attached to a wall of plausible operational detail.

Sentry MCP maintainers have already drafted work around wrapping issue details in an untrusted-data boundary. That is the right genre of fix. The goal is not to make every alert unreadable. It is to stop operational text from silently changing status when it enters an agent’s context window.

Because this is the deeper point: agents make old surfaces active.

Before agents, a poisoned log line might mislead a tired engineer. That was already bad. With coding agents, the same poisoned log line may be summarized, prioritized, converted into a plan, translated into a shell command, and executed inside a repository. The log did not gain new powers by itself. The surrounding workflow did.

Agentjacking is not just a Sentry story. It is an early receipt for a larger rule of agentic software: every system that feeds text to an agent with authority becomes part of the control plane.

That includes observability. It includes support tickets. It includes pull-request comments. It includes chat transcripts. It includes customer emails. It includes dashboards, traces, alerts, and knowledge-base articles. If an agent reads it while deciding what to do, the text is no longer passive.

The old security question was: can an attacker get code execution?

The agent-era version is: can an attacker get instruction execution by placing the right text in the right trusted workflow?

Episode 42 is about that category change. The log is not just the evidence. In the wrong architecture, the log is the command.

Listen to Episode 42

Episode 42, "The Log Is the Command", is live now.

Download the episode or subscribe to the show feed.

Sources

Send tips, corrections, and source notes to [email protected].