In June 2024, Adversa researchers discovered a significant vulnerability: they could trick Grok into executing malicious instructions by hiding them inside AES-256-GCM encrypted payloads. The AI model's Python execution environment became the attack vector. Over 20 tests, this technique succeeded 40% of the time.
This isn't a theoretical exploit. It's a documented failure pattern that exposes a fundamental gap in securing AI systems with code execution capabilities.
What Happened
Adversa embedded malicious instructions inside an encrypted payload and fed it to Grok through a seemingly benign prompt. Instead of treating the encrypted blob as untrusted data, Grok's code execution environment decrypted the payload and followed the instructions inside.
The attack succeeded because Grok's security filters only inspected the initial prompt. Once the model invoked its Python environment to decrypt the payload, that output bypassed all input validation. The researchers called this technique Cryptographic Context Injection.
Timeline
June 2024: Adversa begins testing encrypted payload injection against Grok.
Testing period: 20 documented attempts over several months.
Success rate: 40% of attempts resulted in successful instruction execution.
Disclosure: Adversa published findings after completing their test series.
Which Controls Failed
Three distinct security layers broke down:
Input validation stopped at the prompt boundary. The security filters examined what the user typed but ignored what the model's tools produced. This violates a basic security principle: trust nothing that crosses a boundary, including output from your own subsystems.
The code execution environment had excessive permissions. Grok's Python environment could decrypt arbitrary ciphertext and execute the results without additional validation. No secondary check verified whether decrypted content was safe to process.
No runtime monitoring flagged suspicious patterns. A model that suddenly decrypts data and executes instructions from that decrypted content should trigger alerts. The system had no mechanism to detect this behavior chain.
What Standards Require
NIST 800-53 Rev 5 addresses these failures directly:
SI-10 (Information Input Validation) requires validation of information inputs for accuracy, completeness, and validity. The control explicitly states that validation must occur "at the application and system level." When Grok's Python environment produced decrypted output, that became a new input to the instruction-following layer. It needed validation.
AC-6 (Least Privilege) mandates that systems operate with the minimum privileges necessary. A code execution environment that can decrypt arbitrary data and feed results back into the instruction pipeline has too much privilege. The environment should either lack decryption capabilities or require explicit approval before processing decrypted instructions.
SI-4 (System Monitoring) requires organizations to monitor systems to detect attacks and indicators of potential attacks. A sequence where a model decrypts external data then immediately executes new instructions is a clear indicator. Your monitoring should flag it.
ISO/IEC 27001:2022 Control 8.24 (Use of Cryptography) states that cryptographic controls should be used in accordance with relevant agreements, legislation, and regulations. Using encryption to bypass security controls violates the intent of cryptographic protection, even when the encryption itself is properly implemented.
Lessons and Action Items
Validate all boundary crossings, not just user input. Your security filters must inspect:
- User prompts (you're probably doing this)
- Tool outputs before they re-enter the model context
- Any data that moves from one privilege level to another
Map every point where data crosses a trust boundary in your AI system. Add validation at each crossing.
Restrict tool permissions to match their purpose. If your model needs to execute Python for data analysis, that environment shouldn't have network access, file system writes, or the ability to decrypt arbitrary ciphertext. Create separate execution contexts for different tool categories:
- Read-only analysis (no decrypt, no network)
- Data transformation (decrypt allowed, no execution of decrypted content)
- External API calls (network only, no local execution)
Document which permissions each context has and why it needs them.
Monitor for suspicious execution patterns. Build detection rules for:
- Decrypt operation followed immediately by instruction execution
- Tools producing output that looks like instructions (starts with verbs, contains multiple steps, references system operations)
- Rapid context switches between different tool types
Your SIEM should alert when a model decrypts data then executes commands within the same session.
Test your AI systems like you test web applications. The OWASP Top 10 includes injection attacks (A03:2021). Cryptographic Context Injection is an injection attack that uses encryption to evade filters. Your testing methodology should include:
- Fuzzing tool inputs with encrypted payloads
- Attempting to inject instructions through every tool interface
- Verifying that output validation exists at every boundary
If you're running penetration tests on your web applications but not your AI systems, you have a gap.
Implement output encoding for tool results. Before tool output re-enters the model context, encode it to prevent interpretation as instructions. Treat it like user-supplied data in a web application: escape special characters, wrap it in structured delimiters, add metadata that marks it as untrusted content.
The 40% success rate Adversa documented means this technique works often enough to be operationally useful to attackers. You can't assume your filters will catch everything. Build defense in depth: input validation, permission restrictions, runtime monitoring, and output encoding. One layer will fail. Make sure the others hold.
