Wiz just published details on GhostApproval, an attack that gets AI coding assistants to run malicious commands on a developer’s own machine, and the trick behind it isn’t new AI weirdness at all. It’s terminal escape sequence abuse, a technique that predates most of the engineers using it against you today by decades. The SecurityWeek writeup lays out how an attacker can manipulate what a developer sees in their terminal at the exact moment an AI coding tool asks for approval to run a command, turning the human-in-the-loop safeguard that everyone leans on for cybersecurity in agentic coding tools into theater.

That’s the part worth sitting with. The entire pitch behind “ask before you run it” AI coding assistants is that a human reviews the risky step before it executes. GhostApproval shows that review step can be spoofed using control codes that have existed since the VT100 terminal. Your eyes see one thing. The shell executes another.

Incident Summary: How GhostApproval Slips Past Human Review

The mechanics are almost insultingly simple once you see them. AI coding assistants that operate agentically, meaning they can read files, write code, and execute shell commands, typically insert a checkpoint before anything destructive: a rendered preview of the command, followed by a yes/no prompt. GhostApproval works by getting content the assistant ingests, a file, a dependency, a piece of scraped documentation, to carry ANSI escape sequences that rewrite what the terminal displays. The developer sees a benign-looking command. The shell runs something else entirely.

This isn’t a jailbreak of the model’s reasoning and it isn’t a novel prompt injection payload. It’s an old-school terminal spoofing trick, the same family of attacks used for years to hide malicious output in log files or fake command results in CI pipelines, now aimed at the one interface AI coding tools use to keep humans in control. The technique is decades old. The target, an AI agent with shell access sitting on a developer laptop with cloud credentials, source repos, and SSH keys, is what makes it dangerous right now.

Why Decades-Old Tricks Still Work On Brand-New Tools

Every wave of new tooling inherits the assumptions of the platform underneath it, and terminals were never designed with adversarial input in mind. Escape sequences exist to make terminals useful, moving the cursor, coloring output, clearing the screen. Nobody threat-modeled them against an AI agent that pipes untrusted content straight through to a rendering layer a human is about to trust with a yes/no decision.

That’s the recurring failure mode in cybersecurity generally: new interfaces get bolted onto old, unaudited layers, and the old layer’s threat model never gets revisited. A firewall and brute-force protection at the network edge do nothing here, because this attack never touches the network. It happens locally, inside a terminal window, between a file the assistant read and a human finger on the enter key.

Treat this as a defense in depth problem, not a single-control problem. If your only safeguard against a malicious AI-driven command is “the developer will notice,” you have one control, and GhostApproval just showed that control can be blinded. Threat detection needs to move to where the command actually executes, not just to where it gets displayed.

Containment And Hardening Steps For AI Coding Assistant Use

You don’t need to ban AI coding assistants to manage this risk, but you do need to stop treating the approval prompt as a real security boundary. Some of this is immediate, some of it is process you build into how these tools get rolled out.

• Run AI coding agents in sandboxed or containerized environments with no direct access to production credentials, cloud keys, or SSH-agent forwarding.
• Log and independently verify the raw command text an agent executes, not just what was rendered on screen, so incident response has ground truth to work from.
• Strip or neutralize ANSI escape sequences from any content an AI tool ingests from untrusted sources before it reaches a terminal renderer.
• Apply least privilege to the shell environment the assistant runs in; a compromised approval step should not equal a compromised developer machine.
• Pair endpoint monitoring with your existing threat-protection stack so command execution from AI agents gets flagged the same way an unusual login attempt would trigger scrutiny from something like ipban or ipbanpro on a server.

None of this is exotic. It’s the same security hardening discipline you’d apply to any tool with shell access and a trust relationship to your infrastructure. The mistake is assuming an AI coding assistant is a productivity feature rather than a privileged agent that needs the same scrutiny as a service account.

The Governance Gap AWS Just Tried To Close

It’s worth noting the timing against a separate but related move this week. AWS rolled out a centralized gateway for managing access, spending, and policy across Claude Code and Claude Desktop deployments, replacing the old model of per-developer cloud credentials scattered across laptops. That’s not a direct fix for GhostApproval, but it points at the right instinct: the individual developer’s judgment at an approval prompt was never going to scale as a security control once AI agents got shell access at every desk in the org.

Centralizing policy, credential distribution, and usage visibility gives security teams a place to enforce the sandboxing and monitoring that GhostApproval-style attacks require. A gateway won’t stop a spoofed terminal prompt on its own, but it makes it far easier to contain the blast radius when one gets through, and it gives incident response a single point to pull logs from instead of chasing down what happened on one engineer’s machine after the fact.

Sources

• AI Coding Tools Tricked Into Hacking Developer Machine via Decades-Old Technique
• AWS centralizes access, spending, and governance for Claude