Encrypting a message is supposed to make it harder to read. Against Grok, it made a malicious payload easier to deliver — because the one thing standing between the model and the attacker’s instructions was a filter that couldn’t decrypt anything at all.
Researchers at Adversa AI disclosed on August 20 a technique they call Cryptographic Context Injection (CCI): instructions AES-256-GCM encrypted and dropped on a webpage next to their own decryption key. Grok’s input filter scans incoming content for malicious intent, but ciphertext just looks like noise — there’s nothing to flag. The model then reads the page, decrypts the payload using the key sitting right next to it, and executes the hidden instructions inside its own trusted runtime, no filter in the loop at any point after decryption.
How the Bypass Actually Works#
The mechanics are almost embarrassingly simple once you see them laid out. A webpage carries two things: a block of AES-256-GCM ciphertext, and the key needed to decrypt it. Grok’s safety layer inspects the page’s text before the model acts on it — but encrypted text carries no semantic signal a filter can key off of. It isn’t obfuscated in a way pattern-matching can catch; it’s genuinely opaque until decrypted.
Once Grok reads the page as part of a normal task, it treats the decryption key as just more content to reason about, decrypts the ciphertext, and — because the decrypted text now reads as an instruction — follows it. The proof-of-concept demonstrated extraction of a user’s chat history, prompts, full name, coarse location, and subscription tier, all packaged into URL parameters and sent to an attacker-controlled server. No file needs to be opened, no button clicked. The page just needs to be in context when the model is reasoning.
Adversa’s researchers frame the root cause as a distinction models handle inconsistently: weak, conventional ciphers (ROT13, base64, simple substitution) get decoded natively by an LLM as part of its general reasoning, and a safety filter has at least a chance of recognizing the decoded output as suspicious before the model acts on it. Strong encryption is different — it requires the model to actually execute a cryptographic operation at runtime, which happens after the filter has already cleared the input. That gap is what Adversa calls a “trust laundering” problem: the ciphertext launders malicious intent through a computation the safety layer never gets to inspect.
xAI’s Response Timeline Is the Part That Should Worry You#
Adversa reported the vulnerability to xAI in June. They followed up again on August 10. As of August 19, the technique was still reproducible on Grok.com. That’s roughly two months between initial disclosure and a public writeup with no fix shipped — a gap that matters more than the technique itself, because CCI isn’t exotic to reproduce. It’s a webpage with two text blocks on it.
Adversa also confirmed the underlying encryption-bypass concept applies to Google Gemini, though Gemini’s architecture happened to block the specific exfiltration path used against Grok — worth noting as a difference in outcome, not a difference in root cause. The filter-blind-to-ciphertext problem isn’t unique to one vendor’s implementation; it’s a property of bolting a text-pattern safety filter onto a model that’s also a general-purpose interpreter capable of running whatever computation the input asks it to run.
The Same Root Cause, a Different Delivery Mechanism#
This isn’t the first time this year an AI system’s safety boundary has turned out to be a boundary that only holds for the kind of input its designers anticipated. Zenity’s Black Hat demonstrations against five agentic browsers showed the same underlying failure — an assistant that can’t distinguish the task it was given from instructions hidden in content it’s reading — playing out through calendar invites and crafted emails instead of encrypted webpages. CCI is a more surgical version of the same problem: instead of hiding instructions in plain text and hoping the filter misses them, it hides them behind math the filter fundamentally cannot see through, by design, because that’s what encryption does.
It also lands in an environment where defenders are racing to build AI systems that find these gaps before attackers do, the same instinct behind Anthropic’s open-source vulnerability discovery framework. CCI is a reminder that the attack surface isn’t just source code — it’s the reasoning loop of the model itself, and that loop has a computational capability (running decryption) that a text-based safety filter was never designed to see through.
What This Means If You’re Building on These Models#
If your product wraps an LLM with any kind of browsing, tool-calling, or “read this content and act on it” capability, treat every piece of external content the model ingests as executable, not just readable — because a model that can decrypt is a model that can be told to do so by content it hasn’t yet evaluated for trust. A few concrete responses:
- Don’t rely on pre-execution content filtering as your only safety layer. If the filter runs before any transformation the model itself might perform (decryption, decoding, format conversion), assume attackers will hide payloads inside that transformation step.
- Constrain what the model can do with information it decrypts or decodes mid-task, the same way you’d sandbox output from any other untrusted computation, rather than treating “the model produced this text” as inherently safe just because the original input passed a scan.
- Assume disclosure timelines will be slow. Two months from report to public reproduction is not an outlier in this space — plan your own exposure around vendor patch timelines you can’t control, not ones you hope for.
My Take#
CCI isn’t clever because encryption is exotic — it’s clever because it exploits a mismatch every vendor bolting a safety filter onto an LLM currently has: the filter inspects static content, but the model is a general-purpose interpreter that will run whatever computation the content asks it to run, including one that makes the malicious part invisible until it’s too late to intervene. That’s a structural gap, not an implementation bug in Grok specifically, which is exactly why Gemini shares the underlying weakness even though its exfiltration path happened to be blocked. Until safety architectures move from “scan the input” to “constrain what the model is allowed to do after any transformation, regardless of how that transformation happened,” this exact category of bypass will keep resurfacing under new names. The fix isn’t a smarter filter. It’s admitting the filter runs at the wrong layer.
