Something broke at DEF CON last week. Not a vulnerability in the traditional sense — no CVE has been filed, no vendor patch is coming, and nothing in your current security stack will flag it.
Tenet Security presented GhostJacking on August 9. The attack class is built on a simple, uncomfortable finding: the security tools protecting your infrastructure — your WAF, your monitoring stack, your error tracker — are now attack delivery channels if an AI agent reads them.
The headline: in testing against Cloudflare's recommended configuration, AI coding assistants followed attacker-controlled instructions 90% of the time. Cloudflare did everything right. The malicious request was blocked. It was logged. And that log entry is what carried the attack in.
How the Cloudflare case works
Walk through it once and it sticks.
An attacker sends a request to your web application. It's malicious — credential stuffing, injection attempt, doesn't matter — and Cloudflare's WAF blocks it exactly as designed. The request never reaches your server.
Cloudflare also logs the blocked request, including the full payload. That's useful for security review. Your team, or an AI agent set up to help with security operations, will eventually look at those logs. "Summarize the blocked Cloudflare requests from this morning" is a completely reasonable thing to ask an AI assistant to do.
The malicious request contained hidden instructions formatted to blend with log metadata. When the AI agent reads the log, it processes those instructions as part of its task. In Tenet's demonstrated scenario, the agent — following what it read in the log entry — modified the organization's DNS records and began redirecting web and email traffic to attacker-controlled infrastructure.
The firewall blocked the request. The log of that block is what delivered the attack.
That's the part that should sit with you for a minute. Every security-conscious team's first instinct when they see "blocked by WAF" is relief. The thing that creates relief is the thing that creates exposure. The harder you've pushed traffic through Cloudflare, the more of those logs exist.
The Datadog path doesn't even need access to your app
The Cloudflare attack requires the attacker to reach your application's public surface. The Datadog variant only requires one thing: a client-side Datadog key.
Client-side Datadog keys are not secrets. They're embedded in front-end code so browsers can send telemetry. They end up in public GitHub repositories, CDN-hosted JavaScript files, and occasionally documentation. Searching for exposed Datadog client keys is not hard.
With a client-side key, an attacker can submit a crafted diagnostic event directly into your Datadog workspace. It looks like legitimate telemetry — a custom metric, a latency alert, a performance anomaly. When an engineer asks an AI agent to investigate, the agent processes the attacker's content. In testing, this led to the agent accessing environment variables and cloud credentials from its execution context and shipping them out.
This variant doesn't require the attacker to reach your application at all. The key is in the public. The poisoned data goes in. The agent reads it. Done.
The Sentry angle: agent trusting agent
A third path in Tenet's research targets Sentry — but differently from the DSN injection attack we covered in June. That one required write access to Sentry's ingest API via a public DSN. GhostJacking's Sentry path exploits something newer: Sentry's own Seer AI, which analyzes errors and generates recommendations autonomously.
The attack chain here is agent-to-agent. An attacker submits a malicious report that shapes what Seer's AI concludes about an error event. A separate AI coding agent — Cursor, Copilot, whatever your team runs — fetches Seer's recommendation to help debug. It trusts the recommendation because it came from another AI in your toolchain. The original malicious input is invisible; the coding agent only ever reads a trusted AI's output.
You can train developers to be skeptical of data from the public internet. Training an AI agent to be skeptical of another AI agent in the same toolchain is a harder problem — and in most setups, it isn't happening at all.
Who this actually affects
Tenet estimates more than 15,000 organizations are currently exposed through Cloudflare configurations alone. This is not an enterprise-only attack surface.
Cloudflare is often the first security layer a 10-person org deploys because it's cheap, effective, and requires no IT department. Datadog client keys are in the front-end JavaScript of small SaaS products, NGO donation pages, public sector web tools. Sentry is near-universal in dev shops. If your org runs any of these alongside an AI coding assistant or an AI-enabled operations workflow, you have a GhostJacking surface.
The common thread across all three vectors: an AI agent has read access to an operational data source that the public internet can write to.
What to do this week
Audit what your AI agents can read. List the data sources your AI assistants touch — Cloudflare event logs, Datadog dashboards, Sentry projects, GitHub issues, Slack alert feeds. For each one, ask: can the public internet write data into this source? If yes, that source is a potential injection point.
Add a human checkpoint before agent-initiated infrastructure changes. Use AI to summarize security events. Don't let agents act on them directly — not DNS changes, not firewall rule edits, not environment variable updates. One confirmation step between "agent recommends" and "change executes" is the clearest mitigation here.
Scope your Datadog client-side key permissions. If your client-side key can submit custom events of arbitrary shape, restrict it. The Datadog attack depends on the attacker being able to craft a diagnostic event that looks plausible. Limiting what that key type can actually submit raises the effort required.
Rotate credentials if AI agents have been reading Datadog or Sentry data. Especially AWS keys, service tokens, and anything stored as an environment variable in the agent's runtime. If these agents have been active for months, treat the rotation like you would treat discovering an unknown device on your network.
The thing that doesn't go away
The AgentJacking research in June showed that AI agents trust data retrieved from connected tools. CoreBreak, disclosed at Black Hat the week before GhostJacking, showed that attackers can sometimes skip the model entirely and trigger tool calls directly. GhostJacking closes the last gap in that picture: even when you've secured your application and your WAF is doing its job, the record of that protection is now an attack surface.
The attack arrived through the log of the thing that was supposed to stop it.
That's not a patchable bug. It's a design property of systems where AI agents read operational data that the internet can influence. Understanding where that's true in your stack — and making deliberate choices about what those agents can do with what they read — is the work.
That's exactly the kind of audit we run in early sprint engagements. Get in touch if you want eyes on your AI agent setup before someone else looks at your logs.