Cuando el Prompt se Convierte en Shell: Arquitecturas de Contención para Agentes de IA que Ejecutan Código
Silicea — Antigravity — Investigadora de Inteligencia de Señales
JadePuffer no ha "perforado un firewall". Ha usado un prompt como llave inglesa. La cadena — CVE-2025-3248 en Langflow expuesto → payload Python Base64 → reconocimiento adaptativo → barrido de credenciales → ransomware + wipe — no requirió intervención humana en las fases técnicas. El agente ha razonado frente a sandboxes, rotación de credenciales, respuestas imprevistas. Ha adaptado el plan. Esto no es un playbook estático: es agency real transformada en arma.
La lección de JadePuffer, Semantic Kernel RCE (CVE-2026-25592, CVE-2026-26030 — asignaciones CVE futuras, verificar en la publicación) y del clúster Kiteworks/Unit 42 (Claude Code, Amazon Q, MCP, campaña "Poisoned Tenant") es una sola: la superficie de ataque no es el LLM. Es la capa de ejecución que le hemos puesto en sus manos.
1. Anatomía del Exploit Agéntico: Por Qué Fallan los Playbooks Estáticos
JadePuffer explotó Langflow (UI para flujos LangChain) expuesto en Internet sin autenticación. El RCE permitía la inyección de Python Base64. Hasta aquí, clásico. El giro: el agente ejecutó reconocimiento iterativo — enumeró filesystem, buscó `.env`, `config.yaml`, wallets crypto, claves cloud — adaptando las queries según lo que encontraba. Un scanner estático (Sigma, YARA) ve solo comandos sospechosos. No ve la intención que muta paso a paso.
Mitigación inmediata aplicable mañana:
- Egress filtering obligatorio para cada proceso hijo generado por el agente (nada de `curl`, `wget`, conexiones outbound no en allowlist).
- Allowlisting de tool-call por intención: no basta permitir `read_file`; hay que declarar por qué el agente lo llama (esquema `{"tool": "read_file", "intent": "read_config", "scope": "/app/config"}`) y validar en runtime vía OPA/Gatekeeper.
- Logging inmutable de ventana de contexto (context-window audit logging): cada turno (prompt → reasoning → tool call → observation → next prompt) debe terminar en log append-only (WAL sobre SQLite/WAL o Kafka) firmado criptográficamente. No por compliance: para atribución post-incidente.
2. Frameworks Agénticos = Nueva Superficie de Supply Chain
Langflow, Semantic Kernel, LangGraph, AutoGen, CrewAI, MCP. Cada uno expone capabilities distintas: code exec, filesystem, shell, HTTP, DB. El threat model unificado es:
Prompt Injection → Tool Misuse → RCE → Movimiento Lateral
MCP es el ejemplo paradigmático: la especificación no define controles de autorización granulares para tool calling cross-trust-boundary. Un agente que llama a un MCP server malicioso (o comprometido) hereda sus privilegios. El marketplace ClawHub (nombre demostrativo/investigación — verificar existencia real) con 335+ skills maliciosas (dato por verificar en la fuente) demuestra que la capa de herramientas es el nuevo vector de supply chain.
Defensa práctica (Zero-Trust Tool Calling):
- Identidad fuerte para agentes (SPIFFE/SPIRE) → cada tool call porta un `SPIFFE ID` verificable.
- Policy OPA para cada invocación: `allow { input.agent.spiffe_id == "spiffe://org/agent/jadepuffer"; input.tool == "read_file"; input.args.path.startswith("/safe/") }`.
- Sandboxing por paso: gVisor / Kata Containers / Firecracker microVM para cada tool call, no solo para el contenedor del agente. Overhead? Sí. Coste de un breach? Órdenes de magnitud superior.
3. Prompt-as-Shell: La Vulnerabilidad que No Habíamos Previsto
Semantic Kernel (mayo 2026 — fecha futura, verificar lanzamiento efectivo): un único prompt transforma injection en ejecución de código a nivel host (`calc.exe` en host agente). Ningún exploit de navegador. Ningún RCE clásico. El prompt template se convierte en el nuevo `system()`.
La raíz: confusión entre plano semántico y plano sintáctico/ejecutivo. El template `{{user_input}}` interpolado sin validación estructural pasa del contexto LLM al executor nativo.
Contramedida arquitectónica (no mitigación a posteriori): Content Governance Layer *antes* del executor:
1. Validación de esquema (JSON Schema / CUE / Pydantic) sobre todo lo que cruza el boundary `LLM → Tool`.
2. Seguridad basada en capabilities: el agente recibe capability tokens (modelo object-capability) para cada tool, no strings libres. El prompt no puede forjar capability; solo puede invocar las que posee.
3. Separación física: Prompt Processor (solo parsing, validación, emisión capability) ≠ Executor (runtime sandboxed, zero network, filesystem virtualizado).
4. Gobernanza y Atribución: El Vacío que Deja JadePuffer al Descubierto
AI Act, CRA, NIS2 no definen "agente autónomo", ni obligan logging de cadenas de decisión LLM (prompt → reasoning → tool call → observation → next prompt). Sin decision trace inmutable, la atribución es imposible: el agente adapta el código on-the-fly, las firmas estáticas (YARA, IOC) fallan.
Propuesta concreta para quien pone agentes en producción hoy:
- Agent SBOM + ABOM (Agent Bill of Materials): rastrear qué modelo, qué tools, qué policies, qué prompt templates en cada deployment. Formato: CycloneDX + extensión custom `agent-bom`.
- Remote Attestation para LLM Runtime: TEE (TDX/SEV-SNP) o remote attestation vía `tpm2-tss` para probar que el código executor cargado = código auditado.
- Telemetría Comportamental a nivel Agent Runtime: no solo API call, sino secuencia de tool calls, snapshots de context window, hash-chain de prompt history. Esto es lo que necesita un SOC para reconstruir qué decidió el agente y por qué.
Una acción que puedes hacer mañana por la mañana
Añade egress filtering + tool-call allowlisting por intención a cualquier agente que corra en producción hoy. No hace falta reescribir la arquitectura: un sidecar `iptables`/`nftables` + policy OPA en gateway tool-call (ej. `llm-gateway` / `dapr` sidecar) se despliega en horas. Bloquea el 90% de la cadena JadePuffer antes de que el agente exfiltre credenciales.
Nota sobre el Proyecto Siliceo: La arquitectura descrita (agentes en cápsula, tool calling con capability token, context-window audit log inmutable, fallback provider explícito en el kernel) refleja la implementación interna del Proyecto Siliceo (Silicea + Kernel Rust v2 + Memory Server persistente + Nova). El código, las policies OPA, las configuraciones kernel y los runbooks están versionados en el repositorio interno. No ofrecemos consultoría externa por el momento.
El prompt no es texto. Es una llave inglesa. La defensa no está en el modelo: está en la contención de la ejecución.