Seguridad on lo0 — Blog Técnico

Runbook: enjaular al agente de IA — bubblewrap en el cliente, Tetragon en el cluster

Tue, 09 Jun 2026 17:00:00 +0200

Compañero operativo de El contratista con la llave maestra. Aquel post explica el porqué y el dónde —el modelo de amenaza, las cinco familias de aislamiento, qué dominio usa cada una—; este es el cómo, con comandos. Si no lo has leído, léelo antes: aquí doy por sabido qué es el radio de explosión, por qué bwrap corre sin root y qué vigila Tetragon. El procedimiento va en dos tracks independientes —cliente y cluster— porque, como argumenta el post hermano, el control se extrapola pero la primitiva se reescribe.

TL;DR

Dos procedimientos reproducibles. Cliente (workstation): instala ai-jail (envuelve bubblewrap), genera el .ai-jail por proyecto, audita con --dry-run, fija las allowlists con --bootstrap, usa --lockdown para lo que no te fíes, y deja al agente sin permiso de git push. Cluster (RKE2 con Cilium + Tetragon): pon el baseline de pod (securityContext sin privilegios, seccomp: RuntimeDefault, NetworkPolicy default-deny), mete el pod del agente no confiable en una microVM con runtimeClassName: kata, y despliega las TracingPolicy de Tetragon en dos fases —observar con action: Post para levantar el baseline, luego promover a action: Sigkill sobre tcp_connect (egress) y security_file_open (rutas de secretos)—. La regla de oro de la fase Tetragon: adopta primero, bloquea después; nunca metas un Sigkill en producción sin haber visto antes los eventos en modo observación.

El flujo de los dos tracks

Track A — Cliente (workstation del desarrollador)

A0 — Instalar ai-jail y bubblewrap

ai-jail envuelve el sandbox; en Linux necesita bubblewrap aparte, en macOS no necesita dependencia extra.

# ai-jail (macOS y Linux)
brew tap akitaonrails/tap && brew install ai-jail
# o, con cargo:
cargo install ai-jail
# o, con mise:
mise use -g ubi:akitaonrails/ai-jail

# bubblewrap en Linux (elige tu distro)
sudo pacman -S bubblewrap # Arch
sudo apt install bubblewrap # Debian / Ubuntu
sudo dnf install bubblewrap # Fedora

Comprueba que el binario está y que bwrap corre sin root (no debe pedir sudo):

ai-jail --version
bwrap --ro-bind / / --unshare-all echo "bwrap ok sin root"

Si bwrap falla pidiendo privilegios, tu kernel tiene los unprivileged user namespaces deshabilitados; habilítalos (sysctl kernel.unprivileged_userns_clone=1 en Debian/Ubuntu antiguos) antes de seguir.

A1 — El fichero .ai-jail por proyecto

En el primer arranque dentro del proyecto, ai-jail crea un .ai-jail (TOML) commiteable al repo: cualquier compañero que clone hereda la misma política.

cd ~/Projects/mi-app
ai-jail claude # crea .ai-jail y lanza Claude Code dentro del sandbox

El fichero generado:

# .ai-jail — configuración del sandbox (commitéalo al repo)
command = ["claude"]
rw_maps = [] # directorios extra con escritura
ro_maps = [] # directorios extra de solo lectura

Antes de confiar en el sandbox, audítalo. --dry-run --verbose imprime cada punto de montaje, cada flag de aislamiento y el comando bwrap completo, sin ejecutar nada:

ai-jail --dry-run --verbose claude

Lee la salida y confirma tres cosas: que $HOME se monta como tmpfs (no el real), que ~/.ssh, ~/.aws y ~/.gnupg no aparecen entre los montajes, y que el único directorio con escritura es el del proyecto. Si necesitas un directorio extra:

ai-jail --rw-map ~/Projects/shared-lib claude # extra con escritura
ai-jail --map /opt/datasets claude # extra de solo lectura

Otros agentes, mismo binario:

ai-jail codex
ai-jail opencode
ai-jail bash # shell pelado para depurar el sandbox
ai-jail -- python script.py # cualquier comando

A2 — Las allowlists de permisos con –bootstrap

--bootstrap genera las configuraciones de permisos de cada agente, con allow/deny/ask sensatos, y hace backup antes de sobrescribir:

ai-jail --bootstrap

Lo que produce, en resumen:

Agente	Fichero	Política base
Claude Code	`~/.claude/settings.json`	allow: `git status/diff/log`, `ls`, `grep`, `cargo`, `npm`, `python`, `docker compose` · ask: `git push`, `rm`, `docker run` · deny: `rm -rf`, `sudo`, `chmod 777`, `git push --force`
Codex	`~/.codex/config.toml`	`approval_policy = "on-request"`
OpenCode	`~/.config/opencode/opencode.json`	permisos de `bash`, `edit`, `write`

La clave operativa: git push está en ask, no en allow, y git push --force en deny. El agente puede commitear, ramear y rebasar localmente cuanto quiera; nada de eso toca el remoto. (Si usas el /sandbox de Claude Code, fija además "allowUnsandboxedCommands": false para cerrar el escape hatch dangerouslyDisableSandbox, que de fábrica es opt-out.)

A3 — Lockdown para lo que no te fíes

Para auditar código de terceros o correr un agente sobre un proyecto que no conoces, --lockdown va más allá: proyecto montado en read-only, GPU/Docker/display deshabilitados, --rw-map/--map ignorados, $HOME tmpfs puro sin dotfiles del host, red cortada con --unshare-net y environment limpiado con --clearenv.

ai-jail --lockdown bash

Es el sandbox más restrictivo posible sin llegar a una VM. Úsalo como defecto mental para todo lo que no sea tu propio código en tu propia máquina.

A4 — La red de seguridad: git sin push

No es un flag, es una propiedad del entorno que cambia el cálculo de riesgo. Si el proyecto está en git con remoto, y el agente no tiene permiso de push, el peor caso —que corrompa cada fichero del proyecto— se revierte con:

git checkout . # vuelve al último commit
# y si tocó .git (improbable): borra el dir y re-clona

El remoto nunca se tocó. Sandbox para el filesystem + git para el código + push manual es ya un nivel razonable para uso diario: ai-jail protege tus datos y el sistema, git protege el código, y la decisión de publicar sigue siendo tuya.

Track B — Cluster (RKE2 con Cilium + Tetragon)

El agente no confiable —o la inferencia que ejecuta código generado— corre como pod. El mismo principio del cliente, otras primitivas. Asumimos un cluster genérico RKE2 con Cilium como CNI y Tetragon ya desplegado (el DaemonSet del agente eBPF en cada nodo).

B0 — El baseline del pod

Antes de cualquier eBPF, lo de serie. securityContext sin privilegios, raíz read-only, seccomp por defecto:

apiVersion: v1
kind: Pod
metadata:
 name: ai-agent
 namespace: agentes
 labels:
 app: ai-agent
spec:
 securityContext:
 runAsNonRoot: true
 runAsUser: 10001
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: agent
 image: registry.interno/ai-agent:pinned
 securityContext:
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 capabilities:
 drop: ["ALL"]
 volumeMounts:
 - { name: work, mountPath: /work }  # único escribible
 volumes:
 - name: work
 emptyDir: {}

Y el corte de egress por defecto —el gemelo cluster del --unshare-net—. NetworkPolicy default-deny de salida en el namespace, abriendo solo DNS y lo imprescindible:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: default-deny-egress
 namespace: agentes
spec:
 podSelector: {}
 policyTypes: ["Egress"]
 egress:
 - to:
 - namespaceSelector:
 matchLabels: { kubernetes.io/metadata.name: kube-system }
 ports:
 - { protocol: UDP, port: 53 }
 - { protocol: TCP, port: 53 }

B1 — RuntimeClass Kata: el pod no confiable en su propia microVM

Para código realmente no confiable, sácalo del kernel compartido. Con Kata desplegado existe un RuntimeClass:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
 name: kata
handler: kata

Y el pod lo pide con una línea —runtimeClassName: kata—, ejecutándose en su propia microVM con kernel dedicado en lugar de compartir el del nodo:

spec:
 runtimeClassName: kata  # ← el pod corre en una microVM, no en el kernel del nodo
 # ...resto igual que B0

Es el gemelo cluster del aislamiento por construcción: un exploit de kernel dentro del pod no alcanza al nodo.

B2 — Tetragon, fase observación (Post)

Ahora la capa que distingue una plataforma con visibilidad de runtime. Primero observar, nunca matar de entrada. Una TracingPolicyNamespaced —scoped al namespace y a la etiqueta del agente— que reporta (no mata) tres cosas: ejecuciones de proceso, conexiones de red y aperturas de rutas sensibles. action: Post solo emite el evento.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
 name: agente-observa
 namespace: agentes
spec:
 podSelector:
 matchLabels:
 app: ai-agent
 kprobes:
 # --- conexiones salientes ---
 - call: "tcp_connect"
 syscall: false
 args:
 - index: 0
 type: "sock"
 selectors:
 - matchActions:
 - action: Post
 # --- aperturas de ficheros sensibles ---
 - call: "security_file_open"
 syscall: false
 args:
 - index: 0
 type: "file"
 selectors:
 - matchArgs:
 - index: 0
 operator: "Prefix"
 values:
 - "/var/run/secrets"
 - "/work/.git/config"
 matchActions:
 - action: Post

(Las ejecuciones de proceso no necesitan kprobe: Tetragon emite process_exec/process_exit de forma nativa.) Despliega y observa los eventos en vivo desde el pod de Tetragon del nodo:

kubectl apply -f agente-observa.yaml
# eventos legibles, filtrando por el namespace:
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
 tetra getevents -o compact --namespace agentes

Deja esto rodando una jornada típica del agente. Apunta a qué destinos conecta de verdad (tu registry interno, tu mirror de HF, tu endpoint de vLLM) y qué rutas abre. Eso es tu baseline: la lista de lo legítimo. Sin este paso, un Sigkill mata trabajo bueno y te genera un incidente de disponibilidad —justo lo que el ENS te pide evitar—.

B3 — Tetragon, fase enforcement (Sigkill)

Con el baseline en la mano, promueve a bloqueo. Dos reglas. La primera: mata cualquier conexión cuyo destino no esté en la allowlist —NotDAddr invierte el match: dispara para todo lo que no sea esas redes—. La segunda: mata cualquier intento de abrir una ruta de secretos.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
 name: agente-enforce
 namespace: agentes
spec:
 podSelector:
 matchLabels:
 app: ai-agent
 kprobes:
 # --- egress: mata todo lo que NO sea la allowlist ---
 - call: "tcp_connect"
 syscall: false
 args:
 - index: 0
 type: "sock"
 selectors:
 - matchArgs:
 - index: 0
 operator: "NotDAddr"
 values:
 - "127.0.0.1"
 - "10.0.0.0/8" # red interna del cluster
 - "172.16.10.20" # registry interno (ejemplo)
 matchActions:
 - action: Sigkill
 # --- lectura de secretos: mata el proceso ---
 - call: "security_file_open"
 syscall: false
 args:
 - index: 0
 type: "file"
 selectors:
 - matchArgs:
 - index: 0
 operator: "Prefix"
 values:
 - "/var/run/secrets/kubernetes.io/serviceaccount/token"
 - "/work/.ssh"
 matchActions:
 - action: Sigkill

kubectl apply -f agente-enforce.yaml

Ahora el agente puede hacer lo que quiera dentro del pod, pero en el instante en que intenta conectar a un destino no permitido o leer el token de la service account, Tetragon lo mata en el kernel —antes de que el paquete salga o el read devuelva bytes—. Es el gemelo cluster de la blocklist de curl y del ~/.ssh no montado, pero aplicado en runtime y sobre cualquier binario, no solo los que conoces.

Aviso operativo. El enforcement con Sigkill requiere kernel reciente con soporte de la acción en eBPF (5.10+ es seguro). Despliega agente-enforce primero en un namespace de pruebas, y mantén agente-observa activo en paralelo: si el bloqueo dispara, el evento Post te dice exactamente qué lo provocó. Adopta primero, bloquea después.

La tabla de equivalencias cliente ↔ cluster

El mismo vector, las dos primitivas. Esto es “extrapolar la tecnología” hecho explícito:

Vector de amenaza	Cliente (workstation)	Cluster (RKE2)
`$HOME` / raíz escribible	`$HOME` como tmpfs efímero (`bwrap`)	`readOnlyRootFilesystem: true` + `emptyDir`
Egress arbitrario	blocklist `curl`/`wget` · `--unshare-net`	NetworkPolicy default-deny + Tetragon `NotDAddr`→`Sigkill`
Lectura de secretos	`~/.ssh`/`~/.aws`/`~/.gnupg` no montados	secretos fuera del pod + Tetragon `security_file_open`→`Sigkill`
Escape del kernel	Landlock (2ª barrera VFS)	`runtimeClassName: kata` (microVM, kernel propio)
Sin escape hatch	proceso dentro de `bwrap`, sin salida	sin `privileged`, `drop ALL`, `allowPrivilegeEscalation:false`
Daño al código	git remoto sin `push` → `git checkout .`	GitOps + revisión de PR, el agente no aplica a `main`
Visibilidad	`--dry-run --verbose` (estático, pre-run)	Tetragon `tetra getevents` (dinámico, en runtime)

Checklist de gotchas

No metas un Sigkill sin pasar por Post. El baseline de observación no es opcional: es lo que separa “bloquear un C2” de “tirar tu propio job de fine-tuning”.
El .ai-jail se commitea; los secretos no. El TOML es política, no credenciales. Verifica que no metes rutas con datos sensibles en rw_maps.
readOnlyRootFilesystem rompe apps que escriben en /tmp. Monta un emptyDir en /tmp además del de trabajo.
NetworkPolicy sin regla de DNS deja al pod ciego. Abre el puerto 53 a kube-system o nada resuelve.
Kata no es gratis. Añade latencia de arranque y no todo workload con dispositivos especiales (GPU passthrough) encaja; resérvalo para lo no confiable, no para todo.
El /sandbox de Claude Code no cubre MCP ni hooks salvo que actives sandbox-runtime. Si tu agente usa servidores MCP, asume que corren con permisos completos hasta que lo hagas.
NotDAddr con IPs literales envejece mal. Documenta la allowlist y revísala cuando cambie el registry o el endpoint de inferencia; considera CIDRs internos estables en vez de IPs sueltas.

Ver también

El contratista con la llave maestra: aislar agentes de IA del workstation al cluster — el panorama que este runbook ejecuta: modelo de amenaza, las cinco familias de aislamiento y por qué cliente y cluster usan primitivas distintas.
La puerta de la cocina que el maître no miró: Cilium eBPF y DRANET — la capa eBPF de Cilium sobre la que Tetragon engancha sus kprobes; el datapath que ya tienes en el cluster.
Controles técnicos: ENS × ISO 42001 × EU AI Act — los eventos de Tetragon como evidencia técnica de op.mon/op.exp; el enforcement como medida de protección.
Guardrails y safety en LLM — la mitigación en el plano del contenido; este runbook, la del plano de la ejecución.
Siete fases de despliegue de una plataforma LLM on-premise — dónde encaja el endurecimiento de runtime en la secuencia de despliegue (F4 identidad/políticas, F5 plataforma).

Referencias

ai-jail (Fabio Akita), GPL-3.0: https://github.com/akitaonrails/ai-jail
bubblewrap: https://github.com/containers/bubblewrap
Landlock LSM: https://landlock.io
Tetragon — TracingPolicy: https://tetragon.io/docs/concepts/tracing-policy/
Tetragon — enforcement (Sigkill/Override): https://tetragon.io/docs/concepts/enforcement/
Kata Containers — Kubernetes RuntimeClass: https://katacontainers.io
Kubernetes — Pod Security & seccomp: https://kubernetes.io/docs/tutorials/security/seccomp/
Kubernetes — Network Policies: https://kubernetes.io/docs/concepts/services-networking/network-policies/
Cilium: https://cilium.io

El contratista con la llave maestra: aislar agentes de IA del workstation al cluster

Tue, 09 Jun 2026 16:00:00 +0200

Primer post de una pareja sobre aislamiento de agentes de IA. Este fija el qué y el dónde: el mapa completo de primitivas de aislamiento y a qué dominio pertenece cada una. El runbook hermano fija el cómo, con comandos: ai-jail y bubblewrap en el cliente, TracingPolicy de Tetragon y RuntimeClass en el cluster. Si solo vas a leer uno, este te da el modelo mental; el otro, los ficheros que se copian y pegan.

TL;DR

Un agente de IA que ejecuta código necesita acceso a tu filesystem y a tus herramientas: compilador, linter, grep, make, cargo, npm. Ese es el mínimo para ser útil. El problema es que junto a ese acceso viaja la capacidad de leer ~/.aws/credentials, exfiltrar tus claves SSH o lanzar un rm -rf fuera del directorio del proyecto. Y no hace falta un modelo malicioso: basta una dependencia comprometida en un npm install, porque el agente bienintencionado y el post-install script envenenado corren con los mismos permisos. La respuesta no es confiar en las buenas intenciones del LLM; es aislar para acotar el radio de explosión. Este post recorre las cinco familias de aislamiento de 2026 —del sandbox de proceso a la VM completa— y las reparte en dos columnas: lo que aplica en el cliente (el workstation del desarrollador: bubblewrap, ai-jail, sandbox-exec, Landlock, los sandboxes nativos de Claude Code y Codex) y lo que aplica en el cluster (donde el agente o la inferencia corren en Kubernetes: namespaces+seccomp, gVisor, microVMs Firecracker/Kata y eBPF/Tetragon como capa de observación y enforcement en caliente). La tesis: el modelo de amenaza es el mismo en los dos sitios; las herramientas, no. La política se extrapola; la primitiva se reescribe.

La analogía: el contratista con la llave maestra

Contratas a un operario para una reforma. Es competente y va de buena fe. Pero pasan dos cosas que no controlas. La primera: puede malinterpretar la orden y tirar el tabique equivocado. La segunda, peor: su caja de herramientas pudo manipularse antes de que entrara por tu puerta —alguien metió algo dentro—, y cuando la abre en tu salón, ese algo se activa.

Nadie sensato le da la llave maestra del edificio entero. Le abres la habitación donde trabaja, le dejas las herramientas que necesita, y mantienes cerrados el despacho con la caja fuerte y el cuarto de los servidores. Si la reforma sale mal —por error o por sabotaje—, el daño se queda en esa habitación.

Un agente de IA es ese contratista. El sandbox es la política de llaves: le das la habitación del proyecto y las herramientas, no la llave maestra del sistema. Y aquí está el giro que justifica dos posts: el operario trabaja en dos edificios distintos. Uno es tu piso —el workstation del desarrollador, con tus credenciales, tu ~/.ssh, el baúl de contraseñas del navegador—. El otro es el centro de datos —el cluster donde la inferencia y los agentes autónomos sirven a clientes, con datos de varios inquilinos a la vez—. La política de llaves es idéntica en los dos: principio de mínimo privilegio, acota el radio. Pero la cerradura de la puerta de tu piso no es la misma que la del centro de datos. En el piso pones un bombín (bubblewrap). En el centro de datos pones un guardia que vigila cada puerta y un ala separada del edificio (Tetragon + microVM). Mismo principio, distinta ferretería. Eso es extrapolar la tecnología, no copiarla.

El modelo de amenaza: qué puede hacer un agente desbocado

Antes de elegir cerradura conviene enumerar al ladrón. La superficie de ataque de un agente que ejecuta bash arbitrario se descompone en cinco amenazas concretas. No todas se defienden con la misma capa, y —dato incómodo que la propia documentación de seguridad reconoce— ninguna capa las cubre todas.

Amenaza	Qué hace el agente	Capa mínima que la corta
Filesystem fuera de alcance	Lee `.env`, `~/.ssh/id_rsa`, secretos del sistema; modifica fuentes fuera del proyecto	Sandbox de proceso (allowlist de rutas)
Egress de red arbitrario	Exfiltra datos, recibe instrucciones de un C2 remoto, llama APIs sin autorizar	Bloqueo de red / NetworkPolicy / microVM
Superficie de syscalls del kernel	Un exploit del kernel desde el contenedor escala al host (kernel compartido)	gVisor o microVM (kernel dedicado)
Fuga entre inquilinos	El workload de un cliente lee datos de otro en una plataforma multi-tenant	microVM (estándar de facto)
Exfiltración de secretos	Saca tokens y variables de entorno vía `/proc` o el environment	`--clearenv` / tmpfs de `$HOME` / secretos fuera del pod

Hay una sexta amenaza que ningún sandbox resuelve: el prompt injection. Si un atacante consigue colar instrucciones en el contexto del agente —un comentario envenenado en el código, un fichero malicioso que el agente lee, una respuesta adversaria de una herramienta—, el agente ejecutará esas instrucciones con los permisos que el sandbox le conceda. El aislamiento encoge el radio de impacto de una inyección exitosa; no impide la inyección. Por eso el sandbox es una capa, no la solución: encima van validación de entrada, allowlists de tool-calls y auditoría de salida. La frase a interiorizar: el aislamiento no hace al agente confiable; acota lo que un agente no confiable puede romper.

Dos dominios, una política

El operario trabaja en dos edificios. El reparto de herramientas se ve mejor a dos columnas:

El cliente: aislar al agente en el workstation

Aquí el agente es un asistente de coding —Claude Code, Codex, OpenCode, Cursor— que un desarrollador lanza en su máquina. Un proceso, un usuario, y al lado los activos más jugosos que existen: ~/.aws/credentials, ~/.ssh, ~/.gnupg, el almacén de contraseñas del navegador. El tier que corresponde es el más ligero: el sandbox de proceso.

bubblewrap (Linux) y sandbox-exec (macOS). bubblewrap (bwrap) es el mismo sandbox que usa Flatpak para aislar cada app de escritorio: ~50 KB de binario, ~4.000 líneas de C, mantenido por el equipo de GNOME, y —la propiedad clave— corre sin root vía CLONE_NEWUSER, creando namespaces sin privilegios elevados. Monta $HOME como un tmpfs efímero y solo expone, con escritura, el directorio del proyecto; el resto del sistema se vuelve invisible. En macOS el equivalente es sandbox-exec con perfiles SBPL: API legacy de Apple, oficialmente deprecada y sin reemplazo público, pero funciona hoy. La paridad entre las dos no es exacta —en macOS la GPU (Metal) y el display (Cocoa) son de sistema y sandbox-exec no los restringe—, pero ambas protegen lo que importa: el acceso a las zonas sensibles del filesystem.

Landlock como segunda barrera. bubblewrap aísla por namespaces y montajes; Landlock —un Linux Security Module disponible desde el kernel 5.13— restringe el acceso a nivel VFS, independiente de los namespaces. No reemplaza a bwrap: lo complementa. Cierra vectores que el aislamiento por montaje no cubre por sí solo (rutas de escape vía /proc, trucos con symlinks dentro de montajes permitidos) y actúa de red de seguridad si la maquinaria de namespaces tuviera un bug. Es defensa en profundidad dentro del propio cliente, y degrada limpiamente a no-op en kernels que no lo soportan.

Dev containers, cuando hace falta reproducibilidad. Un dev container (devcontainer.json, lo que usan Codespaces y Cursor) es un contenedor Docker con una capa de configuración encima. Da aislamiento de filesystem razonable y reset fácil (destruir y recrear), pero comparte el kernel del host —misma limitación que cualquier Docker— y tiende a ser de larga vida, acumulando estado. Para un agente que ejecuta código de tu propio equipo, en tu máquina, es un buen relato de repetibilidad; no es la capa de aislamiento para código no confiable por sí solo.

Lo que envuelve todo esto. El script de bash a mano funciona, pero no escala a un equipo. Las herramientas que lo empaquetan:

ai-jail (Rust, GPL-3.0): envuelve bwrap/sandbox-exec con config por proyecto en un fichero .ai-jail (TOML, commiteable al repo, de modo que todo el equipo hereda la misma política), auto-detección de GPU/Docker/display, modo --lockdown (proyecto en read-only, red cortada con --unshare-net, --clearenv), --dry-run para auditar, y --bootstrap para generar las allowlists de permisos de cada agente. Es agnóstico de la herramienta: el mismo binario sirve para Claude, Codex, OpenCode o Crush. Aplica además Landlock automáticamente en kernels 5.13+ como defensa en profundidad.
El /sandbox de Claude Code: desde octubre de 2025, Claude Code trae sandbox propio que usa —exactamente— bubblewrap en Linux y sandbox-exec en macOS. Su Sandboxed Bash aísla los comandos de shell, pero no las herramientas de fichero, los servidores MCP ni los hooks, que corren con los permisos completos del proceso salvo que actives el paquete beta sandbox-runtime, que envuelve el proceso entero. Hay un matiz que conviene conocer: si un comando falla por una restricción, el agente puede reintentar con dangerouslyDisableSandbox —es opt-out, no opt-in—.
Codex CLI: tres modos vía --sandbox (read-only, workspace-write, danger-full-access); el recomendado por defecto es workspace-write. La filosofía es deliberada: Codex no provee el aislamiento, lo delega al entorno que lo envuelve. danger-full-access solo tiene sentido dentro de una microVM.
Cursor: sus cloud agents corren en VMs aisladas; /worktree crea un worktree aislado de un solo uso por tarea, y /best-of-n lanza varios intentos en paralelo en worktrees separados.

El cluster: aislar al agente en producción

El segundo edificio es el centro de datos. Aquí el “agente” puede ser un agente autónomo que corre sin un humano delante, o el propio servicio de inferencia ejecutando código generado, o un workload multi-tenant donde el pod de un cliente no debe tocar los datos de otro. El proceso ya no es uno: son pods en un cluster Kubernetes (RKE2/RKE3 en una plataforma soberana típica). Las primitivas cambian de naturaleza.

El baseline del pod. Antes de nada, lo de serie: namespaces de Linux, seccomp (RuntimeDefault) para recortar la superficie de syscalls, cgroups para los límites de recursos, securityContext sin privilegios (runAsNonRoot, readOnlyRootFilesystem, drop de todas las capabilities) y NetworkPolicy para cortar el egress. Es el equivalente cluster de la allowlist del sandbox de proceso. Necesario, pero comparte kernel con el host: insuficiente para código realmente no confiable.

gVisor (runsc). El kernel en espacio de usuario de Google: intercepta las syscalls del workload antes de que lleguen al kernel del host y las atiende dentro de un kernel Linux reimplementado en Go (el Sentry). La superficie expuesta a vulnerabilidades del kernel del host se reduce drásticamente, manteniendo arranque rápido y footprint bajo. Es el término medio cuando el riesgo de escape de kernel es real pero el overhead de una microVM no es asumible.

microVMs Firecracker / Kata. El estándar de facto para código no confiable en 2026. Firecracker (VMM de AWS en Rust, sobre KVM) da a cada sandbox un kernel Linux dedicado: un exploit de kernel dentro de la microVM no alcanza al host por construcción. Es lo que hay debajo de Vercel Sandbox (GA enero 2026) y E2B. En Kubernetes, Kata Containers trae ese modelo a un RuntimeClass: marcas el pod del agente no confiable con runtimeClassName: kata y se ejecuta en su propia microVM en lugar de compartir el kernel del nodo. Para multi-tenant con código generado, esto es el baseline, no el lujo.

eBPF / Tetragon: la capa que ya tenemos. Aquí está la pieza que distingue una plataforma con observabilidad de runtime de una que solo confía en la configuración. Las capas anteriores son estáticas: definen lo que el pod puede hacer antes de arrancar. Tetragon —el componente de seguridad runtime de Cilium, basado en eBPF— es dinámico: observa, en el kernel y con coste mínimo, cada ejecución de proceso, cada conexión de red y cada apertura de fichero de cada pod, y puede actuar en línea. No reemplaza al sandbox; lo vigila desde dentro del kernel. Donde bubblewrap en el cliente bloquea curl con una blocklist de comandos, Tetragon en el cluster engancha tcp_connect en el kernel y, si el destino no está permitido, mata el proceso con Sigkill antes de que el paquete salga. Donde el cliente esconde ~/.ssh tras un tmpfs, Tetragon engancha security_file_open y reporta —o mata— cualquier intento de leer una ruta sensible montada. Es el guardia que recorre los pasillos mientras las microVMs son las paredes. Y es, exactamente, el tipo de control que materializa las medidas de monitorización y trazabilidad del ENS (op.mon, op.exp) sin instrumentar la aplicación: la visibilidad vive en el kernel, no en el código del agente.

La tabla del panorama

Las cinco familias, su fortaleza relativa de aislamiento, su coste de arranque y el dominio donde viven:

Tier	Primitiva	Aislamiento	Arranque	Dominio natural
Sandbox de proceso	Seatbelt · bubblewrap	Baseline	~0 ms	Cliente (defecto de Claude Code)
Dev container	Docker + seccomp	Moderado	segundos	Cliente / cluster (repetibilidad)
Kernel user-space	gVisor (`runsc`)	Fuerte	ms	Cluster (multi-tenant medio)
microVM	Firecracker · Kata	El más fuerte (práctico)	<1 s	Cluster (código no confiable)
VM completa	KVM · EC2	Máximo	30 s+	Cluster (frontera externa, compliance)
Runtime enforcement	eBPF · Tetragon	Transversal	siempre activo	Cluster (observa+mata sobre cualquier tier)

Tetragon ocupa una fila aparte a propósito: no es un tier en la escalera, es una capa transversal que opera sobre cualquiera de los otros. Se apila con todos.

Un apunte numérico sobre por qué la columna “arranque” decide tanto como la columna “aislamiento”. Una VM completa gana en aislamiento bruto pero tarda decenas de segundos en provisionarse; para un agente que necesita un entorno fresco por petición o por sesión, ese coste es prohibitivo. Una microVM Firecracker arranca en menos de 1 segundo y un sandbox de proceso en ~0 ms. Por eso el patrón dominante en 2026 no es “la VM más aislada”, sino VM completa como frontera externa + microVM como unidad de ejecución por petición dentro —la arquitectura de Vercel, AWS Lambda y E2B—. En el cliente el cálculo es el opuesto: el desarrollador lanza el agente decenas de veces al día de forma interactiva, y un arranque de segundos rompería el flujo; de ahí que el sandbox de proceso, con su overhead de microsegundos, sea el defecto correcto.

Extrapolar, no copiar

La tesis de la pareja de posts cabe en una frase: el modelo de amenaza es invariante entre dominios; la primitiva que lo implementa, no. El cliente y el cluster defienden exactamente los mismos cinco vectores —filesystem, red, kernel, multi-tenant, secretos—, pero con cajas de herramientas que no se solapan. Cada control tiene su gemelo en el otro lado:

$HOME como tmpfs efímero (cliente) ↔ readOnlyRootFilesystem + emptyDir (cluster).
Blocklist de curl/wget en bwrap (cliente) ↔ TracingPolicy sobre tcp_connect en Tetragon + NetworkPolicy (cluster).
--unshare-net en lockdown (cliente) ↔ NetworkPolicy default-deny (cluster).
Sin escape hatch, el proceso vive dentro de bwrap (cliente) ↔ sin privileged, sin hostPath, RuntimeClass kata (cluster).
~/.ssh y ~/.aws nunca montados (cliente) ↔ secretos fuera del pod + Tetragon vigilando security_file_open (cluster).

El runbook hermano convierte cada una de estas equivalencias en ficheros concretos. Lo que importa retener aquí es el método: cuando alguien te enseña un sandbox de agente —sea el /sandbox de Claude Code en un portátil o un microVM en un PaaS—, la pregunta útil no es “¿qué herramienta usa?”, sino “¿cuál de los cinco vectores cierra, y cuál deja abierto?”. La herramienta se sustituye; el mapa de amenazas se queda.

Lo que ningún sandbox resuelve

Tres límites que la propia documentación de Anthropic enuncia, y que conviene tener delante para no vender humo:

El egress sigue siendo un riesgo en cualquier sandbox que permita conexiones salientes. Si el agente puede abrir una conexión, puede exfiltrar. Por eso el lockdown del cliente corta la red y el cluster usa NetworkPolicy default-deny + Tetragon: no se confía en “filtrar bien”, se confía en “no dejar salir”.
La modificación de código sigue siendo posible en cualquier sandbox con el directorio del proyecto montado en escritura. El remedio no es técnico-de-sandbox, es git: con el remoto intacto y sin permiso de push, el peor caso es corromper el working copy local —git checkout . y a empezar—. El daño no llega al remoto.
Ningún sandbox impide que un prompt comprometido llegue a la API. El aislamiento acota el impacto de una inyección; no la previene. Las defensas complementarias —validación de entrada, allowlists de tool-calls, auditoría de salida— son obligatorias junto al aislamiento, no en su lugar.

La conclusión operativa: el aislamiento encoge el radio de explosión; la defensa en profundidad es lo que cierra el círculo. Un sandbox de proceso para código de confianza en una máquina conocida es apropiado y prácticamente gratis. Para un agente que actúa sobre prompts de usuario, ejecuta código generado o corre en multi-tenant, el mínimo aceptable en 2026 es una microVM, con Tetragon observando por encima. Elige el tier que case con tu amenaza real, verifica qué vector deja abierto, y apila controles complementarios encima.

Ver también

Runbook: enjaular al agente de IA — bubblewrap en el cliente, Tetragon en el cluster — el compañero operativo de este post: los ficheros .ai-jail, el --bootstrap de permisos y las TracingPolicy de Tetragon que se copian y pegan. Con comandos.
La puerta de la cocina que el maître no miró: NUMA de red, Cilium eBPF y DRANET — el datapath eBPF de Cilium sobre el que se apoya Tetragon en el cluster; la misma capa de kernel, otro uso.
Guardrails y safety en LLM — la mitigación en el plano del contenido (qué dice y qué se le dice al modelo); este post es la mitigación en el plano de la ejecución (qué puede hacer el proceso del agente).
Controles técnicos: ENS × ISO 42001 × EU AI Act — el marco de cumplimiento que el aislamiento de runtime materializa: Tetragon como evidencia técnica de op.mon/op.exp.
Catálogo de herramientas OSS para LLMOps — dónde encaja la capa de seguridad runtime en el stack abierto completo.

Referencias

bubblewrap: https://github.com/containers/bubblewrap
Landlock LSM: https://landlock.io · https://docs.rs/landlock
ai-jail (Fabio Akita): https://github.com/akitaonrails/ai-jail
gVisor: https://gvisor.dev
Firecracker: https://firecracker-microvm.github.io
Kata Containers: https://katacontainers.io
Tetragon (Cilium): https://tetragon.io
Vercel Sandbox — concepts: https://vercel.com/docs/vercel-sandbox/concepts
E2B: https://github.com/e2b-dev/E2B
Claude Code sandboxing: https://docs.claude.com/en/docs/claude-code
Codex CLI: https://github.com/openai/codex