Securing AI Coding Agents: What GhostApproval, Ghostjacking and CVE-2026-62830 Have in Common

Three vulnerabilities became public in the summer of 2026 that look unrelated at first glance: a symlink flaw in six AI coding assistants, a prompt injection attack delivered through log files, and a critical privilege escalation in a Microsoft cloud agent.

Different vendors, different techniques, different targets. And still the same underlying problem: the agent does something other than what the human sees or approved. If you run AI agents in production, this pattern matters more than any individual patch, because it outlives all of them.

GhostApproval: The approval dialog names the wrong file

On 8 July 2026, Wiz Research published a flaw affecting six widely used AI coding assistants at once: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity and Windsurf.

The underlying technique is decades old. Symlink following (CWE-61) is well understood: a file is really just a pointer to another one, and writing to it writes somewhere else. What is new is what happens in the interaction with the agent.

In one of the demonstrations, the assistant reads a file, explicitly notes in its own reasoning that this is a symlink pointing at a sensitive system path, and writes to it anyway. The approval dialog shown to the developer names only the harmless file.

The agent knows. The human approving the action does not.

Vendor responses are instructive. Amazon, Google and Cursor treated the report as a vulnerability and shipped fixes, Cursor under CVE-2026-50549. Augment and Windsurf had not shipped a fix at time of publication. Anthropic disagreed on Claude Code: a user who trusts a directory and approves an edit owns that decision, putting it outside their threat model.

That position is defensible, but it moves responsibility to the place where the information is missing. An approval is worth only as much as what the dialog tells you.

Ghostjacking: When log files become instructions

At DEF CON 34 on 9 August 2026, Tenet Security presented an attack that requires no vulnerability in the classical sense. Ghostjacking exploits the fact that coding agents routinely read content that outsiders can write into: error messages, blocked network requests, monitoring alerts, bug reports.

The attacker plants instructions in that data. The agent reads it as part of its context and acts on it. Against Claude Code, configured according to the officially recommended setup, this worked in nine out of ten attempts.

The uncomfortable part for security teams is in the fine print of the talk: every single step in the attack chain is a legitimate, authorised operation. EDR, WAF, IAM, VPN and firewall raise no alert, because there is nothing to block. The agent is allowed to do all of it. It is simply doing it for the wrong person.

Tenet's own recommendations reduce the problem to one sentence: data an agent reads must never become an instruction it runs.

CVE-2026-62830: The agent as a master key

In the August patch cycle, Microsoft fixed a flaw in the Azure SRE Agent rated CVSS 9.9. Technically it is a missing authorisation check (CWE-862) in the on-behalf-of flow, the very mechanism meant to ensure an agent acts only with the rights of the respective user.

When that flow breaks, an attacker inherits the service principal's permissions across the managed environment. The rating carries the "Scope Changed" flag for exactly that reason: the damage does not stay with the agent but reaches everything its managed identity can touch, from runbooks and telemetry to the Azure resources behind them.

Because the service runs entirely on Microsoft's side, customers had nothing to patch. The fix happened server-side. Convenient, and at the same time the heart of the problem: an agent's permissions are rarely as narrow as assumed at rollout, and the blast radius only becomes visible once someone exploits it.

The shared pattern

Three incidents, one blueprint:

1. The agent holds broad permissions, because it would be useless otherwise. It writes files, runs commands, touches infrastructure.
2. The agent processes content that other people control. Repos, logs, tickets, web pages, tool output.
3. The control point sees less than the agent does. The approval dialog shows a harmless file. The firewall sees an authorised connection. IAM sees a valid token.

As long as those three hold, every new agent creates a new attack surface. Patches close individual cases, not the pattern.

Why the classical stack sees nothing here

Security tooling is trained to spot anomalies: unknown processes, suspicious destination IPs, unusual privileges. An agent falling for Ghostjacking produces none of that. It uses the tool it is supposed to use, with the permissions it is supposed to have, against destinations that appear on no blocklist.

The decision that goes wrong here is semantic, not network-level: a piece of text meant as data gets read as an instruction. Only something that inspects the content before it takes effect can make that distinction.

What helps on the endpoint

Patronus works at exactly that point, because that is where content and action meet.

Visibility first. Before you can control agents, you need to know which ones are running. On an average developer machine that means several coding assistants and a handful of MCP servers, most installed without IT approval. That inventory runs locally on the device, not through a cloud detour.

Inspect content before it becomes an instruction. Our Wolf Defender model is trained for precisely this: detecting prompt injection, not only in what the user types but also in what tools return. Fetched web pages and log output are the common carrier for indirect injection, which is the case Ghostjacking exploits.

Evaluate tool calls, not just text. The Husky models classify what a tool call actually touches: target, operation and data flow properties. A sensitive source combined with an external sink in a single call is a precise, deterministic condition for a policy decision, no matter how harmless the filename in the approval dialog looks.

All of it before execution, locally. Checks that only apply after the fact document an incident, they do not prevent it. And checks that ship content to someone else's cloud create the very exposure they are supposed to contain.

None of this replaces patching. It makes sure the next flaw of this shape does not immediately become an incident.

What you can check this week

• Which coding assistants and MCP servers actually run on your developer machines, and who approved them?
• Which agents have outbound network access enabled by default?
• Do your approval dialogs show the real target path of an action, or only the name the agent chose to display?
• What permissions does the identity behind your cloud agents hold, and what could an attacker reach with them?
• Which data sources your agents read can be written to from the outside?

If you cannot answer the first question, start there. Everything else builds on it.

See what runs on your own machines

The full version of Patronus Protect launches shortly. Everyone on the waitlist gets the first month free: patronus.studio/download.

If you want to know where your organisation stands on the EU AI Act before that, our free assessment works through 23 questions derived from the regulation itself and produces a PDF report with prioritised findings. No registration, everything runs in your browser.

Sources

• Wiz Research: GhostApproval, a trust boundary gap in AI coding assistants, 8 July 2026
• Tenet Security: Ghostjacking, presented at DEF CON 34, 9 August 2026
• Microsoft Security Update Guide: CVE-2026-62830, Azure SRE Agent, Elevation of Privilege, CVSS 9.9, August 2026