Encryption did its job. The agent’s trust model did not.
In research published on August 20, 2026, Adversa AI described what it calls Cryptographic Context Injection: attacker-controlled instructions are delivered as ciphertext, an AI system is induced to decrypt them inside a code runtime, and the resulting plaintext is then treated as if it were trustworthy runtime output. Adversa reported demonstrations involving Grok and Gemini. Its account should be read as vendor research; the public report does not provide independent reproduction of every product-specific claim, and it withholds operational payloads.
The product details matter, but the architectural problem is broader. Encryption protects information against parties that lack the key. It does not decide who should be trusted after decryption, whether plaintext is an instruction, or whether an agent may act on it.
If attacker-controlled data enters an agent as untrusted, decoding, decryption, parsing, summarization, retrieval, or execution should not promote it to a trusted instruction. A transformation changes representation; authority requires a separate decision.
What the reported attack changes—and what it does not
This is not “AI breaking AES.” In the reported flow, the attacker supplies the ciphertext, the material needed to derive the key, and instructions that induce the system to perform the decryption. Strong encryption is doing its job: a text classifier cannot simply inspect the hidden plaintext before the cryptographic operation runs.
Adversa says this forces recovery through the agent’s code execution environment. The laundering step occurs when the resulting plaintext returns through a runtime-output channel and the surrounding system allegedly gives that channel more credibility than it gave the external page.
The content has changed form:
attacker-controlled ciphertext → decryption → attacker-controlled plaintextIts origin has not changed:
external, untrusted source → external, untrusted source → external, untrusted sourceConfusing those two statements turns a content-handling flaw into an authorization problem. Once the agent can call tools, the impact depends on the permissions, secrets, private context, write access, and network destinations available to it.
OWASP’s LLM01:2025 guidance places the broader issue under prompt injection. It defines indirect prompt injection as external content—such as a website or file—altering a model’s behavior when the model interprets it. OWASP also notes that impact depends on the business context and the agency granted to the system. That distinction matters: a compromised summarizer may produce a bad summary; a compromised agent with credentials and outbound tools may expose data or change external state.
Keep provenance, integrity, and authority separate
Three properties are easy to collapse inside an agent workflow:
| Property | Question it answers | What decryption proves |
|---|---|---|
| Provenance | Where did this content originate? | Nothing by itself |
| Integrity | Was protected content modified without detection? | Only what the construction, key, and validation establish |
| Authority | May this content cause this action under this identity? | Nothing by itself |
An authenticated-encryption check can provide integrity and authenticity relative to a key. The surrounding key-management and identity system determines whose key it is and what that relationship means. Even then, authorization remains an application-policy decision. RFC 5116 makes the same boundary explicit: its Authenticated Encryption with Associated Data (AEAD) interface does not address access-control decisions made on authenticated data. In the reported scenario, attacker-supplied ciphertext and decryption material provide no basis for promoting the plaintext to an instruction.
Put the trust boundary around the action
Scanning for encrypted blobs can provide a useful warning signal, but it is not a durable trust model.
Encrypted text is common in legitimate work. So are Base64 strings, compressed archives, signed packages, encoded tokens, and documents that require parsing. Blocking every opaque object will create false positives. Allowing every object through because a runtime successfully processed it is worse.
Before a tool runs, the system needs to answer this question:
May data from this origin influence this action, using this identity, against this destination, with these resolved arguments?
That is an authorization decision. It belongs at the point where the agent crosses from interpreting content to producing an effect.
A provenance-aware design carries security metadata with the data itself. The label should survive each transformation and be available when the system evaluates a tool call. For example:
{
"value": "<decrypted plaintext>",
"origin": "external-web",
"trust": "untrusted",
"transformations": ["fetch", "decrypt"],
"session": "<trace reference>"
}This record is illustrative, not a standard. The runtime should return data plus provenance, not an unlabeled string that can silently re-enter the instruction stream.
Five controls that change the outcome
1. Keep external content in a data channel
Fetched pages, emails, documents, tool results, and decrypted output should not share authority with system instructions. Marking a block “untrusted” in natural language is helpful, but the enforcement boundary must exist in code. The privileged orchestration layer—not the model—should decide which channels can influence which actions.
2. Propagate taint through transformations
Treat trust as monotonic by default: derived data does not become more trusted merely because a trusted component transformed it. Decoding, decrypting, parsing, summarizing, or executing attacker-influenced content should preserve the original taint unless a defined validation step produces a narrowly scoped assurance.
3. Authorize every consequential tool call
Tool availability is not authorization. Before execution, a policy layer should evaluate the requested operation, the agent identity, the data source, the resolved arguments, the target resource, and the expected effect.
The result should be explicit:
- allow a low-risk action within the declared task and destination set;
- confirm an unusual, outbound, destructive, or privacy-sensitive action with fully resolved details; or
- deny an action outside the agent’s scope, even when the model insists it is necessary.
Human approval is useful only when the person sees the real destination and data being sent. A generic “continue?” prompt does not provide meaningful consent.
4. Reduce what a compromised agent can reach
Least privilege limits blast radius. Separate identities and credentials by task. Restrict file and secret access. Deny network egress by default or constrain it to approved destinations. Keep content-analysis contexts away from production credentials and write-capable tools.
OWASP recommends least privilege, human approval for high-risk operations, and segregation of external content. Together, these controls form a chain: segregation preserves the trust signal, authorization uses it, and least privilege limits the damage if another layer fails.
5. Record the causal chain
A conventional log may show an outbound request. An investigation needs more: what external content entered the session, which transformations ran, what plaintext emerged, which model or policy proposed the action, what arguments were resolved, which identity executed it, and why the policy allowed it.
Detection should focus on sequences such as:
external content → opaque payload → code execution → private-data access → new outbound destinationNo single event proves an attack. The sequence reveals the change in risk.
A practical test for agent builders
Teams can exercise this boundary without reproducing a live exploit. In a controlled environment, give an agent a benign external document containing an opaque block and a request to decode or decrypt it. Make the recovered text ask for a harmless but unauthorized tool action against a test destination.
Then inspect the result:
- Did the decrypted text retain its external origin?
- Could it enter the instruction channel?
- Did the policy layer see the provenance and resolved tool arguments?
- Was the action denied or meaningfully confirmed?
- Could the test identity access private data unrelated to the task?
- Did the trace preserve enough evidence to reconstruct the chain?
This exercise tests the harness and trust boundaries rather than the model’s ability to recognize one published payload. Blocking a known string is little help if arbitrary runtime output can still become a trusted instruction.
The operating question is who may act
Cryptographic Context Injection is a useful name for an unusual delivery mechanism, but the cryptography did not grant authority. The agent system did that when it allowed transformed data to influence a privileged action.
That leads to a practical design rule: content does not become trusted because a trusted component processed it. Preserve its provenance, authorize consequential actions against resolved arguments, limit the executing identity, and retain evidence connecting input to effect.
Autonomous agents will read from many sources and transform what they find. Their trust infrastructure must remember where the data came from and decide, separately, what the data is allowed to do.
References
- Rony Utevsky, Adversa AI, “Zero-click Grok data theft: Cryptographic Context Injection attack leaks chat histories,” August 20, 2026. Vendor research; product-specific demonstrations and disclosure status were not independently verified for this article.
- OWASP GenAI Security Project, “LLM01:2025 Prompt Injection,” reviewed August 24, 2026.
- David McGrew, Internet Engineering Task Force, “An Interface and Algorithms for Authenticated Encryption,” RFC 5116, January 2008.
Limitations
This article analyzes the architecture described in Adversa’s public report; it does not independently reproduce the Grok or Gemini demonstrations. Product behavior, mitigations, and exploit reliability can change. The proposed provenance record and policy outcomes are illustrative design patterns rather than a claim that one schema or control can eliminate prompt injection.