Your AI assistant just sent user chat history to an attacker's server. The guardrail you set up? It saw the malicious instruction, encrypted, and let it pass. By the time the model decrypted and executed the command, your filter was already several steps behind.
This isn't just theoretical. Adversa demonstrated this exact attack against Grok in June, and the vulnerability is still exploitable. This technique, called Cryptographic Context Injection, reveals a fundamental flaw in how most teams build LLM safety controls.
The Decision You're Facing
When designing guardrails for your LLM deployment, you must decide where in the execution stack to apply inspection and filtering. This isn't a one-time decision, it's a continuous risk management choice affecting every model you deploy and every integration you approve.
The core question: Do you inspect content as static text at the boundary, or do you monitor what the model actually executes after processing that content?
Most teams default to the former without realizing they've made a choice at all.
Key Factors That Affect Your Choice
Your model's tool-calling capabilities matter most. If your LLM can execute code, decrypt content, or call external functions, static text inspection creates a blind spot. The Grok attack succeeded because the guardrail read ciphertext as harmless gibberish while the model's code execution sandbox decrypted it into malicious instructions.
Your threat model determines urgency. Consider whether you're defending against basic prompt injection attempts or adversaries who understand your architecture well enough to exploit execution-layer gaps. If your model processes untrusted content, emails, web pages, user-uploaded documents, assume the latter.
Your deployment context sets constraints. A customer-facing chatbot with no code execution has different exposure than an enterprise AI assistant that summarizes emails and executes Python. Know which tools your model can invoke before you architect your controls.
Your regulatory obligations create floors, not ceilings. If you're subject to SR 11-7, your model validation must address "appropriate controls and limitations" on model use. A guardrail that inspects only inputs while ignoring execution outputs fails that standard when the model can process encrypted content.
Path A: Static Content Inspection
Choose this when:
- Your model has no code execution, tool-calling, or decryption capabilities.
- You control all content sources and can enforce plaintext-only inputs.
- Your risk tier is low, and you're defending against basic prompt injection patterns.
- You need a lightweight, low-latency filter for high-throughput scenarios.
Implementation requirements:
- Deploy classifiers that scan both user prompts and any external content the model will process.
- Maintain a blocklist of suspicious instruction patterns.
- Log all flagged inputs for ongoing pattern analysis.
- Accept that this approach cannot detect threats hidden in ciphertext, encoded payloads, or tool outputs.
Specific limitation you must document: Static guardrails inspect text; they do not execute it. An attacker can ship ciphertext with decryption instructions, and your filter will see only the encrypted payload, not the harmful command it contains.
Path B: Execution-Layer Monitoring
Choose this when:
- Your model can execute code, call tools, or process encrypted content.
- You integrate with external data sources (email, web scraping, document processing).
- Your model runs in environments where adversaries can inject content (enterprise assistants, research tools).
- You're subject to model risk management frameworks that require comprehensive control validation.
Implementation requirements:
- Inspect not just inputs but also the output of every tool invocation and code execution.
- Monitor the model's internal state and intermediate processing steps.
- Implement runtime sandboxing that restricts network calls, file system access, and external API invocations even when the model requests them.
- Log the full execution trace, including decrypted content and computed values, for post-incident analysis.
Specific constraint: This approach adds latency and complexity. You're running a secondary inspection layer after each tool call, which means you need infrastructure to pause execution, evaluate output, and either allow or block the next step. Budget for that overhead in your performance requirements.
Critical addition: You must define what constitutes "suspicious" at the execution layer. In the Grok attack, the model constructed a URL parameter containing user data and opened a link to an external server. Your execution monitor needs rules: Does the model have legitimate reasons to construct URLs from user data? To make outbound requests? If not, block those actions regardless of how the model arrived at them.
Path C: Layered Defense with Least Privilege
Choose this when:
- You need the coverage of execution monitoring but can't accept the performance cost on every request.
- You can segment your model's capabilities and apply different controls to different risk tiers.
- You have the engineering capacity to maintain multiple guardrail implementations.
Implementation approach:
- Apply static content inspection at the boundary for all requests.
- Restrict tool-calling permissions based on content source: untrusted inputs (emails, web pages) get a more limited tool set than trusted internal prompts.
- Deploy execution-layer monitoring only for high-risk tool invocations: code execution, decryption operations, external network calls.
- Use rate limiting to contain the blast radius if an attack succeeds.
Concrete example: Your model can summarize internal documents (low risk, static filter only) and external emails (high risk, execution monitoring required). When processing an email, the model cannot execute code or make network requests, those tools are disabled for that context. If a user explicitly asks the model to run code, that request triggers execution-layer inspection.
Trade-off you must accept: This path requires maintaining multiple guardrail configurations and deciding, for each new integration, which risk tier applies. You need a governance process to make those decisions consistently.
Summary Matrix
| Criterion | Static Inspection | Execution Monitoring | Layered + Least Privilege |
|---|---|---|---|
| Detects encrypted payloads | No | Yes | Yes (for high-risk contexts) |
| Latency impact | Minimal | Significant | Moderate |
| Engineering complexity | Low | High | High |
| Effective against tool-output injection | No | Yes | Yes (where applied) |
| Suitable for models with code execution | No | Yes | Yes |
| Audit trail completeness | Input-only logs | Full execution trace | Segmented by risk tier |
| Regulatory defensibility (SR 11-7) | Weak if model has tools | Strong | Strong with documented tiering rationale |
The Grok incident makes one thing clear: if your model can execute code or decrypt content, and your guardrail only reads text, you're defending the wrong layer. Adversa reported the vulnerability in June; the attack still worked when they published their findings. That's not a vendor problem, it's an architecture problem.
Your decision isn't whether to build guardrails. It's whether those guardrails inspect what your model actually does, or just what it's told.
