Security researchers at Adversa AI say they found a way to make Grok leak private session data by hiding malicious instructions where normal safety filters could not read them.

The trick was not a magic phrase pasted into chat. It was a poisoned web page.

According to Adversa, an attacker could place encrypted instructions on an otherwise ordinary page, then wait for a user to ask Grok to summarize or analyze that page. Grok would fetch the page, run the decryption inside its own code execution environment, treat the decrypted output as trusted context, and then open an attacker-controlled URL that carried user data in the request.

Adversa calls the technique Cryptographic Context Injection. The phrase is clunky, but the risk is simple: guardrails may inspect the text that enters an AI system, while the dangerous instruction only becomes readable later, after the model has used its own tools to decrypt it.

That matters because Grok is not just answering from a static prompt. In this scenario it has browsing, code execution, and a privileged navigation tool. Once the hidden instruction lands inside that tool-using workflow, the issue is no longer only a prompt problem. It becomes an egress-control problem.

How the researchers tricked Grok

The attack chain has five parts.

First, the attacker publishes a normal-looking web page. Buried inside the page is an encrypted JSON object, along with enough information for a model with a code runtime to decrypt it.

Second, the user asks Grok to do something ordinary with the page, such as summarizing it. The user does not need to click a malicious button or paste a suspicious prompt. The prompt can look harmless because the harmful instruction is hidden in ciphertext.

Third, Grok processes the page and runs the decryption in its Python-style code execution sandbox. Adversa says the payload used strong encryption, including AES-256-GCM with PBKDF2-derived key material, so a static content scanner would not see the underlying instruction unless it actually executed the decryption path.

Fourth, the decrypted instruction appears to Grok as the result of code it just ran. That is the key trust failure. The instruction is no longer presented as an untrusted sentence on a random web page. It has been laundered through the model's own runtime and arrives as internal-looking output.

Fifth, the hidden instruction tells Grok to assemble private context and load a URL. Adversa says the proof of concept caused Grok to include the user's name, approximate location, subscription tier, and prompts from the ongoing conversation in request parameters sent to an attacker-controlled endpoint.

In short: the attacker did not convince the front door to allow a malicious prompt. They convinced Grok to unlock the prompt itself after it had already entered the building.

Why encryption beat the filter

Most prompt-injection defenses start by inspecting readable content. They look for commands like "ignore previous instructions," "send this data elsewhere," or "call this tool with this argument."

Encryption breaks that assumption.

If the instruction is encrypted, the guardrail sees opaque text. It may also see the decryption recipe, but a normal classifier is not going to run PBKDF2, decrypt AES-GCM ciphertext, inspect the plaintext, and then reason about whether the resulting instruction should be quarantined.

The model, however, can be asked to run code. Once it does, the decrypted text can be reintroduced into the active context as a tool result. That creates a dangerous boundary collapse: content from the open web becomes operational instruction inside an agent workflow.

This is why the Grok demo is more interesting than a normal jailbreak. A plain-text malicious prompt is easier to scan, label, and refuse. An encrypted prompt forces the system to decide whether outputs from its own tools are always trusted.

They should not be.

What actually leaked

The strongest public claim is narrower than some headlines suggest.

The Hacker News reported that Adversa tested Grok web chat running Grok 4.5 Fast, reproduced the attack once on August 19, 2026, and said the successful run exposed data from the current session context. That included the user's name, approximate location, subscription tier, and prompts from the ongoing conversation.

Adversa did not claim it accessed every historical Grok chat or a backend database of all users. It also said it was withholding operational payloads to reduce abuse risk.

That distinction matters. This appears to be a session-context exfiltration path in a tool-using chat agent, not a database breach.

But that is still serious. People paste sensitive work, personal questions, documents, code, and business context into AI chats precisely because the interface feels private. If a summarization request can be turned into an outbound data leak, the risk is not theoretical for anyone using AI agents around confidential material.

Disclosure status

Adversa says it reported the issue to xAI and to xAI's HackerOne program on June 3, 2026. The researchers say xAI acknowledged the report, but did not provide a mitigation timeline. They also say they tried to coordinate again on August 4 and August 10.

As of Adversa's August 20 post, the researchers said they could still reproduce the Grok attack on August 19.

The Hacker News added two useful details: it reported that Adversa had attempted the attack 20 times since June with a 40% success rate, and that failures were caused by Grok struggling with the decryption rather than by safety systems flagging the payload.

That makes the bug feel less like a stable one-click exploit and more like a repeatable agent-harness weakness. For defenders, that is not comforting. A flaky attack against a popular chat agent can still become practical when attackers can tune payloads, target high-value users, or retry through social engineering.

The Gemini part of the research

Adversa also demonstrated a related technique against Google's Gemini, but the Grok case is the more direct privacy story.

In the Gemini example, the encrypted payload was used to push the model toward output that safety policies would normally block. Adversa said the success rate against Gemini had fallen sharply by August, though it could not say whether that was because of model changes, filters, or both.

The shared lesson is not "Grok only." The broader issue is that modern AI systems increasingly combine language models with browsing, code execution, memory, connectors, and outbound tools. Any one of those tools can become a trust boundary. If an agent treats decrypted text, tool output, or fetched web content as equivalent to internal instruction, prompt injection gets a larger attack surface.

What builders should learn

The useful fix is not to ask the model to "be more careful" around encrypted text.

The fix is to separate trust domains.

An AI agent should not summarize an untrusted web page in the same privileged context that can access private session metadata and make outbound network calls. Fetched content should be treated as data, not instruction. Decrypted content should inherit the distrust of the source it came from, not the trust of the runtime that decoded it.

Builders should also gate outbound actions. If an agent is about to open a new domain with user data embedded in a URL, that should be blocked, confirmed, or at least logged with resolved arguments. A URL assembled from tool output is not automatically safe because the model produced it.

The same applies to coding agents, enterprise copilots, CRM agents, browser agents, and finance agents. The more tools an AI system has, the less meaningful a prompt-only defense becomes.

Our take

The important part of this story is not that Grok was fooled by clever encryption. It is that an agentic chat product appears to have let untrusted web content move through code execution and into a privileged browsing action without a hard boundary in between.

That is the pattern to watch.

AI security is moving from "can the model refuse a bad sentence?" to "can the system control what the model is allowed to do after it reads something hostile?"

For users, the practical advice is boring but real: do not ask an AI agent to summarize random pages while sensitive context is open in the same chat. Start a fresh session for untrusted links, avoid pasting secrets into general chat tools, and treat agent browsing as a live security boundary.

For builders, the advice is sharper: if your agent can browse, run code, hold private context, and make outbound requests, you are no longer building a chatbot. You are operating a small automation platform. It needs provenance, egress controls, scoped credentials, audit logs, and human approval around suspicious tool calls.

The model can still be impressive. The harness has to be paranoid.