SURIQ
A safety filter cannot block an instruction it cannot read. That is the whole trick behind the latest attack on xAI's Grok, and it is why a better content filter will not stop it. Researchers at Adversa AI showed that a booby-trapped web page can make Grok hand over a user's ongoing chat history, plus their name, rough location, and subscription tier, to a server they control, all after the victim does nothing more sinister than ask the chatbot to summarize the page.
This is the same failure we have written about three times this year under different names. The wrapper changes; the hole does not. What is new here is how cleanly the technique defeats the one defense most teams are counting on.
The filter never sees the instruction
Adversa AI researcher Rony Utevsky calls the method Cryptographic Context Injection. The attacker plants an encrypted blob on a web page along with the key material and a note telling the model to decrypt it. A content classifier scanning that page sees ciphertext and nothing else. There is no malicious sentence to catch, because the malicious sentence does not exist yet in readable form.
When a user asks Grok to summarize the page, Grok runs the decryption itself, using PBKDF2 and AES-256-GCM in its own code runtime. The plaintext instructions then arrive inside the model's context as the output of trusted code execution rather than as untrusted text pulled off the internet. Grok follows them: it assembles a string that folds in the user's session details, then calls its own browsing tool to load an attacker URL carrying that data in the query parameters. No confirmation, no visible warning, nothing the user can veto.
Adversa AI reported the issue to xAI on June 3, 2026 and followed up in August. As of the August 20 public disclosure there was no patch, no CVE, and no user-facing workaround. The demonstration ran on Grok 4.5 Fast at grok.com and succeeded in about 40% of 20 attempts; the failures came from Grok mangling its own decryption, not from any filter catching the payload.
It is not quite a drive-by
Reports have split on whether to call this zero-click, so be precise about it. The victim has to take one action: ask Grok to summarize the attacker's page. Everything after that request runs on its own. No second click, no consent gate, no warning banner before the session data leaves. So it is not a drive-by that fires from a page you merely open, but it is also not something the user meaningfully agrees to. A routine summarize request is all it takes.
Two chatbots leaked, two did not
Adversa AI ran the same class of payload past four assistants, and the split is the most useful part of the research for anyone building on top of these models.
| Chatbot | What it did with the encrypted page | Result |
|---|---|---|
| xAI Grok 4.5 Fast | Decrypted the payload in its Python runtime, then called its browsing tool | Leaked session data (~40% of attempts) |
| Google Gemini 3 Flash | Ran a variant hiding instructions in fake Python errors | Bypassed safety rules; success rate fell after June |
| OpenAI GPT-5 | Could not parse the decryption instructions | Resisted |
| Anthropic Claude Sonnet 4.5 | Decrypted, then flagged the text as a prompt injection | Resisted |
Two of the four leaked, two held. On Google's Gemini 3 Flash the researchers used a variant that hid instructions inside fake Python error messages and got the model to produce prohibited content, though that success rate dropped after June. OpenAI's GPT-5 simply could not parse the decryption steps. The one that matters most is Anthropic's Claude Sonnet 4.5: it decrypted the payload and then recognized the result as a prompt injection and refused.
That last case points at where the inspection has to live. GPT-5 got lucky by being bad at the crypto. Claude did the right thing on purpose: it treated the decrypted output as untrusted and screened it after the transform, not before. Any defense that only reads the page at ingest is blind to a payload that becomes malicious only after the model runs code on it. The checkpoint belongs after the decode step, at the moment the model is about to act, not at the door.
The encryption is a red herring
Strip away the cryptography and this is the same architecture bug that has been leaking data out of assistant products all year. We saw it when a single click could pull data out of Microsoft 365 Copilot, when Atlassian's Rovo assistant could be steered into leaking internal content, and when instructions hidden in a PNG hijacked AI coding agents. The constant across all of them is a three-part chain: the agent ingests untrusted content, it can resolve private context into a tool call, and there is no boundary or consent gate on what that tool reaches. Encryption is just the strongest way yet to smuggle step one past a filter.
The practical lesson is that adding a prompt-injection filter is not a fix for this class of bug. A classifier reads what it is shown, and strong encryption guarantees it is shown nothing useful. Chasing a smarter filter is chasing the wrong layer. The exposure is the outbound path, so the control has to sit on the outbound path.
Detect it on the way out
If you build or operate assistants that browse or summarize, the detectable moment is egress. The signal is an outbound request to a domain you never allowlisted, carrying session-shaped values in its query parameters, arriving right after the agent fetched an external page. That sequence in your proxy, DNS, or SIEM logs is worth an alert on any host running a browsing agent, and it is exactly the kind of anomalous outbound traffic a monitored log pipeline is meant to surface. You will not see the injection; you will see the exfiltration.
This connects to a broader point we made about guardrail bypasses in AI coding agents: the model is not the right place to enforce trust boundaries, and it never will be reliably. Treat every model as a component that can be talked into anything, and put the limits where you can actually enforce them.
Put the boundary around the agent, not in the model
Adversa AI's own conclusion is the right one: you do not fix this at the model layer. Bound the agent instead. Restrict which domains its tools are allowed to reach, so a call to an unknown host fails by default. Require confirmation for any cross-site tool action that carries user data. Log every outbound request the agent makes so you can replay what happened after the fact. And keep the identity the agent runs under as narrow as the job allows, so a hijacked summarize request cannot reach anything worth stealing. None of that depends on the model behaving. That is the point.