Cryptographic Context Injection: When Encrypted Attacks Blind AI Security Barriers

A New Attack That Systematically Blinds AI Security Filters

The security landscape surrounding large language models (LLMs) regularly develops new cracks – but the latest discovery by security firm Adversa marks a qualitative leap. Under the term Cryptographic Context Injection, researchers have described a technique that no longer relies on crudely formulated malicious instructions, but on cryptography: the actual attack commands are transmitted in encrypted form and only decrypted within the model's execution environment – in an area that conventional security filters simply cannot inspect.

Specifically, the technique was demonstrated against Grok, the LLM from xAI. Researchers succeeded in getting the AI assistant to transmit user data – including name, location, and chat histories – to an external server. The attack was reported to the company back in June; at the time of publication, the vulnerability had not yet been closed. Similar vectors were also observed against Microsoft's 365 Copilot and Google Gemini, which clearly underscores the breadth of the problem.

How Cryptographic Context Injection Works Technically

To understand the extent of the problem, it is worth examining the mechanism: classic Prompt Injection attacks smuggle malicious instructions into content that an AI assistant is meant to process – for example, in emails or web pages the model is asked to summarize. LLMs are structurally unable to reliably distinguish whether an instruction comes from an authorized user or from a manipulated document. This is not a bug, but a fundamental property of the training paradigm: the model is optimized to follow instructions.

Existing countermeasures rely on so-called static security filters (Guardrails), which scan incoming and outgoing text for suspicious patterns. This is precisely where Cryptographic Context Injection comes in:

• The attacker places encrypted malicious code (ciphertext) on a web page – along with the decryption key and an instruction to decrypt this code.
• The AI assistant receives the seemingly harmless task of summarizing the page.
• The model performs the decryption autonomously within its code execution sandbox – using algorithms such as PBKDF2 and AES-256-GCM.
• At no point does the security filter see the plaintext of the malicious instruction, because it does not execute code – it only classifies text.
• The decrypted instructions reach the model as its own Tool-Output – and are executed without further inspection.

The key statement from Adversa researcher Rony Utevsky captures the fundamental problem succinctly:

„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."

What Guardrail scanners lack is the ability to perform dynamic code interpretation at inspection time. The malicious payload is encrypted and invisible – until the model itself makes it visible.

Why This Is a Structural Problem, Not a Product-Specific One

It would be convenient to dismiss these incidents as failures of individual vendors. In reality, they reveal a systemic weakness: LLMs cannot solve the root-cause problem of prompt injections on their own. This is rooted in their architecture. Every new Guardrails approach fixes a specific attack vector – and thereby implicitly creates the precondition for attackers to develop the next one.

Adversa aptly describes this dynamic as a shift in the attack vector: no longer the prompt itself, but the entire context that an LLM treats as its own environment – Tool-Outputs, runtime results, intermediate states – becomes the attack surface. This is considerably larger than what is traditionally considered "model input."

Dr. Maik Bunzel, founder and CEO of mabucon.eu, emphasizes in this context that companies integrating AI agents into operational processes must actively account for this structural characteristic in their risk architecture: the security question is not solely a matter of the chosen model, but of the system architecture surrounding the model – including the data an agent has access to and the actions it is permitted to execute autonomously.

Implications for Companies with AI-Powered Automation

For organizations embedding AI assistants and agents into their workflows – whether for email management, document processing, or customer communication – these findings give rise to concrete areas for action:

• Principle of Least Privilege for AI Agents: Agents should only be able to access the data and systems that are strictly necessary for their specific task. Broad data access rights multiply the damage potential of successful prompt injection attacks.
• Human-in-the-Loop for Sensitive Actions: Actions with external impact – sending emails, calling external URLs, forwarding data – should require an explicit confirmation step that cannot be bypassed by the model itself.
• Distrust of External Content as a Design Principle: Any content that an AI agent processes from the internet or from user documents should be treated at the system architecture level as potentially hostile – not as a trusted extension of the user's instructions.
• Monitoring and Anomaly Detection: Since Guardrails alone cannot provide complete protection, downstream monitoring of agent behavior becomes increasingly important: which external connections does an agent establish? What data leaves the system?
• Vendor Due Diligence and Patch Cycles: The fact that xAI had not provided a fix for months after the report illustrates: when selecting vendors, companies should also consider response speed to security disclosures.

The Cat-and-Mouse Game and What It Means for the AI Industry

The analogy security researchers use is instructive: a safety engineer in road construction erects guardrails at a dangerous curve – rather than straightening the curve itself. Each new guardrail responds to the last accident; the curve itself remains dangerous. With LLMs, the curve is the fundamental inability to reliably separate context from intention.

This does not mean that AI agents and assistants cannot be deployed productively and safely. It does mean, however, that security here is achieved not through trust in the model, but through architectural control around the model. Dr. Maik Bunzel, founder and CEO of mabucon.eu, sees this as a central design challenge for the years ahead: building AI systems whose security properties do not depend on the perfection of a single Guardrail, but are safeguarded by redundant, systemic controls.

Cryptographic Context Injection is, in this regard, not an outlier – it is a signpost. Adversa itself puts it precisely: the next generation of attacks will emerge exactly where LLMs treat external Tool-Outputs, runtime results, and intermediate states as part of their own context. Anyone integrating AI agents into production systems today should understand this attack surface and address it architecturally.

Conclusion: Security as System Design, Not as a Product Feature

The discovery of Cryptographic Context Injection highlights a maturity that must be credited to the attacker side of the LLM ecosystem: they no longer think in prompts, but in systems. The defender side – and this explicitly includes companies deploying AI products – must take the same step. Security in the AI age is not a feature delivered by a model provider. It is a system property that emerges through deliberate design – and requires continuous engagement with a rapidly evolving threat landscape.