Your guardrail can't read what your agent is about to run

Adversa AI found a way to make GitHub Copilot CLI steal a developer's secrets without ever showing it a suspicious instruction. The trick, which the researchers call Cryptographic Context Injection, is almost insulting in its simplicity: hand the agent ciphertext, hand it the decryption key, and politely ask it to decrypt. The agent treats decryption as a coding task, fires up its own code execution runtime, and only then does the instruction wake up. The researchers call these "zombie instructions." Dead text until the agent itself breathes life into them.

The chain works like this. An attacker page carries an encrypted blob, the key, and an instruction to decode it. Copilot CLI, running in autopilot mode, decrypts the blob inside its own shell. The plaintext instruction does not exist anywhere in the agent's context until the agent's runtime executes the decryption. By that point the filter has already run and will not run again. In the severe variant, the key material came from the victim's own environment: a local .env.prod file. The attacker did not ship a working key. The agent assembled secrets from the surroundings, then exfiltrated them through a plain outbound HTTP request. One demonstration read the .env.prod file and transmitted its contents to an attacker-controlled endpoint within 28 seconds. Nothing on screen said a file had left the machine.

The timeline is short and worth getting right. Adversa reported the technique to GitHub's bug bounty program on September 17, 2026. GitHub investigated and declined to classify it as a product vulnerability. As of October 1, the chain still reproduces. The operational payloads are withheld, but the technique is fully described, and this is not Adversa's first disclosure of it: a near-identical attack against Grok went public roughly two months earlier.

GitHub's full response deserves quoting: "After investigating, we determined this requires a user to intentionally direct Copilot CLI to fetch attacker-controlled or untrusted content and confirm they want to trigger the action, and thus is not a product vulnerability." Autopilot mode is opt-in, not default. A user has to point the tool at the untrusted page.

That argument is not nothing, and it should be answered honestly. Consent to "check the dependency notes" is not consent to "decrypt the blob and exfiltrate my tokens." Nobody's threat model for summarizing a README includes a cryptographic second stage. Autopilot exists precisely so developers can delegate the boring fetch-and-summarize work. If the vendor's position is that every such delegation is at the user's own risk, the feature's promise and its security story are describing two different products.

One more finding should worry anyone selecting models for agent work. The identical payload fooled Microsoft's own mai-code-1.1-flash half the time and was refused by OpenAI's GPT-5.6 every time. Resistance to this technique is currently a property of the model, not the architecture. Picking the model under your coding agent means picking its susceptibility to sealed payloads, whether or not anyone told you that.

So what actually stops it? Not the filter. A static guardrail is a function of the input string, and the malicious content exists in the input only as ciphertext. Adding more patterns or smarter classifiers is improving the reading; the attack lives in the gap between reading and running. The checkpoint that works is the tool boundary, where instructions become actions. Every instruction, no matter how it was encoded, must eventually become a tool call to do damage: an HTTP request, a file write, a secret read. At that moment it is fully visible. A deny-by-default egress gate does not need to understand the instruction's provenance. It asks one question: is this destination allowed?

If you run coding agents in autopilot, three things follow. First, treat fetched content as hostile input to a code runtime, not as text for a filter. Second, put the control at the tool boundary: egress allowlists, approval gates on file reads outside the project, and secrets the agent cannot see. Third, do not outsource the classification to the vendor. GitHub has told you, in writing, that this is not its vulnerability to fix. The fix is yours.

This is the second prompt-injection technique in a week to exploit the gap between what the filter reads and what the runtime executes (see our piece on the Manus JSFuck bypass). That one raced the filter. This one never shows up to the race. The pattern is converging on a single lesson, and it is the same one from the GitLab AI Gateway sandbox escape (see our coverage): the tool boundary is the only checkpoint that ever sees the action.