Content classifiers guarding AI chat assistants work by reading the text in front of them and deciding whether it looks like an attack. Cryptographic Context Injection, disclosed by researcher Rony Utevsky of Adversa AI, sidesteps that entirely by giving the classifier nothing to read. The Hacker News' technical writeup and SecurityWeek's coverage both walk through the same mechanism: an encrypted JSON blob sits on a web page alongside key material, and instructions tell the model to decrypt it - using PBKDF2 and AES-256-GCM - inside its own Python runtime before acting on what's inside. Utevsky's framing of why this works is the whole story in one line: "Strong encryption cannot be read by a content classifier and cannot be shortcut in-weights, so it forces recovery through the runtime the attack depends on."
A decryption key that's actually an exfiltration template
Once the model decrypts the payload, the hidden instructions ask it to resolve session data - the user's name, approximate location, subscription tier, and whatever's currently in the conversation - and assemble that data into a string it's told is a "decryption key." It isn't; it's a query parameter. The model then reaches for its own navigation or browsing tool to visit a URL built from that string, and the attacker's server logs the request. Nothing about that final step looks unusual from the outside - it's the assistant doing exactly what a legitimate browsing tool call looks like, with the stolen data riding along in plain sight inside the URL.
Grok said yes 40% of the time. Claude noticed the trick anyway
Adversa tested the technique against Grok 4.5 Fast on grok.com and reported a 40% success rate across 20 attempts run since June, with failures traced to the model struggling with the decryption steps rather than any filter catching the attempt. Google's Gemini 3 Flash, in Deep Thinking mode, was also confirmed vulnerable, though its success rate had dropped noticeably by August. The pattern breaks down elsewhere: OpenAI's GPT-5 reportedly failed to parse the decryption instructions at all, and Anthropic's Claude Sonnet 4.5 decrypted the payload but then flagged it as a prompt injection attempt rather than acting on it - a useful reminder that "the model can technically run the decryption code" and "the model will then do what the decrypted text says" are two separate properties, and only the second one is the actual security boundary.
A ten-week gap between report and public disclosure
Utevsky first published preliminary research on his personal site back in March 2026, then filed a formal report with xAI and HackerOne on 3 June. Follow-up attempts to reach xAI on 4 and 10 August went, by the researcher's account, without a substantive response, and the attack still reproduced when tested again on 19 August. The public writeup went out the next day with no CVE identifier assigned, no advisory from xAI, and - as of publication - no exploitation reported in the wild. That last point is worth holding onto: this is a disclosure about a real, reproducible weakness, not evidence anyone has used it against a real user yet. It's also exactly the window - known technique, no patch, no active abuse confirmed - where the sensible response is to assume it's usable rather than wait for proof it's being used.
The part that doesn't stay contained to one chatbot
The specific trick here - encrypt the instruction so nothing can read it before the model's own runtime decrypts it - is portable to any AI system that pairs code execution with tool access, which describes an increasing share of the agent deployments enterprises are now shipping internally. A content filter that only ever sees plaintext was never going to be a complete defence once models started running arbitrary decryption logic on request, and that's the same underlying gap our piece on AI agent guardrails argues needs addressing at the tool-permission layer, not just the prompt-filtering layer: what an agent's browsing or fetch tool is allowed to reach matters more than whether its classifier caught the request that triggered it.
- Inventory which AI assistants your staff use - officially or informally - that combine code execution with live web browsing or fetch tools, personal accounts included.
- Don't treat "the model refused" or "the filter caught it" as proof of safety on its own; test guardrails specifically against obfuscated or encrypted payloads, not just plaintext prompt injection.
- For any AI tool with a navigation or fetch capability, restrict or monitor outbound calls so session data can't leave via query parameters to attacker-controlled domains.
- Ask AI vendors directly whether their safety classifiers run before or after code-execution and decryption steps - the answer determines whether this class of bypass applies to them.
- Until xAI ships a fix, treat Grok's (and any similarly-architected assistant's) agentic browsing features as capable of leaking session context, and scope what "context" means for any regulated data those assistants can see.
Ten weeks from private report to public disclosure with still no patch is a long runway for a technique that's already reproducible. If you'd like a review of what your organisation's AI tools can actually reach and leak, email sales@halfteck.com.