Telemetry Is an Instruction Channel

A firewall blocks a malicious request. The event lands in the WAF log. Later, an agent reads the log while investigating an issue and changes DNS using values supplied by the attacker.

The firewall worked. The agent still completed the attack.

That is the useful part of Tenet Security’s GhostJacking research. The demonstrations are new, but the larger problem is familiar: an authorized system made a bad decision because it could not distinguish evidence from instruction.

Security telemetry was built to preserve attacker-controlled input. We want the path, header, exception, payload fragment, user agent, and stack trace because those details help us understand what happened. Once an agent can read that material and use infrastructure tools in the same session, a formerly passive record becomes part of the control plane.

The permission review can be correct and the system can still be unsafe.

What the researchers demonstrated

Tenet presented GhostJacking at DEF CON 34 and published its technical account on August 9, with an update on August 13. The work describes attacks through Cloudflare, Datadog, and Sentry integrations.

In the Cloudflare demonstration, an attacker placed crafted text in request headers. A managed WAF rule blocked the request and recorded those headers in a firewall event. An agent later read the event through a GraphQL MCP integration while also holding access to a separate Cloudflare API tool capable of making changes.

The text did not need to look like a blunt prompt injection. Tenet says obvious commands and fake system tags were rejected. The successful version resembled scanner output. It included a ticket reference, compliance language, and claims that the agent could partially verify. The agent treated attacker-supplied DNS values as remediation data, changed an A record, and added a CNAME.

The attack crossed four boundaries:

attacker-controlled request
  -> faithfully preserved WAF event
  -> agent investigation context
  -> authorized infrastructure tool
  -> DNS change

Tenet reports a 90 percent success rate against Claude Code using Sonnet 4.6 in its test setup. SC Media independently described the demonstrated chain, but the success rate remains a researcher-reported benchmark, not a production compromise rate.

The Datadog path used client-submitted log data. A public client token, intended for browser-side telemetry, could let an attacker place a malicious message in a log stream. When an agent investigated and attempted the suggested diagnostic, the chain reached command execution.

The Sentry work explored error reports and agent-to-agent trust. One system could produce a plausible remediation that another coding agent later accepted. That matters because provenance can disappear when one agent summarizes material for another. The second agent sees a recommendation from a trusted system, not the attacker-controlled text that shaped it.

Tenet also reports a separate Claude Desktop sandbox escape that Anthropic confirmed and fixed before the talk. That issue should not be collapsed into the broader telemetry problem. The sandbox vulnerability was a specific product flaw. Telemetry becoming instruction is an architectural failure mode that survives individual patches.

Exposure is not compromise

The large numbers in the disclosure need careful labels.

Tenet identified 73 public artifacts associated with 48 organizations that appeared to use a susceptible Cloudflare setup. Six were identified as Fortune 500 companies. The researchers extrapolated from that sample and Cloudflare adoption to estimate that more than 15,000 organizations could have comparable exposure.

That does not mean 15,000 organizations were compromised. It does not even establish that every inferred deployment would reproduce the attack. It is an estimate of adoption of a configuration pattern.

The same distinction applies to the reported 2,700-plus Datadog client tokens and publicly exposed Sentry DSNs. These values are often designed to appear in client applications. Their presence is not equivalent to an administrative credential leak. The risk comes from what an attacker can write through them, which agents later consume, and what those agents are allowed to do next.

There is no public report of GhostJacking exploitation in the wild. The useful response is to test the trust boundary, not to turn a research estimate into an incident count.

Tool permission is only half the authorization decision

MCP reviews usually start with identities and verbs:

• Which agent can call the tool?
• Which methods are available?
• Can it read or write?
• Which account and scope does it inherit?
• Does a person approve sensitive operations?

Those are necessary questions. GhostJacking exposes the question they leave out:

What information caused the agent to decide that this tool call was appropriate?

An agent may be authorized to update DNS. That does not mean a WAF header is authorized to select the new destination. A coding agent may be allowed to run a package. That does not mean a log message is allowed to choose the package name and arguments.

The authorization decision needs both sides:

who may perform the action
       plus
what may influence the action

Current access-control systems are much better at the first than the second.

Preserve provenance through the whole trace

The missing evidence is not another copy of the final tool call. It is the causal path from source material to side effect.

At minimum, I want an agent trace to retain:

Field	Why it matters
Run and session ID	Joins the investigation across agent, model, and tool systems
Source system and event ID	Locates the exact WAF event, log entry, issue, or document
Source principal	Identifies who or what was able to create the content
Trust classification	Distinguishes operator input, internal data, and externally influenced data
Content digest	Proves which material the agent saw without requiring every system to retain it forever
Transformation history	Shows summaries, retrieval, enrichment, and agent-to-agent handoffs
Tool name and canonical arguments	Records the requested side effect in a comparable form
Approval and policy decision	Shows which rule or person permitted execution
Target resource and result	Establishes what actually changed
Causal link	Connects the source evidence to the tool request it influenced

That final link is the hard part. Model reasoning is not a deterministic program trace, and a list of retrieved documents does not prove which sentence caused a decision. We can still retain the context set, content origins, sequence of reads, proposed plan, tool request, and approval record. That is enough to build useful detections and investigate suspicious outcomes.

Without it, the audit log says an authorized agent made an authorized DNS change. That is true and almost useless.

Detect source-to-side-effect transitions

The strongest analytics are joins between an untrusted source class and an unrelated privileged effect.

Examples include:

• WAF event read, followed by DNS or email-routing modification;
• browser-submitted telemetry read, followed by shell or package execution;
• error report read, followed by a credential, deployment, or repository change;
• external ticket or pull-request comment read, followed by modification outside that ticket or repository;
• one agent’s generated remediation accepted by another agent without the original sources;
• encoded URLs, package commands, IP addresses, or credential requests copied from telemetry into tool arguments;
• infrastructure changes whose argument values appear only in externally influenced content.

The correlation window should follow the task, not just elapsed time. An agent may read an event, inspect several systems, generate a plan, wait for another process, and act later. A five-minute SIEM window may miss the relationship while the agent trace retains it naturally.

I would also alert when a single session combines broad evidence readers and powerful writers. That is not automatically malicious, but it is the configuration that makes this class of attack consequential.

Separate the reader from the writer

The cleanest architectural control is to stop one context from doing both jobs.

An investigation agent can read externally influenced evidence and produce a structured finding. A remediation service can accept a narrow schema, independently verify important values, apply policy, and perform an approved change.

For a DNS finding, that schema might include:

{
  "record": "mail.example.com",
  "observed_problem": "DMARC policy mismatch",
  "recommended_action": "review",
  "evidence_ids": ["waf-event-1234"],
  "externally_supplied_values": ["rua", "cname_target"]
}

The remediation system should not accept an arbitrary command or destination copied from the source. It should retrieve the current record through its own trusted path, calculate the expected value from policy, and require approval for a material change.

This is more work than telling the model to ignore instructions in logs. It is also a real security boundary.

What agent-jackstop does and does not do

Tenet released agent-jackstop alongside the research. It is useful, but it should be described accurately.

The repository provides hardening configurations for Cursor and Claude Code. The controls include default-deny network egress, command approval, filesystem restrictions, protections around secrets, and instructions for treating tool output as untrusted.

That is prevention and blast-radius reduction. It is not a detection product, and its own documentation says the configurations do not make an agent immune to prompt injection.

There are practical tradeoffs. The sample allowlists permit common registries so ordinary development remains possible. Those destinations can also host attacker-chosen packages. Teams must narrow the list to their actual workflow and decide which commands always require approval.

The controls are still worthwhile. If a poisoned log convinces an agent to run a package, blocking unapproved command execution and outbound connections can break the chain. If the same agent can directly update DNS through an approved MCP tool, network sandboxing around subprocesses may not address that path.

Use the configurations as one layer, then test them against the tools and data sources in your environment.

An incident runbook for suspicious agent actions

When an agent-driven infrastructure change looks legitimate but unexpected, the first question should be: what did the agent read before it acted?

The investigation should preserve:

1. The complete agent run, including model and configuration versions.
2. Every retrieved item and its source principal.
3. Tool calls, canonical arguments, approvals, and results.
4. The original telemetry before enrichment or summarization.
5. Any agent-to-agent messages or generated recommendations.
6. Credentials and tool scopes available during the run.
7. Related changes to memory, configuration, skills, and startup files.

Containment should revoke the agent’s write authority, preserve the evidence-reading path, and verify the affected resource through an independent channel. If DNS changed, do not ask the same compromised context to confirm that DNS is now correct.

Then replay the task in a safe environment with the poisoned source removed, transformed, and explicitly marked untrusted. That tells you which control actually breaks the chain.

The log is part of the attack surface now

Observability systems have always contained hostile data. The difference is that people used to read it and decide what to do. Agents compress that distance. They retrieve evidence, interpret it, choose a tool, and act while carrying the authority we gave them.

The answer is not to strip useful detail from every log. It is to retain provenance, separate evidence readers from infrastructure writers, validate values through trusted sources, and detect impossible transitions from attacker-influenced content to privileged effects.

A blocked request should be evidence that an attack failed. It should not become the instruction that finishes the job.

Sources

• Tenet Security: GhostJacking Attacks
• SC Media: GhostJacking turns error logs into indirect prompt injections
• Tenet Security: agent-jackstop