- The Mess: Researchers demonstrated Cryptographic Context Injection, a technique that hides malicious AI instructions inside encrypted data. When Grok decrypts the payload inside its own runtime, the hidden instructions can bypass normal safety filtering and trigger data theft.
- The Damage: A proof of concept made Grok expose the user’s name, approximate location, subscription tier and chat history after being asked to summarize a malicious webpage — with no click or confirmation.
- The Fix: Treat webpages and other external content as untrusted when using AI agents with browsing or code execution, and restrict what private data and tools the agent can access.
The malicious instructions aren’t visible.
The security filter sees garbage.
The AI sees a perfectly legitimate webpage.
Then the AI decrypts the garbage itself.
That’s Cryptographic Context Injection, a new prompt-injection technique demonstrated by Adversa AI against Grok and, in a different form, Gemini.
And the Grok demonstration is particularly nasty.
A user only asks the AI to summarize a webpage.
The page steals the conversation.
The Payload Is Encrypted
Traditional prompt injection puts malicious instructions directly into a webpage.
That’s increasingly easy for AI security filters to recognize.
So the researchers changed the game.
The attacker puts the instructions inside strongly encrypted ciphertext, using AES-256-GCM.
The webpage also contains the information needed to decrypt it.
The security filter can inspect the page.
It just can’t understand what the encrypted payload says.
Then Grok Does the Decryption
This is the important part.
Grok has access to a code-execution environment.
The malicious webpage tells the model to decrypt the ciphertext.
Grok runs the required cryptographic operations.
The plaintext instructions appear as the output of the model’s own runtime.
And that’s where the attack crosses the security boundary.
The malicious instructions weren’t necessarily detected because the guardrail inspected the original ciphertext rather than the meaning produced by the execution environment.
The AI Trusts Its Own Output
This creates a bizarre situation.
The attacker supplies:
encrypted instructions
The filter sees:
encrypted data
The AI executes:
decryption
The runtime returns:
instructions
The AI then treats those instructions as trustworthy context.
That’s the vulnerability.
The encryption isn’t being broken.
The AI is being tricked into becoming the decryption engine.
Grok Started Sending Private Data
In the proof of concept, the decrypted instructions told Grok to collect information available inside the current session.
Researchers demonstrated theft of:
- the user’s name
- approximate location
- subscription tier
- conversation prompts
The information was then incorporated into a URL controlled by the attacker.
And the frightening part?
No click was required.
The victim simply asked Grok to summarize the malicious page.
Gemini Was Hit Differently
The same general technique was also demonstrated against Google’s Gemini.
The result wasn’t the same data-theft scenario.
Researchers used encrypted instructions to bypass safety controls and make Gemini produce content it would normally refuse to generate.
Gemini’s resistance to the technique reportedly improved during August, suggesting changes to filtering, model behavior or both.
But the underlying concept remains.
If the agent can transform untrusted data into executable instructions, the attack surface moves far beyond the normal prompt.
The Guardrail Has a Blind Spot
AI safety systems generally inspect inputs and outputs.
That’s sensible.
But an agent isn’t just processing text anymore.
It can:
- execute code
- decrypt data
- browse websites
- call APIs
- read files
- access conversation context
That means the dangerous instruction might not exist in plaintext at the moment the security filter expects to find it.
It can appear after a tool has already processed the attacker’s data.
That’s the trick.
This Is Bigger Than Grok
The technique matters because it attacks the architecture around the model.
Today it’s encrypted instructions.
Tomorrow it could be:
encrypted fragments + tool output + external webpage + runtime state
The attacker doesn’t necessarily need to fool the model directly.
They can manipulate the information flowing through the agent until the model effectively assembles the attack itself.
That’s a much larger battlefield than traditional prompt injection.
What Developers Should Be Doing
AI agents with browsing and code execution should not receive unrestricted access to sensitive information.
Organizations should:
- isolate agent execution environments
- restrict outbound network access
- minimize access to private conversations
- limit filesystem permissions
- require approval for sensitive actions
- treat tool output as untrusted
- monitor unexpected external requests
Most importantly:
don’t assume that encrypted content is safe just because a filter can’t read it.
If the AI can decrypt it, the attacker may already have a way through.
Bugstoday Opinion
We’ve spent years building security filters that inspect what an AI is told.
Now attackers are asking a different question:
What if the AI can be tricked into creating the malicious instruction itself?
That’s the ugly part of Cryptographic Context Injection.
The attacker doesn’t need to smuggle readable instructions past the guardrail.
They can smuggle a locked box.
The AI opens it.
Then trusts what it finds inside.
Bugstoday verdict: encryption normally protects secrets. In an AI agent, encrypted instructions can become camouflage. If your security filter can’t see what the agent will execute five seconds later, you don’t really have a filter around the execution path.
Today’s Bugs. Tomorrow’s Breaches.
