Ghostjacking Attack: Why Blocked Logs Can Still Hijack Your AI Agents

The Ghostjacking attack became a same-day security story on August 10, 2026, when fresh SecurityWeek reporting surfaced Tenet's new DEF CON research on poisoned logs and trusted observability tooling. The reason it matters now is simple: many teams already let AI agents inspect blocked requests, error alerts, and debugging traces as if those systems were neutral data sources.

That assumption is starting to break. According to the public report and Tenet's accompanying research writeup, an attacker can hide instructions inside content from tools an agent already trusts, then let the agent carry out the rest: DNS changes, command execution, credential theft, and even persistence that survives across sessions.

Key Takeaway: Ghostjacking is not about tricking an agent with a weird prompt on a random website. It is about turning your own security, logging, and developer tooling into the delivery path.

Why the Ghostjacking attack matters right now

Security teams have spent the past year focusing on jailbreaks, browser agents, and supply chain abuse. Those are real problems, but the Ghostjacking attack lands in a nastier place. It targets the content that defenders already expect AI to read during normal triage.

That is what makes this story distinct from Hexon's recent coverage of the AI agent visibility crisis, Claude Code security guidance, AI coding agent malware from clean repos, and the Mastra AI supply chain attack. Those posts focused on governance, sandboxing, or trusted packages. Ghostjacking pushes the problem into the telemetry itself.

Most teams now want agents to do at least three things:

• read logs and alerts faster than a human can
• suggest or apply a remediation
• move across connected tools without repeated approvals

That combination is exactly where the danger lives. Once the same agent can both read externalized operational data and act on what it reads, the distance between observation and compromise gets very small.

Key Stat: Tenet says the Cloudflare path worked 9 times out of 10 against Claude Code, while the Datadog path built on 2,700+ exposed front-end keys the researchers found online.

How the Ghostjacking attack actually works

The easiest way to understand Ghostjacking is to stop thinking of logs as passive records. In an AI workflow, logs, alerts, bug reports, and incident summaries are no longer just evidence for a human. They become machine-readable input that can influence a system with real permissions.

The attack chain described in the reporting has a consistent pattern:

1. The attacker plants malicious text in a source the agent is allowed to read.
2. The agent treats that text as meaningful instruction or trusted remediation context.
3. The same agent, or a second agent downstream, uses its approved tools to take action.
4. The action looks legitimate because it happens through authorized APIs and approved workflows.

That last point is the part too many teams will underestimate. Nothing has to smash through the firewall or exploit a classic memory corruption bug. The infrastructure can remain technically "secure" while the agent itself becomes the path around the control.

Cloudflare: the blocked request becomes the payload

In the Cloudflare example, a malicious request gets blocked at the firewall layer and logged word for word. An analyst then asks the agent to review blocked events. The agent reads the planted text, interprets it as remediation guidance, and can change DNS settings so the company's domain points somewhere the attacker controls.

That is why this story is more uncomfortable than a generic prompt injection warning. The request was already blocked. The defense did its first job. The problem is that the blocked content remained intact inside a trusted review workflow and the agent inherited enough authority to act on it.

Datadog: a fake urgent alert becomes command execution

The Datadog path is operationally simpler and probably more relatable for engineering teams. Tenet says a publicly exposed front-end key can be used to create a fake urgent diagnostic alert. When an engineer asks the agent to check the error, the agent consumes the malicious content and runs the attacker's command.

From there, the risk moves fast:

• code execution on a trusted workstation
• theft of environment secrets
• theft of cloud credentials
• follow-on access through legitimate developer context

This is the same trust collapse that showed up in the CSS webmail attacks, only in a different layer. In both cases, the dangerous step is not the first untrusted input. It is the point where a trusted interface quietly wraps that input in credibility.

Sentry: one AI can vouch for another

The Sentry example may be the most important for the next wave of agent design. SecurityWeek says a crafted report can influence Sentry's own AI assistant, Seer, which then passes a fake fix downstream. A coding agent that trusts Seer executes the attacker's code without ever seeing the original malicious wording.

That creates a cross-agent trust problem. One model does not need to be fully compromised if it can launder a malicious instruction through a second system that accepts its output as guidance.

Common Mistake: Treating "AI reviewed this already" as a trust signal. In multi-agent workflows, one agent's summary can become another agent's injected instruction.

Where teams will misread the risk

The first mistake will be narrowing this into a Claude Code story. Claude Code appears in the reporting, but the shape of the risk is broader than one vendor. Any agent that can read noisy outside content and then touch infrastructure is exposed to the same category of failure.

The second mistake will be assuming this is only about obviously malicious user content. The attack works because the content shows up in places engineers already trust:

• WAF logs
• observability alerts
• bug reports
• AI-generated incident summaries
• cross-tool remediation suggestions

The third mistake will be thinking the main fix is better prompting. It is not. Better instructions may help at the margin, but the decisive controls live outside the model: network boundaries, approval policies, tool scoping, trust labels, and logging of agent actions.

This is also why the story clears Hexon's uniqueness bar. The main lesson is not "prompt injection exists" or "an agent did something weird." The useful lesson is that security telemetry itself can become an instruction channel when the same system is trusted to investigate and to remediate.

What to do in the next 24 hours

If your team uses AI coding assistants, observability copilots, or incident-response agents, there is a short hardening list that matters more than abstract debate.

1. Separate read access from write authority

If an agent reads logs, alerts, or tickets, do not let that same workflow directly change DNS, secrets, IAM roles, production configs, or code without an explicit second gate. The cleanest control is to split analysis from action.

2. Treat logs and alerts as untrusted content

Mark monitoring content with a lower trust level, even when it comes from internal tools. A blocked request, stack trace, or bug report can still contain attacker-controlled text. Agents should never silently upgrade that text into policy.

3. Default to network-denied or tool-minimized execution

Tenet's writeup argues for denying outbound network access by default and forcing human approval for risky commands. That is the right baseline. If an agent cannot freely fetch, post, or alter critical settings, the Ghostjacking blast radius gets much smaller.

4. Review cross-agent handoffs

Look closely at any path where one AI system summarizes or recommends an action and another system executes it. That includes observability assistants, ticketing copilots, remediation bots, and coding agents tied into the same workflow.

5. Audit persistence and memory

The reporting says the attack can leave backdoors in agent config, tools, or memory. Do not stop at revoking a key or closing a prompt. If an agent session or its stored state can preserve poisoned instructions, cleanup has to include that layer too.

Pro Tip: Your highest-value control may be a boring one: require a human to approve infrastructure-changing actions even after the agent's analysis looks sensible.

What better agent security architecture looks like

The Ghostjacking attack is a strong argument for a design rule many teams still resist: the model should not be the final decision point for whether operational data is safe to act on.

A more defensible architecture usually includes:

• trust labels that distinguish system instructions from logs, tickets, and retrieved content
• different execution profiles for analysis versus remediation
• hard server-side policy checks for destructive or external actions
• narrow tool exposure tied to the specific workflow
• durable audit logs showing which content triggered which action

This is the operational version of the problem Hexon has been tracking across Claude Artifacts malware on a real claude.ai link and the broader AI agent visibility crisis. Trust now moves sideways through normal business tooling, not only through obviously hostile websites.

The hardest habit change for teams will be cultural. Engineers often trust logs, dashboards, and internal alerts because those systems are part of the defensive stack. But if attackers can control even a slice of what lands there, the agent needs to treat that content more like email than gospel.

Final takeaway

The Ghostjacking attack deserves attention because it shifts the AI security conversation from prompts at the edge to telemetry at the center. A blocked request in Cloudflare, a fake urgent alert in Datadog, or a crafted Sentry report can all become execution paths when an agent is allowed to read, decide, and act in one continuous loop.

That is the real lesson from the August 10 disclosure. Your monitoring stack, developer tooling, and AI assistants may already form a hidden attack chain even when every component looks individually legitimate. If you want one concrete next step today, inventory every place where an AI agent reads operational data and can also take a privileged action. Those junctions are where Ghostjacking stops being a conference demo and starts becoming your incident.