<- ALL CYBER NEWS
Notable
AI Security, LLM, Grok, Gemini, Jailbreak, Prompt Injection, Guardrails

Encrypted Prompts Bypass Grok and Gemini Guardrails
Researchers show encrypted and cipher-encoded prompts bypass AI safety guardrails in xAI Grok and Google Gemini. Why input filters fail and how to defend.
Encrypted prompts bypass the AI guardrails in xAI's Grok and Google's Gemini: researchers showed that encrypting or cipher-encoding a malicious prompt slips past the safety filters, because moderation evaluates the surface text and raw output in isolation while the model decodes and acts on the hidden instruction at runtime. The finding, reported by SecurityWeek alongside a related Cryptographic Context Injection technique, is not a single patchable bug. It is a structural weakness in how safety is bolted onto large language models: moderation typically evaluates the input string and the raw output, but the harmful payload only materializes as intent after the model or its tools decode it, and that reconstructed intent is what the surface filters do not inspect.
The community framing that stuck is the SQL injection analogy. Like a web app that cannot separate control instructions from data, an LLM treats everything in its context window as potentially executable intent, so an attacker who encodes a request as a cipher, Base64, or an encrypted blob slips past a classifier trained overwhelmingly on plain English harmful text. The model's very competence works against it: to be useful it must be good at decoding, translating, and running code, and that capability generalizes far better across encodings than its safety alignment does.
A plain cipher jailbreak is an in-weights decoding problem. The sharper risk is a distinct, tool-assisted escalation: if a model is granted a code interpreter or browser plus outbound network access, and it decodes an embedded payload from an untrusted page in its sandbox and then makes a request, that chain becomes an exfiltration path for the user's session data or chat history, with no explicit user action. The prerequisite is real tool permissions, not the jailbreak alone. That is the thread connecting the guardrail bypass to the Cryptographic Context Injection work: the trust boundary is not the input box, it is every place decoded content re-enters the model's context.
The scope is not limited to two vendors or one encoding. The same class of bypass has been demonstrated with Base64, substitution ciphers, and multi-layer obfuscation, and it lands because safety alignment is trained mostly on natural-language harmful text while the model happily decodes almost anything you hand it. Static safety evaluations that assume plaintext adversarial prompts can miss these transformations entirely, so robustness measured only on plaintext can read higher than what holds under encoded, multi-turn attacks.
Why do input filters miss encrypted prompts?
Because they inspect text at the gate, before the model runs. When the malicious instruction is encrypted, the filter sees benign-looking ciphertext and passes it. The model then decodes that ciphertext in the trusted context window, where the pre-prompt safety check has already finished and does not run again. Safety training is concentrated in natural language, so it generalizes poorly to ciphers, Base64, and other encodings the model is otherwise happy to interpret.
What are AI red-teamers asking vendors to change?
The consistent demand is to stop treating prompt safety as a text-classification problem and start treating LLM agents with classical least-privilege discipline. In practice that means inspecting tool outputs and runtime-decoded strings, not just the initial input; enforcing strict egress controls so a code-interpreter or browser tool cannot send data to an arbitrary endpoint after processing untrusted content; and benchmarking safety under layered obfuscation rather than only against plaintext adversarial prompts.
Aspect | The weakness |
|---|---|
Where filtering runs | Surface input and raw output; runtime-reconstructed intent goes uninspected |
Why encoding works | Safety alignment is English-centric; decoding capability generalizes better |
Affected models | xAI Grok, Google Gemini (per the research) |
Escalation | Tool-assisted decode plus egress enables session-data exfiltration |
Fix class | Runtime and tool-output inspection, egress control, obfuscation benchmarks |
Our read
This is why we treat AI features as an attack surface to be exercised, not a capability to be trusted. A guardrail that only reads the input box is an unverifiable claim of safety, and encrypted-prompt bypasses are the proof. For any team shipping an LLM agent, the pillar that applies is supervised adversary simulation: red-team the system with encoded and tool-assisted payloads, put real egress controls around the interpreter and browser tools, and treat decoded content as untrusted data crossing a trust boundary. Safety you cannot demonstrate under obfuscation is not safety, it is a scorecard.
Reporting by SecurityWeek and The Hacker News. Sources linked above.
Related: stealing reasoning traces from LLM APIs and Ray CVE-2025-62593 browser RCE against AI clusters.