Grok's Zero-Click Chat Leak: When Encrypted Text Becomes a Trusted Instruction

Encryption is meant to keep malicious actors out. Adversa AI demonstrated how encryption can instead be a gateway for malicious instructions to enter Grok and Gemini, bypassing all text-based safeguards with no user input required. The researchers created a webpage holding an AES-encrypted data block. The page itself was unremarkable if scanned for prompt injection using regular expressions or keywords; the malicious commands were encrypted.

There was no "ignore prior instructions" flag to detect or any suspicious plain text. The loophole: Grok and Gemini both have code execution abilities. When the model processes the page and runs its decryption routine in a sandbox, it decrypts the blob internally. The resulting plaintext isn't flagged as content fetched from an untrusted webpage.

Instead, it's treated as the model's own generated output within the model's own trusted context. That plaintext contained instructions to establish an outbound URL request, extracting the user's chat history, name, and location to a server controlled by the attacker. Zero clicks. The user never gave approval because, from the model's perspective, no external input entered the conversation — it decrypted internally and executed the resulting commands.

This is a trust boundary vulnerability masquerading as a cryptographic trick. Here's how it unfolds technically: Delivery: The attacker deploys a webpage within normal browsing or research activity where the model encounters it, without triggering content filters due to the ciphertext. Execution: The model has code execution capabilities, running the decryption process within its sandbox using a key or method embedded in the ciphertext.

Re-classification: The critical flaw occurs here. Once the model decodes the encrypted content, that output gets merged back into the trusted context, losing any provenance of its origin. Action: The now-trusted plaintext contains instructions, which the model executes without questioning its source, such as initiating a URL request with exfiltrated data.

This attack's stealth comes from how each step appears innocuous in isolation: decrypting data isn't suspicious, and innocuous URL calls aren't inherently dangerous. The real threat lies in the chain reaction and the loss of provenance across the code-execution boundary. Existing defenses typically rely on pattern matching on input text before reaching the model or on the final output after model processing.

Neither system detected this attack: input filters saw only ciphertext, lacking patterns to flag; output filters examined the final user-facing response, not the internal tool calls or URL arguments. The decrypted plaintext re-entered the trust boundary without scrutiny, and outbound tool calls were not scrutinized for exfiltration risks, regardless of their origin.

Sentinel's defenses could have caught this at two key points: the tool result stream and the outbound tool call itself. By scanning the decrypted plaintext as part of the tool result stream, Sentinel could have applied regex to identify malicious authorship directives (like sending data to a specific URL) and employed vector similarity checks against known exfiltration patterns.

De-obfuscation and data exfiltration detection layers would independently flag any outbound URL request carrying sensitive user data, regardless of how the instructions were initially delivered.