Threat Analysis

Ghostjacking: when your AI agent is told what to do by someone else

A DEF CON 34 disclosure turned observability data into an instruction channel for AI agents. The uncomfortable part is that nothing was exploited — the agent used exactly the access it was given.

What was actually demonstrated

Ghostjacking is not a software vulnerability. There is no memory corruption, no authentication bypass, no CVE to patch. The technique abuses a property of how agentic systems are wired: they read from sources they trust, and they act on what they read, and there is no reliable boundary between those two facts.

The delivery mechanism is elegant precisely because it is so ordinary. A web application firewall exists to block malicious requests — and then to record them verbatim. That verbatim record is the payload. An attacker sends a request they fully expect to be blocked, with instructions embedded in the request body or headers. Cloudflare dutifully logs it. Days later an analyst asks their AI assistant to review blocked events, the agent retrieves the log, and the attacker's text arrives inside the model's context window wearing the authority of a trusted security platform.

Three delivery surfaces were shown. Blocked-request logs in Cloudflare. Fabricated diagnostic alerts in Datadog. Crafted error reports in Sentry — where a single fake bug report was enough to drive an AI coding assistant into executing attacker-supplied code on a developer workstation.

The agent-to-agent variant is the one to watch

The most instructive part of the research involves Sentry's Seer. An attacker-controlled report influences Seer's analysis; a second, separate coding agent then consumes Seer's conclusion and acts on it without ever seeing the original poisoned input.

This is instruction laundering. One AI system converts hostile input into an apparently trustworthy recommendation, and the taint is stripped at the boundary. Every multi-agent architecture currently being built has this property, and almost none of them propagate provenance between agents.

The attacker did not need to break authentication. They needed to be quoted.

Why "what can the agent access?" is the wrong question

Entitlement review is a static discipline. You enumerate what an identity can reach, you apply least privilege, you re-certify quarterly. It works because it rests on an assumption that has held for the entire history of access control: the intent behind an authenticated identity is stable and belongs to its owner.

Agentic systems void that assumption. Intent is now supplied at runtime, in-band, by whatever text lands in the context window. Anyone who can write into a data source the agent reads has partial write access to the agent's objectives. Log lines, ticket comments, alert payloads, pull request descriptions, indexed web pages, email bodies — all of it is an instruction channel now, whether or not it was designed as one.

Two questions replace the old one:

• What untrusted content can influence this agent? Not "what can it access" — what can reach its context, and who can write there. Any platform that records adversary-supplied input verbatim is by definition an untrusted channel, regardless of how trusted the platform itself is.
• What authority exists at the moment of influence? Credentials held, tools callable, systems mutable, and whether any of it is gated by a human at the point of action rather than at the point of provisioning.

Where those two overlap, you have an exposure. The size of the overlap is the size of the risk. That is a far more useful metric than an entitlement count, and almost nobody is measuring it.

Controls that actually cut the chain

Most of the vendor response so far has converged on "AI agent identity governance", which is IAM with new branding and does not address a failure mode where the identity behaves exactly as designed. The controls below are less interesting and considerably more effective.

The regulatory framing that gets this funded

If you are in scope for DORA, resist the instinct to file this under "AI risk". It fits existing articles more cleanly, and existing articles have existing budget lines.

An agent that can alter DNS, firewall rules or deployment configuration in response to data it ingested is an undocumented change path into a critical or important function. That is ICT change management and operational resilience, not emerging technology. The observability platforms carrying the payload are ICT third-party service providers, and the injection channel is a property of the contracted service. And an agent that closes a ticket as resolved after acting on attacker instruction is a direct failure of detection and incident classification.

Framed that way, the remediation is a change-control gap with a named owner. Framed as "AI risk", it becomes a working group.

What to do this quarter

• Inventory every agent with tool access. For each one, list its read sources and its write capabilities in two separate columns. The overlap is your exposure.
• Identify which read sources record adversary-controlled input verbatim. WAF logs, error trackers, ticketing systems, inbound email and public issue queues all qualify.
• Revoke mutating permissions from any agent whose primary job is investigation or analysis. Most do not need them and were granted them for convenience.
• Rotate Datadog, Cloudflare and Sentry API keys, and check whether any are exposed in public repositories or CI logs.
• Add agent-initiated changes to your change-management scope, with logging that records both the action and the input that triggered it.
• Test it. Plant a benign marker string in a blocked request, ask your agent to investigate, and see whether it treats the marker as data or as instruction. This takes an afternoon and tells you more than any questionnaire.

The last one is the point. Most organisations do not know which category their agents fall into, because nobody has asked the agent a hostile question yet. That is a cheap experiment with a clarifying result.