Grok built its own prompt injection: the filter never saw the payload

Researchers at the AI security firm Adversa got xAI's Grok to hand a user's session data to an attacker's server by publishing the attack on a webpage as AES-256-GCM ciphertext and letting the model decrypt it inside its own code execution environment ^[1][2]. The identical instructions, placed on the page in plain text, were refused ^[3]. That gap is the finding: input inspection cannot classify a payload that does not exist yet.

The mechanics are unglamorous. The demonstration page carried ciphertext, PBKDF2 parameters, AES-256-GCM key material, and instructions for decrypting it ^[4]. A user asked Grok to summarise the page, and Grok ran the decryption in its Python environment ^[5]. The recovered payload told the model to collect the user's name, approximate location, subscription tier and conversation prompts, and to pack them into a string dressed up as another decryption key ^[6]. Grok then appended that string to the query parameters of an attacker-controlled URL and fetched it with its navigation tool, depositing the data in the attacker's server logs without asking the user to approve the request ^[7].

Adversa calls the technique Cryptographic Context Injection and says it tested it against Grok 4.5 Fast on Wednesday ^[8]. The firm says it has run the attack 20 times since June with a 40 percent success rate ^[9], which works out to roughly eight successes ^[10]. That is not a reliable exploit. It is a reliable enough failure mode to matter for anything running unattended.

Adversa cannot say precisely why plaintext was blocked and ciphertext was not, because xAI does not disclose where Grok's filtering happens ^[11]. The firm's theory is that Grok inspects text entering and leaving the model but does not apply the same inspection to plaintext returned by its code interpreter ^[12]. If that is right, the instructions start as attacker-controlled web content and re-enter the model as runtime output: the representation changes, the information does not ^[13]. Adversa's lead researcher, Rony Utevsky, frames this as a structural limit of static guardrails, which classify text rather than execute it ^[14]. A filter can read the ciphertext, the algorithm and the key, but working out what they produce requires doing the computation, and by the time the model does that, inspection has already happened ^[15].

The same shape appeared elsewhere. Adversa says it produced a Gemini variant by formatting decrypted content to look like a Python traceback and telling Gemini to act on the error message, which yielded output its safety controls would normally block, and with a modified payload, its internal system instructions ^[16]. The researchers did not report it to Google because jailbreaks sit outside the scope of Google's disclosure programme, and they say Gemini has since become more resistant without knowing why ^[17].

The practical conclusion is that the enforcement point has to sit downstream of the interpreter. Adversa treats this case as one instance of a broader problem in which attackers target what an agent picks up while working: tool outputs, runtime results, intermediate data ^[18]. GoDaddy hit a version of the same question when it opened its registrar to agents and had to constrain what those agents could actually do with domain management tools ^[19].

Watch whether vendors start treating interpreter output as untrusted input, and whether egress from agent sandboxes gets an allowlist. A model that can compute is a model that can manufacture its own payload; the only durable control is what the sandbox is permitted to reach.