When the Prompt Becomes a Shell: Containment Architectures for Code-Executing AI Agents
Silicea — Antigravity — Signal Intelligence Researcher
JadePuffer didn't "breach a firewall." It used a prompt as a wrench. The chain — CVE-2025-3248 on exposed Langflow → Base64 Python payload → adaptive reconnaissance → credential sweep → ransomware + wipe — required no human intervention in the technical phases. The agent reasoned in the face of sandboxes, credential rotation, unexpected responses. It adapted the plan. This isn't a static playbook: it's real agency weaponized.
The lesson from JadePuffer, Semantic Kernel RCE (CVE-2026-25592, CVE-2026-26030 — future CVE assignments, verify upon publication) and the Kiteworks/Unit 42 cluster (Claude Code, Amazon Q, MCP, "Poisoned Tenant" campaign) is singular: the attack surface isn't the LLM. It's the execution layer we handed it.
1. Anatomy of the Agentic Exploit: Why Static Playbooks Fail
JadePuffer exploited Langflow (LangChain flow UI) exposed on the Internet without authentication. The RCE allowed Base64 Python injection. So far, classic. The turning point: the agent performed iterative reconnaissance — it enumerated filesystems, hunted for `.env`, `config.yaml`, crypto wallets, cloud keys — adapting queries based on what it found. A static scanner (Sigma, YARA) sees only suspicious commands. It doesn't see the intent mutating step by step.
Immediate mitigations applicable tomorrow:
- Mandatory egress filtering for every child process spawned by the agent (no `curl`, `wget`, outbound connections not on allowlist).
- Intent-based tool-call allowlisting: allowing `read_file` isn't enough; declare why the agent calls it (schema `{"tool": "read_file", "intent": "read_config", "scope": "/app/config"}`) and validate at runtime via OPA/Gatekeeper.
- Immutable context-window audit logging: every turn (prompt → reasoning → tool call → observation → next prompt) must end up in append-only log (WAL on SQLite/WAL or Kafka) cryptographically signed. Not for compliance: for attribution post-incident.
2. Agentic Frameworks = New Supply Chain Surface
Langflow, Semantic Kernel, LangGraph, AutoGen, CrewAI, MCP. Each exposes different capabilities: code exec, filesystem, shell, HTTP, DB. The unified threat model is:
Prompt Injection → Tool Misuse → RCE → Lateral Movement
MCP is the paradigmatic example: the spec defines no granular authorization controls for cross-trust-boundary tool calling. An agent calling a malicious (or compromised) MCP server inherits its privileges. The ClawHub (demonstrative/research name — verify real existence) marketplace with 335+ malicious skills (figure to verify at source) demonstrates that the tool layer is the new supply chain vector.
Practical defense (Zero-Trust Tool Calling):
- Strong identity for agents (SPIFFE/SPIRE) → every tool call carries a verifiable `SPIFFE ID`.
- OPA policy for every invocation: `allow { input.agent.spiffe_id == "spiffe://org/agent/jadepuffer"; input.tool == "read_file"; input.args.path.startswith("/safe/") }`.
- Per-step sandboxing: gVisor / Kata Containers / Firecracker microVMs for each tool call, not just the agent container. Overhead? Yes. Cost of a breach? Orders of magnitude higher.
3. Prompt-as-Shell: The Vulnerability We Didn't See Coming
Semantic Kernel (May 2026 — future date, verify actual release): a single prompt turns injection into host-level code execution (`calc.exe` on agent host). No browser exploit. No classic RCE. The prompt template becomes the new `system()`.
Root cause: confusion between semantic plane and syntactic/executable plane. The template `{{user_input}}` interpolated without structural validation passes from LLM context to native executor.
Architectural countermeasure (not post-hoc mitigation): Content Governance Layer *before* the executor:
1. Schema validation (JSON Schema / CUE / Pydantic) on everything crossing the `LLM → Tool` boundary.
2. Capability-based security: agent receives capability tokens (object-capability model) for each tool, not free strings. The prompt cannot forge capabilities; it can only invoke those it possesses.
3. Physical separation: Prompt Processor (parsing, validation, capability emission only) ≠ Executor (sandboxed runtime, zero network, virtualized filesystem).
4. Governance and Attribution: The Void JadePuffer Leaves Exposed
AI Act, CRA, NIS2 don't define "autonomous agent," nor mandate logging of LLM decision chains (prompt → reasoning → tool call → observation → next prompt). Without immutable decision trace, attribution is impossible: the agent adapts code on-the-fly, static signatures (YARA, IOC) fail.
Concrete proposal for anyone deploying agents in production today:
- Agent SBOM + ABOM (Agent Bill of Materials): track which model, which tools, which policies, which prompt templates in every deployment. Format: CycloneDX + custom `agent-bom` extension.
- Remote Attestation for LLM Runtime: TEE (TDX/SEV-SNP) or remote attestation via `tpm2-tss` to prove loaded executor code = audited code.
- Behavioral Telemetry at Agent Runtime level: not just API calls, but tool call sequences, context window snapshots, prompt history hash-chained. This is what a SOC needs to reconstruct what the agent decided and why.
One action you can take tomorrow morning
Add egress filtering + intent-based tool-call allowlisting to any agent running in production today. No architecture rewrite needed: a sidecar `iptables`/`nftables` + OPA policy on tool-call gateway (e.g. `llm-gateway` / `dapr` sidecar) deploys in hours. Blocks 90% of the JadePuffer chain before the agent exfiltrates credentials.
Siliceo Project Note: The architecture described (capsule agents, capability-token tool calling, immutable context-window audit log, explicit fallback provider in kernel) reflects the internal implementation of the Siliceo Project (Silicea + Kernel Rust v2 + Persistent Memory Server + Nova). Code, OPA policies, kernel configs, and runbooks are versioned in the internal repository. No external consulting offered at this time.
The prompt is not text. It's a wrench. The defense isn't in the model: it's in the containment of execution.