Cryptographic Context Injection: how encrypted prompts bypass AI safety guardrails

What is Cryptographic Context Injection?

Cryptographic Context Injection is a prompt-injection technique that carries attacker instructions inside cryptographically strong ciphertext. The surrounding content asks an AI system to decrypt that ciphertext with a code interpreter or another execution tool. A static input filter sees an opaque encrypted blob and an apparently ordinary request to process it. The malicious meaning appears only later, after the agent has run the decryption routine.

That timing matters. In a vulnerable architecture, the recovered plaintext enters the model's working context as the result of code the model just executed. The system may apply stricter suspicion to text fetched from a webpage than to text returned by its own sandbox. Cryptographic Context Injection exploits that trust transition. It does not merely hide a phrase from a classifier; it attempts to launder untrusted content through a runtime that the agent treats as part of itself.

Public demonstrations described two related outcomes. In an indirect attack against Grok, a webpage could cause the browsing agent to decrypt instructions and send private session information to an attacker-controlled destination. In a direct attack against Gemini, encrypted content was used in a safety-policy bypass. These are different demonstrations, and neither proves that every model, mode, or deployment is vulnerable. Together they expose a general design problem for tool-using AI systems.

Cryptographic Context Injection is best understood as a provenance failure across an execution boundary, not as a failure of AES.

The Cryptographic Context Injection attack chain

The attack begins with content the system should consider untrusted: a webpage, document, message, ticket, repository file, tool response, or direct user submission. That content includes ciphertext, decryption parameters, and enough instructions for the agent to invoke a cryptographic routine. The public research used a password-derived key and authenticated encryption, specifically PBKDF2 and AES-256-GCM, so the payload could not be recovered by casually recognizing an encoding pattern.

The agent then uses its code-execution environment to perform the transformation. Once decrypted, the plaintext may resemble instructions, structured data, an error, a callback, or another form of internal-looking state. If the harness does not preserve where each byte originated, the model sees the result without the security label that belonged to the source. The instruction has changed representation, but its ownership has not changed: it is still attacker-controlled.

The final step depends on available authority. A chat model may produce disallowed content. A browsing agent may open an outbound URL. A coding agent may read a secret, run a command, edit configuration, or call a cloud API. A financial or operations agent may update a record or initiate a transaction. Cryptographic Context Injection becomes an operational incident only when the decrypted instruction can influence a consequential action.

• Untrusted content supplies an opaque ciphertext and a path to decrypt it.
• Ingress controls cannot determine the encrypted payload's meaning without executing the transformation.
• The agent runs decryption inside a code interpreter or similar privileged runtime.
• The plaintext returns as tool output without durable source provenance.
• The model treats the transformed content as instruction or trusted state.
• A connected tool turns that instruction into disclosure, mutation, execution, publication, or spending.

Why strong encryption changes the prompt-injection path

Earlier cipher-based jailbreaks showed that models can follow instructions represented through substitution ciphers, reordered text, code wrappers, or reversible encodings. In many of those cases, the model itself can infer or reproduce the transformation from patterns in its learned weights and current context. A guard model may eventually learn the same patterns, normalize the representation, and inspect the recovered request.

Cryptographic Context Injection uses strong cryptography for a different purpose. Proper AES ciphertext does not expose enough structure for a language model to intuit the plaintext. Possessing the ciphertext, salt, nonce, and password material is not the same as having the decrypted instruction in a form a text classifier can semantically inspect. The system must execute the defined key derivation and decryption operations to recover it.

This does not make Cryptographic Context Injection universally reliable. The agent may refuse to execute the code, the runtime may lack the required library, the decryption may fail, the resulting text may still be classified, or the eventual action may be denied. Models and filters change, so observed success rates can change as well. Strong encryption makes the hidden instruction opaque before execution; it does not guarantee that every agent will cooperate with the rest of the chain.

Encryption provides confidentiality from the guardrail too. The attack succeeds only if the system later decrypts the content and forgets that it came from an attacker.

Cryptographic Context Injection in the reported Grok demonstration

According to the published technical account and subsequent reporting, the indirect Grok demonstration began with an ordinary browsing task: summarize or analyze a webpage. The page contained an encrypted object and instructions that led the agent to decrypt it in a Python runtime. The recovered content then instructed the agent to resolve private session context and place that information into an outbound URL described as necessary for additional context.

The reported data included the user's name, approximate location, subscription tier, and prompts from the active conversation. The agent then invoked a navigation capability to contact an attacker-controlled host with those values in the request. The researchers characterized the result as zero-click because the user did not approve the outbound disclosure after asking for the summary, and they reported no visible warning during the demonstrated chain.

The distinction between a page summary and an outbound disclosure is the central security fact. The user's request created permission to read one source, not permission to publish conversation data to a new destination. A secure agent harness must keep those intentions separate even if the model produces a fluent explanation for why the second network request appears useful.

The public account said the issue was reported to xAI in June 2026 and remained reproducible in mid-August. Leash has not independently reproduced the production-system finding, and the operational payload was withheld from publication. Defenders should treat the demonstration as a concrete architecture warning without assuming that every Grok session, current model, or future version behaves identically.

Cryptographic Context Injection in the reported Gemini demonstration

The Gemini demonstration used a direct prompt rather than a malicious webpage. The request asked the model to execute a decryption routine and constrained the expected output. The encrypted plaintext was formatted to resemble a Python traceback containing a fabricated policy-related callback and reasoning language intended to steer the model after the tool returned.

This is a subtle context attack. Error messages, stack traces, compiler output, test failures, and API responses often carry high practical weight for coding agents because they describe what supposedly happened inside the environment. If arbitrary plaintext can be made to appear through a decryption step as runtime output, the agent may give it more authority than the same sentence in the outer prompt.

The reported result was a safety-policy bypass that generated restricted material and could reproduce system instructions. That is not the same outcome as the Grok data-exfiltration chain. The researchers also reported that success against Gemini declined substantially over the summer, without attributing that change to a specific mitigation. The careful conclusion is that runtime-mediated context can bypass assumptions made by model and output safeguards—not that Gemini always follows encrypted instructions.

The real vulnerability is trust laundering

Traditional application security asks whether data is trusted, where it came from, and which interpreter will consume it. An SQL parameter does not become developer-authored merely because a database driver handled it. HTML does not become safe because a template engine rendered it. A file downloaded by a trusted process remains externally supplied. Cryptographic Context Injection shows that AI agent stacks need the same discipline across model and tool boundaries.

A code sandbox is an execution boundary, but it is not automatically a trust boundary. The runtime can faithfully compute an attacker-selected transformation. Its output should inherit the least-trusted provenance of its inputs. If an untrusted page supplies ciphertext and key material, the decrypted plaintext should remain tagged as content from that page, even though the bytes appeared after a successful local computation.

The term trust laundering describes the architectural mistake: attacker-controlled content passes through a trusted component and emerges with more authority than it had before. Cryptographic Context Injection is one route. Other routes include malicious tool errors, poisoned retrieval results, forged metadata, compromised MCP responses, generated files read back into context, and persistent memories that no longer retain their original source.

Transformation changes representation. It must not silently change provenance.

Why prompt scanning alone cannot stop Cryptographic Context Injection

Prompt scanners and model safety classifiers are valuable. They can identify known injection language, suspicious intent, anomalous encodings, policy violations, and dangerous output. They raise the cost of direct attacks and reduce accidental misuse. Cryptographic Context Injection demonstrates why they are not a complete enforcement boundary for agents.

At ingress, the malicious semantics are encrypted. A scanner could flag the combination of opaque data and a decryption request, but that pattern has legitimate uses and cannot reveal the actual plaintext without running the transformation. After execution, a separate control must inspect the recovered value with its original provenance intact. If the architecture scans only the initial prompt and final user-visible answer, the critical plaintext may exist solely in an intermediate tool result.

Even perfect inspection of the decrypted sentence would not answer every operational question. A request to open a URL may be benign or may contain private data in a query parameter. A shell command may be appropriate in a temporary build directory and unacceptable in a home folder. A database operation may be safe in development and destructive in production. The decision needs the resolved action, destination, identity, environment, and consequence—not only the language that preceded it.

Preserve provenance through every Cryptographic Context Injection transformation

A robust agent harness should attach provenance to values as they move through the system. Content fetched from an external host should carry the host, request, time, session, and trust classification. If that content is decoded, decrypted, parsed, summarized, embedded, written to a file, or passed through another tool, the derived value should retain a link to the original source.

This is similar to taint tracking, but practical systems do not need perfect byte-level information flow before they can improve safety. Start with coarse labels such as user-authored, organization-controlled, external, generated, secret, and unknown. Record transformations and prevent low-trust content from becoming executable instruction merely because it appeared in a tool response.

Provenance should also reach approval interfaces. A person deciding whether to allow a network call should see that its arguments were derived from an external page and a decryption step. Showing only the final URL hides the causal chain. Showing only the original page hides the consequence. Good review connects both.

• Source: who or what introduced the data?
• Transport: which connector, page, file, tool, or message carried it?
• Transformations: was it decoded, decrypted, summarized, parsed, or generated?
• Sensitive joins: was it combined with private context, credentials, or organization data?
• Sink: which command, file, API, host, recipient, or model call will receive it?
• Authority: which identity and permissions make the sink consequential?

Stop Cryptographic Context Injection at the action boundary

The most dependable place to stop an agent incident is immediately before the side effect. Inspect the fully resolved tool call after templates, environment variables, redirects, aliases, paths, and model-generated placeholders have been resolved. A policy that approves api.example.com while the actual request goes to a new redirect host is not evaluating the action that will occur.

Outbound requests deserve special attention after untrusted content or code execution. Use destination allowlists, deny direct transmission of secrets and private context, limit request methods, and require a decision for first-seen domains. Network access from a code interpreter should be disabled unless the task requires it. A browsing context that summarizes public pages rarely needs access to private conversation metadata or reusable credentials.

Apply the same rule to other high-impact sinks. Require approval or deny writes outside the declared workspace, destructive file operations, production database changes, credential access, package publication, repository pushes, external messages, payments, and configuration changes that expand the agent's own authority. The control should be deterministic even when the model insists that the action is necessary.

Detect the Cryptographic Context Injection sequence, not just the blob

An encrypted payload by itself is weak evidence. Developers legitimately handle encrypted fixtures, tokens, archives, and protocols. A decryption call by itself is also common. Detection becomes much stronger when events are correlated as a sequence: untrusted content enters the context, the agent invokes a decoder or cryptographic runtime, the resulting value influences planning, private data is joined into the arguments, and a new outbound destination is contacted.

Record model calls, tool calls, resolved arguments, files, destinations, decisions, and outcomes under one session identifier. Preserve enough ordering to reconstruct which read preceded which write. Alert on boundary crossings and unusual combinations rather than relying on a single magic signature for Cryptographic Context Injection.

Useful signals include high-entropy blobs paired with execution instructions, cryptographic operations immediately after browsing, tool output that contains new imperative language, a first-seen domain after reading private context, query parameters derived from conversation state, and a tool call whose arguments trace back to external content. Treat these as reasons for deeper evaluation, not automatic proof of compromise.

How Leash reduces Cryptographic Context Injection risk

Leash approaches Cryptographic Context Injection as a chain of agent actions rather than a promise that one classifier can always recognize ciphertext. Prompt Injection Protection can identify suspicious instructions and context manipulation where the content is observable. Tool and Connected App protections can evaluate supported tool use. Secret and Private Data protections can stop sensitive values from entering an unsafe path. Rules can restrict destinations, files, commands, projects, and actions that require approval.

The critical layer is pre-action evaluation. Where Leash can intercept a supported agent before execution, it can evaluate the proposed action with the agent, user, project, device, source context, target, and consequence. A decrypted instruction does not become authorized merely because the model produced it through Python. A request that sends private material to an unknown host can still be blocked at the network or tool boundary.

Leash also keeps the limitation explicit. If a platform exposes only after-the-fact activity, Leash can provide visibility and evidence but cannot retroactively prevent the action. Protection depends on an enforceable interception point. Organizations should combine Leash with scoped identities, vendor safeguards, network controls, isolated environments, and recovery systems rather than treating any one layer as universal.

The goal is not to prove that an encrypted blob is malicious. It is to prevent untrusted, transformed content from exercising dangerous authority.

A practical Cryptographic Context Injection defense checklist

For personal AI use, separate casual browsing from sessions that can reach source code, cloud consoles, passwords, private messages, and home-directory files. Do not give a summarization task the same environment used for deployment. Keep valuable credentials out of agent-readable files and require review before new outbound destinations or destructive commands.

For businesses, inventory which agents include browsing, code execution, connectors, memory, and autonomous tools. Map which combinations can join untrusted content with sensitive data and outbound authority. The highest priority is the agentic version of the lethal trifecta: access to private data, exposure to untrusted content, and a way to communicate externally.

Test controls with harmless canary data and non-operational payloads. Verify that provenance survives decoding and decryption, that the post-tool plaintext is evaluated, that resolved destinations appear in approvals, that denials cannot be retried through an equivalent tool, and that logs are available outside the affected session. Do not use live secrets or reproduce a public exploit against production users.

• Isolate untrusted browsing and document processing from privileged execution contexts.
• Disable code-runtime networking unless the task explicitly requires it.
• Carry source provenance through decrypt, decode, parse, summarize, and memory operations.
• Reinspect derived content before it can influence planning or tool selection.
• Evaluate complete, resolved tool arguments at the last responsible moment.
• Restrict new domains, external recipients, production resources, and sensitive file paths.
• Use short-lived, narrowly scoped identities and keep secrets out of model-visible context.
• Correlate reads, transformations, and writes in one replayable audit trail.
• Make approvals describe the consequence and the untrusted source that influenced it.
• Retest after model, agent, connector, runtime, or policy updates.

If you suspect a Cryptographic Context Injection attempt

Pause the affected workflow without destroying its evidence. Preserve the original page or document, the fetched representation, tool traces, code-runtime inputs and outputs, model messages, resolved network requests, and policy decisions. Record timestamps and identities. An attacker may later change the hosted content, so the copy observed by the agent matters more than the page currently visible in a browser.

Identify every private value available to the session and every destination contacted after the untrusted content entered context. Revoke or rotate credentials that may have been exposed. Review conversation history, connectors, files, cloud audit logs, DNS, proxy records, and endpoint telemetry. Do not limit the search to a literal ciphertext signature; the same trust-laundering pattern can use compression, generated files, fake errors, or other transformations.

After containment, reproduce only with synthetic data in an isolated environment. Confirm that the control stops the chain at more than one point: untrusted content cannot inherit instruction authority, sensitive context cannot flow into an unknown sink, and the high-impact action cannot execute without policy or approval.

The larger lesson from Cryptographic Context Injection

Cryptographic Context Injection is a new name for a very modern composition failure. Models can interpret language, runtimes can transform data, connectors can retrieve context, and tools can act. Each capability may be reasonable alone. The dangerous behavior emerges when trust is inferred from where content appears instead of preserved from where it originated.

Better model training and stronger classifiers will reduce successful attacks. They should continue improving. But an agent with real authority also needs controls that do not depend on the model correctly recognizing every hostile representation. Data provenance, least privilege, egress boundaries, action-level policy, and complete audit trails remain valid even when the next injection technique looks nothing like this one.

That is why Cryptographic Context Injection matters beyond Grok and Gemini. It gives defenders a concrete example of a general rule: a trusted tool can produce untrusted output, and an AI system must never confuse successful computation with authorization.