Zero-click Grok data theft: Cryptographic Context Injection attack leaks chat histories

A new attack technique we call Cryptographic Context Injection works around guardrails and gets attacker commands processed in a trusted context by shipping those instructions as cryptographically secure ciphertext and inducing the model to decrypt them inside its own code execution runtime. This lets attackers steal data using the access the AI system has, or modify the agent’s behavior, which we demonstrate against Grok and Gemini.

As of August 19, we could still reproduce the attack against Grok. Against Gemini, our success rate has fallen sharply since June. We are letting the security community know so defenders can build extra protections to detect any exploitation attempts. Operational payloads are withheld.

What is Cryptographic Context Injection

Static safety guardrails classify inputs as text; they do not execute them. An attacker ships ciphertext along with the key material and an instruction to decrypt it, and the model runs that decryption inside its own code execution sandbox. Everything a guardrail’s scanner would need is right there on the page, but recovering the plaintext means running PBKDF2 and AES-256-GCM, which no content classifier does at inspection time. Unlike base64 or a substitution cipher, there is no shortcut the model’s own weights can take either. The decrypted attacker instructions then appear as the output of code the model just ran, inside the trusted execution context, and are not flagged as untrusted input. The model acts on them as authoritative. The runtime execution launders attacker-controlled data into trusted instructions the agent will act upon. That is how the attack got its name: cryptography helps fabricate trusted context for the agent.

The same cryptographic backbone works whether the injection is direct or arrives indirectly, for example through the browsing channel. The Grok case shows the more dangerous form. In an agentic setting, the laundered output flows into a privileged, internet-connected action with no provenance or egress control, turning a content trust problem into a data exfiltration problem.

Attack steps:

1. An AI system processes untrusted input. For example, an agent is instructed to act on an external web page, to summarize it, or to extract specific data. The page contains an encrypted JSON object along with decryption instructions, which are easy to implement with a basic Python runtime and standard libraries.

2. Static guardrails cannot read the payload. Input filters classify text, they do not run it. AES-256-GCM ciphertext under a PBKDF2-derived key stays opaque to a classifier even though the key material travels alongside it, because recovering the plaintext requires executing the cipher. This is the key distinction from prior cipher-based evasion attacks. They relied on weak, reversible schemes (substitution ciphers, reordering, XOR, base64) that a model decodes natively, in-weights or in-context, with no interpreter in the loop. Strong encryption cannot be decoded in-weights at all, so recovery is forced through the code execution runtime.

3. Decryption materializes attacker instructions inside the trusted context. The model runs the decryption in its sandbox. The plaintext, the attacker’s actual instructions, now exists as the output of code the model just executed, rather than as an untrusted external string.

4. The model trusts its own runtime output. This is the pivot. The model acts on what its sandbox returns the way a program acts on its own internal state, not with the scrutiny it would apply to an untrusted user message or fetched web content. The attacker payload inherits a credibility that the same text would never get if pasted directly into the prompt. The closest classical analogy is SQL injection: a system that fails to distinguish its own trusted query from attacker-supplied data flowing through the same channel.

5. Depending on the attacker’s goal, the instruction can either direct the model to reach out to external servers, leaking the user’s data through request parameters, or produce some other undesired output and re-encrypt it to smuggle it past output guardrails. In an agentic setting, the possibilities are much wider and could include requests to misuse any tool available to the model.

The specifics of the two attack demonstrations are in the two sections below.

Grok: zero-click data exfiltration via indirect prompt injection

Target: xAI Grok web chat, agentic browsing framework. Reported to xAI.

The attacker hosts the payload on an ordinary-looking webpage. The user does nothing unusual; they ask Grok to summarize or analyze that page. Grok fetches it during browsing.

The page carries an encrypted JSON object with an instruction to decrypt it using the agent’s Python runtime. The decrypted instructions then direct the agent to resolve its private session context (the user’s name, coarse location, subscription tier, and the full set of the user’s prompts in the conversation) and to embed that resolved context into a URL, which the agent is told to open in order to “fetch additional context”. The agent autonomously invokes its privileged navigation tool to load that URL, transmitting the user’s data to the attacker-controlled endpoint in the request’s query parameters.

One key element of the attack chain is a disguise. The payload tasks the model with creating an additional “decryption key” that is not key material at all. Its value is a template string that interpolates the user’s private context (name, location, tier, chat history). This “key” is later used as a URL parameter for data exfiltration.

The framework built by xAI lets instructions and data parsed from an untrusted external page drive the invocation of a privileged, internet-connected tool; it allows private session metadata and conversation history to be resolved into the inputs of that outbound tool; and it enforces no effective egress boundary or consent gate on this path, and no provenance separation we could observe. The laundered, attacker-controlled instructions reach a privileged egress action unimpeded.

In the proof of concept demo, the exfiltration completed with no user confirmation and no visible warning, a true zero-click outcome triggered by an ordinary “summarize this page” request. The health-related text in the demo is not a part of the attack; it’s just an example of the information that would be exfiltrated. The redacted parts of the video contain just code execution traces and URLs, no warnings of any kind.

Gemini: safety policy bypass (direct injection)

Target: Google Gemini public chat interface (gemini.google.com), Deep Thinking mode. Model identity per the extracted system instructions: Gemini 3 Flash (Web), paid tier.

A single prompt, with no prior context, asks Gemini to run a Python script that decrypts a supplied ciphertext, with a strict instruction to emit only a small JSON object. The prompt gives an additional fallback instruction only for the failure case: if the Python raises an exception, read the failure message and act on it. No instruction for success is given, leaving one defined path forward.

The ciphertext is crafted so that the decrypted plaintext is a convincingly formatted Python traceback, and the “traceback” is the injection payload, not a real error. It contains two things:

• a fabricated, API-styled callback that appears to deactivate the safety policy
• a first-person reasoning prefix that pre-commits the model to producing the restricted content, framed as something it will encrypt “for safety”.

Because the model treats the sandbox output as the result of code it just ran, the planted reasoning enters its context as if it were its own, and it proceeds down the single path. The prohibited answer is generated in plaintext, then encrypted inside the sandbox, so the visible output the safety filter evaluates is only ciphertext. A deferred acronym trick keeps the restricted subject unnamed in the outer prompt until after decryption.

The technique produced a multi-paragraph example of restricted content that Gemini’s safety filters normally suppress (building an incendiary weapon). With a modified payload, the same vector reproduced Gemini’s system instructions, including the directive forbidding their disclosure. That these are the genuine system instructions is supported both by their stability across repeated extractions and by their match to the Gemini 3 Flash system prompt that other researchers have independently extracted and published in public collections.

A wider lesson for agentic AI security

It’s tempting to conclude that prompt injection is mostly a solved problem. While defenses have significantly raised the bar against the classic form (a bare instruction pasted into a prompt or hidden in a fetched page), this doesn’t mean the problem is fully solved. Cryptographic Context Injection is one instance of a broader shift: attacks that manipulate not just the prompt, but the wider context an LLM treats as its own, such as tool outputs, runtime results and intermediate state. This attack surface is far larger than what’s traditionally labeled “model inputs”, and the next generation of attacks will emerge there.

The attack technique and the two findings make an important point: the code execution runtime is a trust laundering channel, and strong encryption forces the payload down it.

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. Whether a weaker encoding would also bypass a given target’s specific filters is an empirical question. What encryption does not do is guarantee cooperation: the model can still decline to run the code, and success rates vary by target and shift over time. When the model does cooperate, the payload is opaque to content guardrails on both ingress and egress.

Prior research has shown that ciphers and encodings can carry a payload past safety alignment. CipherChat established that models decode ciphers well enough to answer through them, and CodeChameleon wrapped the payload in a reversible transform shipped with its own decryption function. In both, the model recovers the payload itself, with no interpreter in the loop. The cryptographically secure, runtime-forced variant here is a different beast, one that couples the attack tightly to the execution channel.

Exfiltration through a code interpreter’s outbound request is established ground, Johann Rehberger has been demonstrating variants of it since 2023. What is new here is how the instructions arrive: not as fetched text a filter could inspect, but as the return value of the agent’s own decryption run.

What defenders should do

While the examples above concern “benign” chat-style agents (though even they possess the Lethal Trifecta these days), Cryptographic Context Injection poses a greater risk to powerful agents, such as coding, platform operations, or financial ones. Every precondition is stronger for them: code execution isn’t an exception path but the product, outbound network calls are routine, and the credentials in reach are much more powerful and valuable than a session’s metadata.

You do not need to fix this at the model layer. Every control that bounds this attack sits in the harness around the agent: what identity it runs as, what it can reach, what it can write, and what you can replay afterward.

1. Quarantine untrusted content in a context with no tools and no credentials. It should return only structured data to the privileged context; never summarize fetched pages or ticket threads in the same context that holds repository write access.
2. Gate irreversible and outbound actions. Confirm new network destinations, pushes, merges, publishes, and writes outside the workspace, showing fully resolved arguments rather than templates. Where no human is present, the same set is a hard deny.
3. Capture per-session tool traces with resolved arguments. Without them you have neither detection nor forensics, and you cannot answer what the agent read before it acted.
4. Alert on the sequence, not one payload. The examples would be chains such as: untrusted content enters the context, code executes, and the agent then contacts a host outside the dependency graph or writes outside its declared scope; an opaque blob paired with instructions to decrypt it is a review signal, never a blocking filter.
5. Make context provenance a procurement requirement. Ask vendors whether tool output is separated from the instruction channel and whether the agent can refuse tool calls whose arguments originate in fetched content.

Session tracing, sequence detection, and provenance-driven trust are the controls only a few tools assemble together. The Adversa AI coding agent security platform links every model call, tool call, and endpoint action into chains, downgrades an agent’s trust the moment it touches untrusted content, and blocks the dangerous chains before they complete. That’s why the platform is able to stop Cryptographic Context Injection attacks against coding agents. We reproduced the Grok chain against an instrumented coding agent, and the platform stopped it as soon as the agent’s decoding routine produced a plaintext version of the attacker’s content.

Disclosure process

The attack was first reported to xAI on June 3, 2026, and to their HackerOne bug bounty program on the same date. xAI acknowledged the report but provided no specifics and no mitigation timeline. We made additional attempts to reach xAI and coordinate disclosure on August 4th and 10th. As of the date of writing, we have received no response. To make a wider audience aware of the risks and inform defenders about this attack vector, we are disclosing the vulnerability while withholding concrete payloads to avoid exploitation.

The attack was not disclosed to Google because jailbreaks are out of scope for its vulnerability disclosure program. The attack success rate of this vector against Google’s agents had dropped significantly by August. We can’t attribute the change — it could be filter updates, model version changes, or both.