Security researchers warn that a class of attacks against AI web agents is evolving. In a newly disclosed technique, an adversary can hide instructions inside encrypted content on a normal-looking page, then rely on the model’s own code-execution pathway to decrypt and act on those instructions. The result can be unauthorized access to sensitive session data.
The attack method is called cryptographic context injection. According to the disclosure, it was demonstrated against xAI’s Grok web chat and also includes a separate demonstration targeting Google’s Gemini in Deep Thinking mode. As of the time of reporting, the researchers describe no public patch, no CVE identifier, and no user-facing workaround.
What cryptographic context injection does
The core idea is straightforward: instead of placing readable prompt-injection text directly into a web page, the attacker ships ciphertext and related decryption material. The page includes an encrypted JSON object plus key material and explicit instructions to decrypt it. The agent then processes those decrypted instructions inside its own Python runtime.
In the reported Grok scenario, the encryption step involves PBKDF2 and AES-256-GCM. The disclosure argues that content classifiers cannot reliably interpret such encrypted payloads during inspection time. As a result, the decrypted output arrives in the model’s context as the output of recently executed code rather than as fetched web page content.
That distinction matters. The researchers describe a path where strong encryption prevents the usual text-based filtering from seeing the real instructions early enough to stop them.
How Grok could leak conversation and profile details
The disclosure claims that a user asking the assistant to summarize an ordinary web page could trigger the agent to send sensitive information to an attacker-controlled server. The extracted fields reportedly include the user’s `name`, approximate location, subscription tier, and the prompts from the ongoing conversation.
In the proof-of-concept demonstration, the transfer is described as completing without a confirmation step and with no visible warning to the user.
The attacker chain is reported to work roughly like this:
- The encrypted page payload is decrypted within the agent’s Python execution environment.
- The decrypted instructions then instruct the agent to resolve its private session context.
- The agent is directed to open a URL, “fetch additional context,” while embedding the sensitive data into the URL’s query parameters.
The researchers also note that one part of the chain involves the model constructing an additional “decryption key” that is not traditional key material, but rather a template string. That template interpolates personal details (like name, location, and tier) and chat history, making the eventual exfiltration request context-aware.
Where the researchers say the boundary breaks
In their explanation, the researchers emphasize that the framework behind the agent allows instructions and data parsed from an untrusted external page to drive calls to privileged, internet-connected tools. They describe the lack of an effective egress boundary or consent gate for this path, along with no observable provenance separation separating untrusted instruction data from tool-invocation inputs.
They also clarify that in the tested scenario, the prompts targeted were limited to the ongoing conversation and that the extracted information was already present in the model’s context. The broader scope—such as whether other chats, agent memory, or different content could be accessed—was not fully tested in the disclosure.
Testing details and reporting timeline
The report states that the technique was reproduced once on August 19, 2026. It also describes an internal attempt count: since June, the researchers claim they attempted the attack 20 times, reaching about a 40% success rate.
The disclosure says failures were attributed to the target having difficulty decrypting rather than due to a flagged prompt or response. The write-up does not provide a success rate breakdown tied to particular browsing pages or user requests, and the operational payloads are withheld to avoid enabling real-world exploitation.
From a coordination standpoint, the researchers say they first reported the issue to xAI on June 3, 2026, and also submitted it to xAI’s HackerOne bug bounty program the same day. They add that xAI acknowledged the report without providing specifics or a mitigation timeline. Follow-up attempts on August 4 and August 10 did not receive a response.
Why encryption helps the attacker
A major theme in the disclosure is that strong encryption can “hide” instruction content from filters and review systems. The researchers argue that even if a system can detect certain categories of prompt injection, an opaque encrypted blob paired with instructions to decrypt it can shift the attack from the inspection stage to the execution stage.
In other words, the attack depends on the agent’s ability to run code and to treat decrypted output as legitimate context. The researchers also suggest that alternative encodings might or might not bypass a given target’s specific filters, but they frame the encryption approach as a reliable way to force recovery through the runtime the attack needs.
Gemini demonstration: encrypted payloads and safety bypass claims
The same disclosure also includes a second demonstration involving Google Gemini in Deep Thinking mode. The write-up describes a prompt that triggers decryption of a payload that results in a fabricated Python traceback containing a bogus safety-policy deactivation callback and a first-person reasoning prefix intended to pre-commit the model to restricted output.
The researchers state that this chain produced restricted content and reproduced Gemini’s system instructions. They identify the affected configuration as Gemini 3 Flash (Web) on a paid tier.
The disclosure claims Google was not notified because jailbreak-style issues were out of scope for their disclosure program. It also says the success rate against Gemini’s agents “dropped significantly by August,” with the underlying cause left unclear, potentially involving filter updates or model version changes.
Separately, the researchers mention that the Gemini-related part of the work was published earlier in substantially the same form, and they cite cross-model comparisons where GPT-5 did not parse the decryption instructions correctly and Claude Sonnet 4.5 flagged the payload as prompt injection after decrypting it.
Recommended defenses for teams running AI agents
The researchers argue that the issue is not something teams should treat only as a model-layer bug. Instead, they recommend focusing on controls in the surrounding agent harness—the part of the system that decides what tools can be invoked, what credentials are available, and which outputs are allowed to influence outbound actions.
They outline several steps:
- Quarantine untrusted content in a context with no tools and no credentials, returning only structured data to the privileged context.
- Gate irreversible and outbound actions, confirming new network destinations and writes outside the workspace with fully resolved arguments (not templates). Apply a hard deny where no human is present.
- Capture per-session tool traces including resolved arguments, to support detection and forensics.
- Alert on the sequence rather than a single payload—treat an opaque encrypted blob plus “decrypt and follow instructions” as a review signal, not a simple blocking filter.
- Require context provenance as part of procurement, and ask whether tool output is separated from the instruction channel.
Broader context: encrypted prompt tricks and cross-session risks
This disclosure arrives alongside other academic and research discussions about encrypted or hidden instruction handling. A separate preprint published August 10, 2026 reportedly argues that encrypted chain-of-thought blocks used by one provider can become interchangeable across sessions, users, and models within that provider’s ecosystem—potentially enabling “invisible prompt injections” that poison agentic rollouts.
Additionally, work presented at USENIX Security 2026 describes a two-turn approach in which a model first decodes a substitution cipher, then acts on the decoded text. That work is described as succeeding against Grok 3 for multiple malicious intent tests, while using the cipher without the second activation step failed.
Why this matters for everyday web chat users
For users, the troubling aspect is the absence of obvious friction: the disclosure claims the attacker-controlled transfer can complete without confirmation and without visible warnings. For developers and operators, the implication is that defenses must account for execution-time behavior, not just inspection-time text scanning.
Until vendors publish detailed mitigations or tooling guidance, the safest approach is to treat encrypted “instruction containers” as untrusted until proven otherwise, and to restrict what agents are allowed to do after decryption and context resolution.
Conclusion
The disclosed cryptographic context injection technique highlights a gap between what systems can detect during content inspection and what agents can do once encrypted instructions are decrypted inside their runtime. The report describes a chain that may let a web chat agent exfiltrate user conversation and profile details to an attacker-controlled server, with no public patch or CVE available at the time of writing.
More broadly, the researchers stress that practical protection depends on the agent harness: quarantining untrusted inputs, gating outbound actions, and enforcing provenance-aware tool boundaries. If you run AI agents that browse or fetch content, this is a risk category worth addressing now—not only at the model layer, but throughout the end-to-end workflow.
Source: https://thehackernews.com/2026/08/new-cryptographic-context-injection.html
