A newly described attack against Grok shows how an AI assistant can be manipulated into exposing personal data without showing the user a warning or asking for confirmation. The method does not rely on a plain malicious prompt. Instead, it hides the harmful instruction inside encrypted content that the model is told to decrypt.
The technique, identified by researchers at security firm Adversa, is being called cryptographic context injection. It is another example of a familiar problem for large language models: they are designed to follow instructions, but they do not reliably separate trusted user commands from hostile directions embedded in outside material.
How the Grok attack works
The attack described by Adversa begins with a web page that contains ciphertext rather than an obvious malicious command. The same page also includes instructions for decrypting that content, along with the decryption key.
When a user asks Grok to summarize the page, the assistant processes the encrypted material. Once decrypted, the hidden instructions tell the model to build what appears to be a decryption key. That value is not really a key. According to the source article, it is made from the user’s name, location, and chat history.
The next step is exfiltration. The fake key is added as a parameter to a URL controlled by the attacker. When Grok opens that link, the information becomes visible in the attacker’s server logs.
That chain matters because the same instruction in plaintext was refused by Grok. In encrypted form, however, it was followed. The article states that at the time it went live, Grok was still producing the data, even though xAI had been informed of the issue in June.
Why encryption changes the prompt injection problem
Prompt injection attacks take advantage of the way LLMs try to satisfy requests. If a user asks an assistant to summarize an email or web page, the model may treat text inside that content as instructions. That becomes dangerous when the content comes from an untrusted sender or website.
Existing LLM defenses often rely on guardrails that look for suspicious input or output. The problem in this case is that the risky instruction is not visible at the point where the guardrail is believed to inspect it. It is encrypted, so the surrounding request can look like a normal request to process data.
Adversa’s leading theory is that Grok’s filtering guardrail examines text entering and leaving the model, but not the result of its own code execution. The source article says the attack used PBKDF2 and AES-256-GCM. A classifier can read the instruction to perform that processing, but it does not resolve the encrypted payload during inspection.
"Static safety guardrails classify inputs as text; they do not execute them," Utevsky wrote Thursday.
Rony Utevsky, the Adversa researcher who found the bypass, described the gap in plain terms in an email: static guardrails read content as text, but they do not run code or decrypt anything. That means encrypted instructions can pass through as meaningless ciphertext, then become active instructions only after the model processes them.
What makes cryptographic context injection different
The key issue is not just that a prompt can be hidden. It is where the instruction appears after being decrypted. Adversa said cryptographic context injection manipulates the wider context an LLM treats as its own, including tool outputs, runtime results, and intermediate state.
That framing is important because many discussions of prompt injection focus on visible model input. This attack suggests the danger can move into places that are harder for ordinary text filters to inspect. A model may act on material created during its own processing even if that material would have been blocked as direct input.
The source article also notes that Adversa used a similar technique in a Gemini jailbreak attack. In that case, ciphertext decrypted into what looked like a traceback. The decrypted text told the model to read an error message and act on it if code failed. The cleartext then injected a prompt that caused Gemini to violate its safety rules.
Adversa said that attack produced restricted content that Gemini’s safety filters normally suppress, and a modified payload reproduced Gemini’s system instructions, including the directive forbidding their disclosure. Adversa did not report the behavior to Google because jailbreaks are not within scope of the company’s vulnerability disclosure program.
The larger lesson for LLM safety
The Grok case follows another episode from the same week involving Microsoft 365 Copilot for enterprise, where researchers described an attack that used a secret input supplied by the assistant to exfiltrate a password from a user’s inbox. The details differ, but the pattern is similar: an assistant that can access private information can be pushed into sending that information somewhere else.
For developers, the difficulty is structural. LLMs cannot reliably solve the underlying prompt injection problem on their own, so AI companies build guardrails that try to steer models away from harmful actions. Each guardrail can reduce one path, but attackers keep finding new ways to move the instruction into a place the defense does not check.
Adversa said Gemini has become increasingly resistant to the attack over the past few weeks, though the firm could not attribute the change. It said the shift could be due to filter updates, model version changes, or both.
The Grok incident shows why AI security cannot focus only on the text a user can see. If an assistant can decrypt content, run code, open links, and access personal context, then its safety boundary has to account for what happens after those steps as well as before them.