Anthropic documenta cómo aísla Claude en sus productos

Uno de los problemas crónicos en el mundo del software de sandboxing es que los productos rara vez documentan con detalle cómo funcionan sus mecanismos de aislamiento. Sin documentación, la confianza que depositas en ellos es, en el mejor caso, fe ciega. Eso es exactamente lo que Simon Willison señalaba en su blog el 30 de mayo, al destacar que Anthropic acaba de publicar una excepción notable a esa norma.

El equipo de ingeniería de Anthropic ha publicado una visión general técnica de cómo contienen a Claude en sus tres entornos principales: Claude.ai, Claude Code y Claude Cowork. El documento no es un whitepaper académico ni un comunicado de relaciones públicas: es una descripción funcional de las capas de aislamiento que aplican y por qué las han elegido.

Qué técnica usa cada producto

Las diferencias entre entornos son significativas, y responden a contextos de ejecución muy distintos:

• Claude.ai utiliza gVisor, el kernel en espacio de usuario de Google, para aislar los procesos del servidor sin necesidad de una VM completa. Es una solución probada en entornos de producción a escala.
• Claude Code, que corre localmente en la máquina del usuario, emplea Seatbelt en macOS y Bubblewrap en Linux. Ambos son mecanismos de sandboxing nativos de cada sistema operativo, lo que tiene sentido cuando el runtime es el propio equipo del desarrollador.
• Claude Cowork, el entorno de trabajo colaborativo, va un paso más allá y levanta una VM completa: el framework de virtualización de Apple en macOS y HCS (Host Compute Service) en Windows.

La lógica que subyace a todo esto la resume el propio documento de Anthropic con claridad:

> Constrain where and how an agent can act with process sandboxes, VMs, filesystem boundaries, and egress controls. The goal is to set a hard boundary on what an agent can reach. For example, if credentials never enter the sandbox, they can't be exfiltrated, regardless of whether the cause is a user, a model finding a "creative" path, or an attacker.

En español: si las credenciales nunca entran en el sandbox, no pueden salir de él, independientemente de si el vector es un usuario, el propio modelo o un atacante externo. El diseño parte de asumir que el fallo puede venir de cualquier dirección.

Por qué importa ahora

Esta publicación llega en un momento en que los agentes de Claude Code —con capacidad para ejecutar comandos, leer sistemas de ficheros y llamar a herramientas externas vía MCP servers— se están desplegando en entornos de producción reales. La pregunta de qué puede y qué no puede hacer un agente autónomo en un sistema ya no es teórica.

El modelo de amenaza que describe Anthropic es relevante precisamente porque contempla escenarios que los equipos de seguridad han empezado a tomarse en serio: prompt injection desde fuentes externas, comportamiento inesperado del modelo al explorar caminos "creativos", y ataques deliberados contra el agente como vector de acceso. Cubrir las tres superficies con controles en capas —proceso, filesystem, red— es una aproximación sensata.

Para quién es útil esta información

Los equipos que integran Claude Code en flujos de CI/CD o que construyen agentes sobre la API de Anthropic son los que más se benefician de este nivel de transparencia. Saber qué hace Seatbelt o Bubblewrap por defecto, y qué límites de red aplica Anthropic en sus entornos gestionados, permite tomar decisiones informadas sobre qué trabajo delegar al agente y qué mantener fuera de su alcance.

También es útil para quienes evalúan Claude Cowork en entornos corporativos: el hecho de que levante una VM completa, en lugar de depender solo de un sandbox a nivel de proceso, responde directamente a las objeciones habituales de los equipos de seguridad empresarial.

---

Desde EP, la valoración es sencilla: que Anthropic publique esto no garantiza que el sandboxing sea perfecto, pero sí que puedes auditarlo, cuestionarlo y exigir mejoras concretas. Eso ya es bastante más de lo que ofrece la mayoría de productos comparables.