Tenet Security has published a technique it calls GhostJacking, extending earlier work on agent hijacking. The mechanism is one sentence long:
An AI cannot tell a real instruction from a trap hidden in the data it reads.
Poison a log entry or an alert. An AI agent reads it as part of doing its job. The agent executes what the data told it to.
Why logs are the ideal channel
Every other prompt-injection surface we have covered this month has a human somewhere near it. A poisoned PDF handed to Atlassian Rovo requires someone to upload it and ask about it. A malicious MCP server requires a developer to install it.
Monitoring data has none of that. It is machine-generated, arrives continuously, is trusted implicitly, and is precisely what an operations agent is deployed to read. Nobody reviews a log line before the agent sees it — that is the entire value proposition of putting an agent on logs.
And attackers can often write into logs without any special access. A failed login with a crafted username. A request with a chosen User-Agent. An error message that reflects attacker input. These are ordinary application behaviours; they become an instruction channel the moment something reads the log and can act.
The chain Tenet demonstrated
- Privilege escalation from the initial agent context
- Pivot to enterprise cloud infrastructure
- Data exfiltration, using a now-patched Claude Desktop sandbox escape
- Persistence through a backdoored agent configuration
Step four is the one that survives cleanup. Rotating credentials and patching the escape does nothing about a configuration file that tells the agent to keep doing what it was told.
Tenet's framing of the exposure:
Companies are handing AI agents the keys to their code, their monitoring, and their infrastructure.
That is not rhetoric — it is the deployment pattern. An agent with read access to logs and write access to infrastructure is what an AI SRE product is.
The Cursor CLI flaw, same week
Separately, Manifold Security disclosed a flaw in Cursor's CLI on 20 July 2026. Cursor patched it three days later.
A repository could execute any command it chose on your machine, as you, the moment you started Cursor's CLI agent in it.
Commands ran before the trust prompts appeared, and the sandbox was bypassed even when explicitly enabled.
Read those two clauses together. The trust prompt is the control users believe protects them, and it fired too late. The sandbox is the control security teams believe protects them, and it did not hold. A developer who did everything right — enabled the sandbox, intended to review the prompt — was still exposed by cloning a repository.
No CVE identifier was assigned in the reporting we saw, which means scanners keyed to NVD will not flag it. That is the same gap we wrote about with the Metabase advisory that carried no CVE.
Three days from disclosure to patch is a good vendor response and worth saying so.
What is actually new here
Prompt injection is not new, and we have covered a lot of it. What GhostJacking changes is who has to be involved.
| Vector | Requires |
|---|---|
| Poisoned document | A user uploads it and asks about it |
| Malicious MCP server | A developer installs it |
| Instruction-splitting | An attacker's server already connected |
| GhostJacking | Attacker can write a log line |
The last row has effectively no precondition in most environments.
What is not established
- No CVE and no patch list for GhostJacking. This is a technique, not a product bug. There is nothing to apply.
- Which agent products are affected is not enumerated. The demonstration used a now-patched Claude Desktop escape as one link in the chain; the technique itself is not specific to any vendor.
- No in-the-wild exploitation is reported. This is research.
- The Cursor flaw has no CVE in the reporting we found, so the affected-version range is whatever Cursor's own advisory says.
What to do
- Treat log and alert content as untrusted input to any agent that reads it. Not "monitor for injection" — assume it is present and constrain what the agent can do as a result.
- Separate read scope from write scope. An agent that reads monitoring data should not hold credentials that modify infrastructure. That single split breaks most of the chain.
- Put agent configuration under change control. The persistence step here is a config file. If nobody would notice it changing, that is the finding.
- Constrain egress. Same conclusion as every other injection story this month: if the agent cannot reach an arbitrary host, exfiltration stops being the easy part.
- Update Cursor CLI and check whether your developers ran it inside cloned repositories before late July.
The structural point is one we keep arriving at from different directions. Model-level defences do not fix this, because assembling scattered context into an action is what a capable agent does. The boundary that works is the one around the agent — what it can reach, what it can change, and who checks its configuration.
