El aislamiento tiene capas. Sabe cuál aplica.

Módulo 2 · Instalación y entornos · Lección 4 de 5

Cuando el equipo de seguridad de TI de un cliente pregunta a qué puede acceder Claude Code, la respuesta depende de qué límite de aislamiento está en vigor. Esta lección cubre las opciones de aislamiento, qué abarca cada una y cómo configurarlas, para que puedas responder cuestionarios de seguridad con precisión, no con optimismo.

El caso de seguridad: el aislamiento tiene capas. «Está en un sandbox» no es una respuesta de seguridad completa.

En los proyectos empresariales, la pregunta sobre qué puede acceder Claude Code (y qué no) aparecerá en la revisión de seguridad. La respuesta correcta no es «está en sandbox»; es «depende de qué capa de aislamiento esté en vigor».

Claude Code ofrece varias opciones de aislamiento, y cada una cubre superficies de acceso distintas. El sandbox Bash integrado restringe los subprocesos de Bash y los procesos hijos, pero no restringe las herramientas de archivos integradas de Claude Code, los servidores MCP, los hooks ni el acceso web. Esas superficies requieren aislamiento adicional: un sandbox runtime, un dev container o una VM. Cuando TI pregunta «¿a qué puede acceder Claude Code?», la respuesta honesta es: «depende del límite de aislamiento que configuremos». De eso trata esta lección.

Superficie de acceso	Sandbox Bash integrado	Sandbox runtime	Contenedor / VM
Comandos bash	✓ Restringido	✓ Restringido	✓ Restringido
Herramientas de archivos (Read/Write)	✗ Acceso completo	✓ Restringido	✓ Restringido
Servidores MCP	✗ Acceso completo	✗ Acceso completo	✓ Restringido
Hooks	✗ Acceso completo	✗ Acceso completo	✓ Restringido
Acceso web	✗ Acceso completo	✓ Restringido	✓ Restringido

En las revisiones de seguridad de TI, especifica qué límite de aislamiento está en uso, no solo «sandbox».

flowchart TB
  subgraph VM["Contenedor de desarrollo o VM (capa externa)"]
    subgraph SBX["Sandbox de Claude Code (capa interna)"]
      BASH["Comandos bash"]
      FILES["Herramientas de archivos y acceso web"]
    end
    MCP["Servidores MCP y hooks"]
  end

Los controles: cuatro propiedades del modelo de sandboxing de Claude Code

Cada una de estas propiedades es un argumento en la conversación del cuestionario de seguridad y una decisión de configuración antes del despliegue.

1. Acotamiento de directorios (directory scoping)

Claude Code puede restringirse a directorios concretos. No puede leer ni escribir fuera del ámbito definido. Para un desarrollador que trabaja en un directorio de proyecto, esto significa que Claude Code se queda dentro del proyecto. No puede acceder al directorio personal del desarrollador, a otras bases de código ni a archivos del sistema, salvo que se permita explícitamente.

2. Lista blanca de red (network allowlisting)

Las solicitudes de red salientes de Claude Code pueden limitarse a una lista blanca definida de hosts. Los intentos de alcanzar endpoints fuera de la lista se bloquean. Es especialmente relevante en sectores regulados donde los controles contra la fuga de datos forman parte de la postura de seguridad.

3. Operación sin aprobación dentro de los límites

Las operaciones dentro del sandbox definido continúan sin interrumpir al desarrollador para confirmar. Esto preserva el beneficio de productividad: los desarrolladores no aprueban cada lectura de archivo ni cada comando de shell, mientras el alcance de la acción autónoma queda explícitamente acotado.

4. Notificación de operaciones fuera del sandbox

Cuando Claude Code intenta una operación fuera del límite del sandbox, lo muestra en lugar de fallar en silencio o escalar en silencio. El desarrollador ve lo que se intentó y puede decidir si amplía el sandbox o redirige el enfoque. Es la propiedad de transparencia: es lo que hace que el límite sea significativo en lugar de opaco.

Configuración: los ajustes de sandbox viven en settings.json, con tres grupos de campos que conocer

Los controles de sandbox se configuran de forma declarativa. Un ejemplo mínimo funcional cubre la mayoría de los requisitos empresariales en menos de 20 líneas.

La configuración del sandbox de Claude Code se gestiona a través de settings.json, ya sea a nivel de usuario (~/.claude/settings.json) o desplegada mediante managed settings para un equipo. Tres grupos de campos hacen el trabajo: sandbox (aislamiento de procesos y límites del sistema de archivos), permissions (reglas de permiso a nivel de herramienta) y network (lista blanca de dominios salientes). Esta es una configuración mínima que cubre un requisito típico de endurecimiento empresarial:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["/"],
      "allowRead": ["/project", "~/.claude"],
      "allowWrite": ["/project"]
    },
    "network": {
      "allowedDomains": [
        "api.anthropic.com",
        "*.client-internal.com"
      ]
    }
  },
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint)",
      "Read(/project/**)"
    ],
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(~/.ssh/**)"
    ],
    "defaultMode": "acceptEdits"
  }
}

Campos clave que conocer para la conversación del cuestionario de seguridad:

• sandbox.filesystem.denyRead / allowRead: define el límite de directorios. Deniega la raíz y después vuelve a permitir el directorio del proyecto. Esto es lo que te permite decir al equipo de seguridad «no puede leer tus claves SSH» en lugar de «probablemente no lo hará».
• sandbox.network.allowedDomains: lista blanca de dominios salientes. Se admiten comodines (*.client-internal.com). Configúralo para aplicar la política de salida en lugar de depender solo de las reglas de firewall.
• permissions.deny: reglas de denegación a nivel de herramienta. Bloquean patrones concretos de bash (curl *) o el acceso a archivos (Read(./.env)). Estas reglas no pueden ser sobrescritas por la configuración local cuando se despliegan en managed settings.
• permissions.defaultMode: modo de permisos por defecto al iniciar. Opciones: default, acceptEdits, plan, auto. Usa acceptEdits para equipos que quieren que las ediciones se aprueben automáticamente mientras siguen confirmando los comandos de bash.

Dev containers: ejecutar Claude Code dentro de un contenedor añade un límite externo al interno

Un dev container es el complemento natural de la configuración de sandbox para clientes empresariales que quieren entornos de desarrollo reproducibles y aislados.

Cuando Claude Code se ejecuta dentro de un dev container, el propio contenedor proporciona una segunda capa de aislamiento. El sistema de archivos, la red y el alcance de procesos quedan acotados por la definición del contenedor antes de que se apliquen los controles de sandbox de Claude Code. Para los equipos de seguridad del cliente, es una respuesta sólida a las preguntas sobre aislamiento: tanto la herramienta como el entorno están limitados. Anthropic ofrece una feature oficial de dev container que se encarga de la instalación de Claude Code automáticamente.

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

La versión de la feature fija el script de instalación, no la versión de Claude Code. Claude Code se actualiza automáticamente dentro de los contenedores por defecto, salvo que la actualización automática se desactive mediante DISABLE_AUTOUPDATER. Para entornos con políticas de versiones fijadas, establece esta variable explícitamente. La documentación completa de devcontainer está en code.claude.com/docs/en/devcontainer.

Artefacto del curso: Installation Configuration Pack (sección de configuración)

Esta lección aporta la sección de configuración del Installation Configuration Pack: el alcance del sandbox, los controles de red y el método de autenticación que requiere el entorno del cliente.

1. Documenta la configuración del sandbox: alcance del sistema de archivos, dominios de red permitidos y cualquier herramienta denegada. Un bloque de configuración por entorno de despliegue: desarrollo, staging y producción pueden diferir.
2. Registra el método de autenticación en uso: OAuth, clave de API o SSO mediante SAML/SCIM, y cualquier configuración de proxy. El equipo de TI lo pedirá antes de aprobar el despliegue.
3. Anota qué capa de aislamiento aplica: sandbox Bash, sandbox runtime o contenedor/VM. La elección determina tanto la sintaxis de la configuración como las respuestas al cuestionario de seguridad.

Comprueba tu comprensión

Escenario: el cuestionario de seguridad.

Estás en una llamada con el responsable de seguridad de TI del cliente, revisando el plan de despliegue de Claude Code.

El responsable de seguridad pregunta: «¿Podría un desarrollador configurar Claude Code por error para leer archivos fuera de su directorio de proyecto, por ejemplo sus claves SSH o credenciales en su carpeta personal?» ¿Qué le respondes?

• A. No; Claude Code solo lee los archivos de la pestaña activa. Claude Code está limitado a lo que está abierto en el IDE, así que no puede acceder a otras partes del sistema de archivos.
• B. Con reglas de denegación explícitas configuradas, no; lo verificamos antes del despliegue. Las reglas de denegación para rutas sensibles se configuran en la configuración de permisos, el sandbox de Bash restringe los comandos de shell y la configuración se prueba antes del rollout. La configuración activa, no el comportamiento por defecto, es lo que cierra el cuestionario de seguridad.
• C. Sí, a menos que el desarrollador lo ejecute con permisos restringidos. El acceso a archivos no está restringido por defecto y debe bloquearse manualmente mediante permisos a nivel de sistema operativo.

Ver respuesta

Correcta (direccionalmente): B. Las opciones A y C son incorrectas.

B es direccionalmente correcta, pero el encuadre importa para un equipo de seguridad. «Por defecto no» no es una respuesta segura para un cuestionario de seguridad; implica una seguridad pasiva. Los equipos de seguridad necesitan configuración activa. La respuesta adecuada para el responsable de seguridad es: «Configuramos reglas de denegación explícitas para rutas sensibles como ~/.ssh/**, activamos el sandbox de Bash para restringir los comandos de shell y verificamos estas reglas antes del despliegue. El acceso se rige por configuración activa, no por el comportamiento por defecto.» Ese es el paso de «probablemente no lo hará» a «lo imponemos y comprobamos que no puede». Ten en cuenta también que el sandbox Bash integrado cubre los comandos de bash; el acceso de las herramientas de archivos a las claves SSH requiere una regla explícita permissions.deny o una capa de aislamiento más amplia (contenedor/VM). Confirma qué capa está en uso antes de afirmar que el límite existe.

Ideas clave

Al terminar esta lección puedes especificar qué límite de aislamiento está en vigor, configurar los controles del sandbox, plantear con precisión la conversación del cuestionario de seguridad y construir una especificación de dev container con la feature oficial de Anthropic.

• «Está en sandbox» no basta: especifica qué capa de aislamiento aplica (sandbox Bash, sandbox runtime o contenedor/VM), porque cada una cubre superficies distintas.
• El sandbox Bash integrado no restringe las herramientas de archivos, los servidores MCP, los hooks ni el acceso web; esas superficies requieren un sandbox runtime o un contenedor/VM.
• Los cuatro controles del sandbox son el acotamiento de directorios, la lista blanca de red, la operación sin aprobación dentro de los límites y la notificación de operaciones fuera del sandbox.
• La configuración se declara en settings.json (sandbox, permissions y network); las reglas deny no pueden sobrescribirse localmente cuando se despliegan en managed settings.
• Un dev container añade un límite externo que acota el sistema de archivos, la red y los procesos antes de aplicar los controles de Claude Code.

Siguiente: Modo headless y CI