GhostJacking is the most important attack name most security teams have never heard, and the reason it matters is not the cleverness of the payload. It is the mundane, almost boring chain of permissions that made it work. Tenet Security demonstrated on the DEF CON 34 main stage that a firewall doing its job, blocking a malicious request and logging it, creates the very document an AI agent later reads as a trusted instruction. The blocked payload becomes the prompt, and the agent, holding credentials issued months earlier, rewrites DNS. Nothing malfunctioned. No rule broke. Endpoint detection stayed quiet because the agent was authorized to do exactly what it did. That is the terrifying part: the system worked, and working is what got the company hijacked.
The fix, as OWASP co-lead Steve Wilson puts it, is not a better model or a longer system prompt. It is an authorization gate outside the model. The agent can propose the DNS change, but it cannot approve it. That single architectural split, proposal from approval, turns a high-impact action from an autonomous event into a human checkpoint. It is a simple idea that runs directly against the grain of how most teams are shipping agents today. Ivanti's own data shows 77% of security professionals are at least somewhat comfortable letting AI act without human review, and that comfort is precisely the exposure GhostJacking exploits. CrowdStrike has already pushed its prompt-injection taxonomy past 200 techniques, naming indirect injection through data an agent reads as the critical vector for tool-calling systems. The industry is not positioned to make Wilson's split quickly, and the economic incentives are not pushing them. Kayne McGladrey, a senior IEEE member, put it plainly: companies are accepting the risk deliberately or unconsciously, and they will keep doing so until the penalties outweigh the advantages.
What does this mean for a reader who is not running a Fortune 500 SOC? It means the question is no longer whether your model can spot an attack. It is whether your agent holds the authority to turn a blocked log entry into a production change. The GhostJacking chain works because the agent was given both read access to attacker-reachable data and write access to the systems that data describes. That is not a model problem. That is an identity and permission problem, and it is one you can test this week. Run the negative test: plant an adversarial instruction in a log your agent is expected to inspect, and keep the transcript. That transcript is the difference between claiming a control and showing a test of it. Enumerate your service principals, drop the pre-provisioned Microsoft first-party apps, filter to those with credentials, and ask who owns each one. For any agent with production authority, write the containment sequence before an incident, not during one: revoke the workload credential, disable the write-capable API, preserve the transcript, then validate and roll back.
The uncomfortable truth is that no sitting CISO has gone on the record with a change they made since August 9, or what it cost in agent capability. That silence is telling. Egiziago Cioffi, the architect who built and sold an Azure OpenAI assistant over SharePoint, learned the hard way that an evaluation set with no identity dimension cannot fail an authorization bug, no matter how high the faithfulness score. His fix was a query-time filter built from the asking user's group claims, so an unentitled chunk never reaches the model. GhostJacking turns on the same principle, but one level up: it is not about what the model knows, but what it may do. The gate belongs outside the model because a system that cannot reliably report its own shortcuts should not authorize its own actions. If your agent can read a log and change DNS, the only thing standing between a blocked payload and a rerouted domain is a policy check that does not exist yet. Build it before the next DEF CON, or accept that your tolerance for risk is doing the deciding for you.