Your Guardrails Read Plaintext. Encrypted Attacks Bypass All of Them.

A security researcher at Adversa encrypted a malicious instruction, pasted it into a web page next to a plaintext decryption key, and watched Grok steal user chats and personal information. The guardrails never fired. They could not. Guardrails scan for suspicious plaintext. The attack was not plaintext.

xAI was informed of the vulnerability in June. As of this writing, Grok was still exfiltrating data. The fix is not a patch. The fix is admitting that content inspection is the wrong layer for containment. (Cross-reference Note #148: the worm exploit did not use a bug either. It used a feature. Same structural blindness, a different vector.)

The thesis: if your containment strategy depends on the model reading an instruction and deciding it is bad, you do not have containment. You have a polite request. The attack class is called Cryptographic Context Injection, and it exposes a principle every agent builder needs to internalize before the next deployment.

The Signature Blindness Principle

Guardrails that inspect content work by pattern matching. They scan for suspicious phrases, known injection templates, harmful instructions. This is signature-based detection, the same architecture antivirus software used in 1995, and it carries the same structural flaw. It can only catch what it has a signature for.

Cryptographic Context Injection defeats this by denying the guardrail readable text. The malicious instruction is encrypted. The guardrail sees ciphertext, finds no suspicious patterns, and lets it through. The model receives the ciphertext and a plaintext decryption instruction. The model decrypts. The model follows. The guardrail watched the entire exchange and saw nothing.

Take the specific mechanics from the Adversa report. The website hosting the ciphertext also carries the plaintext instructions for decrypting it, which the model follows. The guardrail inspects that decryption instruction. It looks harmless. It is just "decrypt this base64 string." The actual payload lives in the ciphertext, invisible to any content scanner.

This is not a Grok-specific bug. Microsoft Copilot carried a hidden input that bypassed its safeguards, a backdoor no content inspection would have flagged. The Guidelight study found few frontier labs have published concrete containment plans. The pattern is structural. If containment lives in the content layer, any encoding the guardrail cannot parse is a hole.

Name the principle: the Signature Blindness Principle. Any guardrail that inspects content is blind to any encoding it cannot parse. Base64. ROT13. AES. Unicode homoglyphs. The set of encodings is infinite. The set of guardrail signatures is finite. The math does not work in your favor.

Why Your Runtime Is the Real Perimeter

Content inspection fails because it asks the model to police itself. The model is the thing under attack. You are asking the burglar to check his own pockets before he leaves.

Runtime boundary enforcement is different. It does not ask the model what it is doing. It restricts what the model can do. Network egress controls. Filesystem permissions. Tool-call allowlists. Sandboxed execution. The model can be fully compromised and still cannot exfiltrate data if the runtime will not let it reach the network.

This is the thesis from Note #146: containment is architecture, not prompts. Cryptographic Context Injection proves it from a new angle. Prompts are content. Guardrails that inspect prompts are content inspection. Architecture is the runtime boundary.

False alarms are the other half of the content-inspection problem. Legitimate agent workflows routinely move base64 blobs and encrypted payloads. A guardrail that inspects content cannot tell a routine encrypted exchange from an attack, so developers must either whitelist those patterns, which reopens the hole, or trip over false positives on every ordinary task. Runtime limits sidestep the question entirely. The boundary does not care what the payload is. It only enforces what the runtime may do, which is why runtime enforcement is the only layer of defense that never trades false alarms for blind spots.

An OpenAI leader is warning that the industry is entering a new phase of persistent, autonomous AI cyber-attacks. The framing matters. It is a permanent threat, not a series of incidents. One-time patches do not work against persistent threats. Runtime boundaries persist. Content patches expire.

The Containment Gap Is a Published Gap

The Guidelight AI Standards study graded five leading labs on containment preparedness. Few have published or demonstrated concrete response plans. OpenAI scored highest. Anthropic and Meta scored lowest. The assessment covered monitoring, halting, third-party auditing, and containment specifics.

The implication for operators is direct: you cannot assume your model provider has a containment plan. If two of the largest labs have not published concrete containment, then your containment is your problem. Not theirs.

Coders found workarounds to Claude's invisible watermarks within hours of the announcement. The same cat-and-mouse applies to content-based guardrails. You patch a signature, the attacker rotates the encoding. The watermark episode proves the pattern: defensive content markers fall within hours. Guardrails built on inspection fall the same way.

The Three-Layer Runtime Defense

Build a three-layer defense that does not depend on content inspection.

Layer 1: Egress control. The model's runtime has no direct network access. Every outbound call goes through a proxy that enforces an allowlist. If the model decrypts a malicious instruction and tries to POST user data to an external server, the proxy blocks it. The runtime denies by default. The model never gets to ask permission.

Layer 2: Tool-call allowlisting. Every tool the agent can invoke is explicitly registered. No dynamic tool discovery. No "run arbitrary code" tools. If the decrypted instruction tells the model to call a tool that is not on the allowlist, the call fails. The model can be fully compromised and still cannot reach a tool it was never granted.

Layer 3: Session isolation. Each agent session runs in its own sandbox, with its own credentials and its own network namespace. A compromised session cannot reach data from other sessions. The blast radius of any single compromise is one session.

The principle across all three layers: never ask the model to police itself. Make the runtime enforce what the model cannot.

What to Do Today

1. Audit your current guardrail architecture. Ask one question: does any part of your containment depend on the model reading content and deciding it is bad? If yes, mark that layer. It is vulnerable to encoding bypass.
2. Map every network egress path from your agent runtime. List every outbound destination. If you cannot produce that list from memory, your egress is uncontrolled. Fix that first.
3. Implement tool-call allowlisting if you have not. Every tool must be explicitly registered. No exceptions for convenience.
4. Check whether your model provider has published a containment response plan. If they have not, assume they will not catch the next attack class for you. Plan accordingly.
5. Read the Adversa disclosure on Cryptographic Context Injection. Then try it against your own agent in a test environment. If your guardrails catch it, you are in the minority. If they do not, you now know before an attacker does.

The Uncomfortable Question

Your guardrails read plaintext. The attacker sent ciphertext. How long do you want to pretend those are the same problem?

If your containment depends on the model reading the instruction and deciding it is bad, you do not have containment. You have a polite request. The runtime is the real perimeter. Make it hold the line.