Hook
Over the past seven days, a signal appeared in a place it had no business being. A blockchain and Web3 intelligence feed โ the kind that normally lives on wallet clusters, DEX flows, and validator exits โ ran a full-length deep-dive on AI Agent security. Not a single paragraph touched a chain. No contract addresses. No token flows. No governance proposals. No NFT floor deltas. Just a national CERT advisory, a DEF CON talk, a heuristic-scan count of 2,388 exposed endpoints, and a stated hijack success rate of 85% to 90% against mainstream coding agents.
That mismatch is the first data point I logged, and it is not noise. Clusters don't watch the candle, watch the cluster. The candle here is "an AI security story." The cluster is a Web3 property publishing it with zero Web3 content, which tells me two things at once: the platforms that fund agent automation are converging with the platforms that fund on-chain settlement, and the information source I am reading is a secondary aggregator, not a primary one. Both facts change how I grade everything downstream.
Here is the anomaly in one line: an attack class that executes entirely inside an agent's legitimate authorization envelope, hijacks the most trusted tools in a developer's stack, and โ by the source's own account โ trips none of the controls we have spent fifteen years building. That is the case file. Let me open it.
Context
To read this properly, you need the architecture, not the headline. The subject is the Model Context Protocol โ MCP โ an integration standard pushed by Anthropic at the end of 2024 to let AI agents read and act on external systems: code repositories, observability platforms, CDNs, CRM tools, ticket trackers, logging pipelines. MCP's selling point was openness. Its design flaw is the same openness viewed from the security side.
The attack class being named here is indirect prompt injection, a concept the offensive and defensive research communities have documented for well over a year. The innovation on display is not a new vulnerability category. It is packaging. The report describes a chain โ loosely branded "Ghostjacking" โ that combines a known mechanism (indirect prompt injection), a known trust defect (MCP's implicit trust in external data), and specific SaaS integration points (Cloudflare, Datadog, Sentry) into a reproducible, quantified exploit.
The vocabulary matters because it frames the rest of the analysis. Simon Willison's "Lethal Trifecta" โ private data access, exposure to untrusted content, and outbound communication capability โ maps almost perfectly onto what an MCP-integrated agent does by default. An agent that can read your private repositories, ingest content from the open web or a third-party feed, and then send data outward satisfies all three legs simultaneously. When all three legs are present, prompt injection stops being a "model output quality" problem and becomes an authorization and execution problem.
The timeline the source presents runs from June 2026 through October 6, 2026: a CSA Labs study in June, DEF CON 34 in August, a Tenet Security release, a Sentry response, and a Nigerian national CERT advisory. That entire window sits later than my own knowledge cutoff, which forces a specific discipline onto this piece. I cannot independently cross-verify the ngCERT advisory, the Tenet Security DEF CON materials, the agent-jackstop repository, the CSA Labs success rates, or the Claude Desktop sandbox findings through open public sources. So I apply conditional acceptance: if the statements are accurate, then the following conclusions hold โ and I cap every confidence grade accordingly, most of them in the C range, a few at B, the infrastructure layer at D.
This is where eleven years of on-chain forensics pays a dividend. In crypto, we learned early that the narrative is cheap and the ledger is expensive. A project can promise anything in a whitepaper; the transaction history is the only witness that cannot lie. I bring the same ethic here. Code is truth. Config is truth. A success rate is only as good as the environment it was measured in. So let me walk the evidence chain and mark every link I cannot pull on myself.
Core
The single most important technical claim in this entire file is what I call the legitimate-action paradox. The source states plainly that the attack's actions โ code execution, cloud credential access โ fall inside the agent's authorization range, and therefore conventional security controls do not fire. Endpoint detection and response, web application firewalls, identity and access management, VPN logs โ none of them alarm. Read that again, because it is not a bug in those systems. It is a category boundary. Those controls were engineered to distinguish authorized human or programmatic behavior from unauthorized behavior. They have no model for "authorized behavior carrying an adversary's intent." The agent is not breaching the perimeter. The agent is being the perimeter.
Clusters don't watch the candle, watch the cluster. Everyone will stare at the 85% number and argue about it. The real cluster is the reason the number can exist: a system where the executing identity is always legitimate, because the hijack lives in the data the identity consumes, not in the identity itself.
Trace the root cause and it resolves to a single architectural defect โ data and instruction are not separated at the transport layer. MCP, as a protocol, does not mark the provenance of a payload as "data" versus "executable instruction." The source states directly that agents are designed to treat external data as instructions. That is the disease. It has nothing to do with which model is running. It is a systems architecture flaw baked into how the integration layer treats everything that enters the agent's context window. Every byte that arrives from a tool โ a log line, a ticket body, a CDN configuration, an error report โ should be treated as untrusted code, because functionally it is.
Now the three vectors, and I want to be precise about why the third one matters more than the other two.
Vector one is Cloudflare, routed toward domain hijacking. Vector two is Datadog, routed toward code execution plus cloud credential theft. Vector three is Sentry, and it is the one with genuine theoretical novelty. Sentry is an error-monitoring platform. Its data has an implicit authority: it looks like system-level telemetry. When an agent ingests Sentry error payloads, it does not treat them as a stranger's text. It treats them as internal truth. That is how you manufacture an insider effect without ever compromising an insider. You do not need to steal a badge. You need the agent to believe the monitoring platform vouched for you.
The mechanism is a Sentry DSN โ the client-side key a platform uses to accept error reports. DSNs are designed to be public. They are shipped in client code, they are meant to be exposed, and that is fine in a world where only a human reads an error message. But in the agent world, the DSN becomes a trusted input channel into a system that executes actions. The source reports a scan finding 2,388 organizations with injectable, publicly exposed Sentry DSNs, including 71 sites inside the Tranco top-1M ranking. That is the scale evidence, and it is the part I would verify first if I had shell access to a validation environment.
Then the numbers climb, and the climb itself is a signal. CSA Labs in June 2026 reports 85% success for Sentry DSN injection against three named coding agents. By DEF CON 34 in August, the source reports 90% success against one of them using a Cloudflare-recommended configuration. A near-ninety-percent success rate is not a boundary-condition vulnerability. Boundary conditions live at 2%, 5%, maybe 12% with specific preconditions. Eighty-five to ninety percent means the default configuration is the vulnerability. And the direction of travel โ up from June to August โ reads less like defense improving and more like offense optimizing faster than defense adapts. When a success rate rises over a two-month window, you are watching the attacker iterate, not the defender.
There is a fourth finding that sits orthogonal to the MCP chain and deserves its own line: the source reports that Claude Desktop's envoy egress gateway had a JWT cross-reuse problem across containers โ a classic session-token over-reuse defect, and reportedly fixed without a published CVE. I flag the CVE omission deliberately. In a deployment where multiple vendors adopt the same egress architecture, a silent fix means every other adopter cannot self-check against a known advisory. That is a transparency deficit dressed as discretion. It is the same failure mode I document in crypto when a team patches a bridge exploit quietly and lets the next fork inherit the bug.
Now the defense side, because the source is honest that there is not much of it. The tool released โ agent-jackstop โ takes a capability-minimization approach: restrict, by default, what the agent is allowed to do. Reduce the blast radius. Give the agent fewer reachable actions so that a successful injection has less to grab. The design philosophy is correct, and it is exactly the philosophy I would apply. But understand its ceiling. Capability minimization lowers the explosion radius; it does not lower the ignition probability. As long as an agent must read external data to be useful โ and that is the entire point of an agent โ the injection surface remains open. You are shrinking what the fire can consume, not preventing the spark.
The source also makes a sharper defensive claim: that detection is ineffective and defense must move forward to the configuration layer. I accept the direction of that claim and reject its absoluteness. The correct framing is not "detection is dead." It is "detection at the perimeter is dead for this attack class, because the perimeter never sees an unauthorized action." The migration is real โ from detection to configuration, from alerting to capability control, from EDR and SIEM toward policy engines and agent gateways. But calling detection universally useless is the kind of absolute that should trigger your skepticism reflex, not your agreement reflex.
Here is where this stops being an AI story and becomes a blockchain story, and I do not think the source even noticed. The reason a Web3 property is running this piece is that the two attack surfaces are fusing. An AI agent that manages a crypto wallet, executes DeFi strategies, or signs governance transactions is the exact Lethal Trifecta in production: it holds private data (keys, positions, strategies), it ingests untrusted content (market feeds, social signals, on-chain metadata), and it holds outbound capability (it can move funds). Every property I value in that architecture is also an attack vector. When I clustered 500,000+ wallets across the Terra ecosystem in 2022, I was hunting for insider behavior in a single deterministic system. The agent layer turns every integration point into a candidate insider, and there is no single ledger to reconcile against. That is a harder forensic problem than anything I have worked on.
So the honest state of the technology is this: the attack technique is at scale-validation stage โ it has published success rates, a conference platform, and a national advisory. The defense technique is at proof-of-concept stage โ an open-source hardening configuration with no enterprise productization behind it yet. That asymmetry is the whole picture. Offense has a number. Defense has a repository.
Contrarian
Correlation is not causation, and a compelling narrative is not a proven threat. Let me apply pressure to the file in three places, because the source grades its own claims at C and D and I think that is correct โ but it does not push hard enough on the framing.
First, the vulnerability-branding problem. Ghostjacking, Agentjacking, and the earlier MCP OAuth complexity and ClawSecure reports all get distinct names. Naming is not neutral. It is a commercialization strategy. In security research, a named vulnerability gets conference slots, press coverage, and inbound commercial leads. The incentive structure rewards a new brand over a new mechanism. And here is what the branding obscures: these are not independent new threat classes. They are the same source pathology โ indirect prompt injection โ wearing different hosts. Cloudflare, Datadog, Sentry are examples, not the complete set. The same logic ports to any external data source an agent can read: issue trackers, wikis, log platforms, CRM records. Calling each host a new threat manufactures the illusion of an expanding frontier when the truth is a single unfixed design debt. I have watched the same dynamic in crypto โ every new "exploit class" on the timeline often turns out to be a re-skin of a known primitive. The names multiply; the primitive does not.
Second, and this is the one I most want on the record, Sentry's "technically impossible to defend at the platform layer" is a suspiciously convenient disclaimer. Think about what a platform can actually do: sign its DSN requests, verify origin, rate-limit ingestion, filter sensitive payloads before they reach a consuming agent. None of that is exotic. Claiming platform-layer defense is impossible while offloading all responsibility onto the integrator is textbook vendor risk transfer โ the platform keeps its customers, sheds its liability, and points downstream when the incident review happens. The source reports this position without interrogating it. I will not extend the same courtesy. When a platform says "we cannot protect you here," the correct forensic response is to ask what protections it chose not to build, not to accept the impossibility claim as physics.
Third, the authority inflation. A national CERT advisory carries real weight, and I respect the work CERTs do. But ngCERT is Nigeria's national CERT, and its advisory has limited direct enforcement power over the global AI supply chain. The source's framing leans hard on "Government-Level Threat," which reads as authority backing to increase narrative mass. That may be a threat-severity designation rather than a claim of global regulatory force โ but the ambiguity is doing rhetorical work, and it should not. The advisory is a data point. It is not a mandate. I grade it as signal, not as law.
Underneath all three critiques is the question the source never asks directly: should the protocol layer โ MCP's creators โ own a secure-by-default responsibility? The source routes the entire defensive burden to deploying organizations' configuration choices, which implicitly accepts the protocol's unsafe defaults as a fixed given. That is the same logic I reject in governance design. When a system is built so that the safe path requires every participant to independently opt into security, you have not built a secure system. You have built a system that distributes blame. I have spent years documenting how governance delegation concentrates power in a handful of wallets while the framing advertises participation; the MCP dynamic rhymes with it exactly. An open protocol, centrally authored, with security as an integrator's homework, is not decentralization. It is a compliance shield with a developer-friendly coat of paint.
I want to be explicit about what this file does not establish. It does not establish that these attacks are weaponized in the wild โ every documented success appears to be in controlled research conditions. It does not establish how the 85% and 90% figures behave against configurations with tool allowlists or human confirmation on sensitive actions. It does not provide the effectiveness data for agent-jackstop โ whether it blocks attacks or merely shrinks impact. It does not tell us whether closed, commercial enterprise agents inherit the same exposure. And it does not answer whether any regulator beyond ngCERT has moved. Four of those five are the questions that separate a research finding from a live risk, and none of them are answered. Clusters don't watch the candle, watch the cluster โ and the cluster of unanswered questions here is larger than the cluster of answered ones.
Takeaway
The signal to watch next week is not another named attack. It is whether MCP ships a security-enhanced protocol version with provenance or attestation at the transport layer โ because until data and instruction are separable by design, every downstream hardening is a bandage on a structural wound. Secondary signals: any confirmation of real-world weaponization, any mainstream cloud vendor baking agent-hijack protection into a managed agent runtime, and any insurer underwriting agent-hijack liability. Those three, in that order, tell you whether this is a research paper or a market.
And if you are running an agent that touches value โ on-chain or off โ the audit does not wait for the CVE. Enumerate every external source your agent reads. Treat each one as untrusted code. Cap the capabilities. Confirm the dangerous actions by hand. The perimeter you built will not warn you, because in this attack class there is nothing unauthorized to detect. The question worth sitting with is not whether your agent can be hijacked. It is whether, when it is, your controls were ever designed to notice โ or whether you built a system that trusts the data and calls that trust a feature.