Claude Code ejecuta bash, y el sandbox lo mantiene seguro

Módulo 6 · Seguridad y gobernanza · Lección 3 de 6

Al terminar esta lección podrás configurar los límites de sistema de archivos y de red para el despliegue de un cliente, y explicar por qué el sandbox habilita la operación autónoma en lugar de limitarla.

Qué hace el sandbox

El sandbox define lo que Claude Code puede tocar. Sin él, no es seguro autorizar la operación autónoma.

1. Definir límites

Delimita explícitamente qué directorios y hosts de red son accesibles. No hay ambigüedad sobre lo que el agente puede alcanzar durante una tarea autónoma.

En la práctica: las claves del sandbox que verás a continuación, bajo sandbox.filesystem y sandbox.network, son la forma en que esos límites se escriben y se aplican.

2. Reducir los avisos de aprobación

Cuando el alcance está claro, Claude opera dentro de él sin interrumpir constantemente. Un sandbox bien acotado significa menos preguntas, no más.

Lo contraintuitivo: acotar bien aumenta la autonomía. Dentro de un límite de confianza no hay nada que preguntar, así que los avisos que quedan son los que importan.

3. Contener los fallos

Sin acceso al sistema host fuera del alcance definido. Si algo sale mal, el radio de impacto queda limitado por la frontera que trazaste.

Por qué le importa a FinCo: un radio de impacto acotado es lo que hace defendible la operación autónoma en una revisión de seguridad. La frontera es la respuesta a «¿cuál es el peor caso?».

El sandbox no es una restricción de capacidad. Es lo que te permite autorizar la operación autónoma con confianza.

Configuración del alcance

Dos límites que configurar: qué directorios puede tocar Claude y a qué hosts puede llegar.

Estas cuatro claves son la forma en que el sandbox se escribe en managed-settings.json. Los nombres de las claves son correctos al momento de escribir esta lección. Confírmalos con la documentación actual de Claude Code antes de tu primer despliegue.

Sistema de archivos: permitir

sandbox.filesystem.allowWrite

Directorios de trabajo del proyecto donde Claude Code puede leer y escribir. Se define mediante allowWrite bajo sandbox.filesystem en managed-settings.json. Se establece explícitamente para que Claude sepa dónde puede operar durante una tarea.

Se lee como: «Claude puede operar aquí.» Normalmente, la raíz del proyecto y sus subdirectorios; nada más amplio de lo que necesita la tarea.

Sistema de archivos: denegar

denyWrite y denyRead

Dos claves separadas bajo sandbox.filesystem. denyWrite bloquea las carpetas de sincronización y las rutas que no deben modificarse; denyRead bloquea los almacenes de credenciales y los archivos sensibles que no deben leerse en absoluto. Ambas se aplican aunque la ruta esté dentro de un directorio permitido.

Se lee como: «Nunca aquí, aunque esté dentro de una ruta permitida.» denyRead cubre el caso del almacén de credenciales; denyWrite cubre el caso de la sincronización con Dropbox que aparece en los escenarios de más abajo.

Red: permitir

sandbox.network.allowedDomains

Endpoints de API aprobados, herramientas internas y hosts Git corporativos. Se define mediante allowedDomains bajo sandbox.network en managed-settings.json. Admite comodines (por ejemplo, *.finco.internal). Se acota a lo que la tarea necesita de verdad.

Se lee como: «Claude puede alcanzar estos dominios.» Para FinCo, eso incluye el registro interno npm.finco.internal y los endpoints corporativos aprobados.

Red: denegar

sandbox.network.deniedDomains

Almacenamiento personal en la nube, APIs externas no aprobadas y cualquier destino que pudiera usarse para exfiltrar datos. Se define mediante deniedDomains bajo sandbox.network en managed-settings.json. Tiene prioridad sobre allowedDomains.

Se lee como: «Nunca alcanzar estos.» El registro de denegación explícito es lo que el equipo de seguridad quiere ver en la pista de auditoría, no solo un valor implícito por defecto.

flowchart TD
    S["sandbox en managed-settings.json"] --> F["sandbox.filesystem"]
    S --> N["sandbox.network"]
    F --> FA["allowWrite<br/>Claude puede operar aquí"]
    F --> FW["denyWrite<br/>no modificar, aunque esté dentro de un permitido"]
    F --> FR["denyRead<br/>no leer, por ejemplo almacenes de credenciales"]
    N --> NA["allowedDomains<br/>dominios que Claude puede alcanzar"]
    N --> ND["deniedDomains<br/>dominios que nunca debe alcanzar"]
    ND -->|"tiene prioridad sobre"| NA

Los controles de egress (salida de red) operan en dos niveles. Anthropic aplica una línea base, con listas de dominios permitidos, sanitización de URLs y defensa contra la exfiltración, en todos los despliegues de Claude. Sobre esa base, el egress de red es un control administrativo a nivel de organización: los ajustes anteriores se configuran una vez en managed-settings.json y se aplican a todo el despliegue. No es un ajuste por desarrollador. El equipo de seguridad es responsable de la frontera de red, y esa frontera se mantiene sin importar cómo hayan configurado los desarrolladores sus entornos locales.

Comprueba tu comprensión

Constructor del alcance del sandbox

Decide a qué pertenece cada recurso. Permite lo que necesita la tarea y deniega lo que no debe tocar. Este es el entorno piloto de FinCo: clasifica cada recurso como permitir o denegar y revisa la clave que corresponde.

1. Sistema de archivos ~/finco-app

Ver respuesta

Permitir. El directorio de trabajo del proyecto es exactamente lo que necesita la tarea. Va en sandbox.filesystem.allowWrite.

2. Sistema de archivos ~/Dropbox

Ver respuesta

Denegar. Una carpeta de sincronización en la nube es una vía de exfiltración de datos. Va en sandbox.filesystem.denyWrite, aunque esté dentro de un directorio padre permitido.

3. Sistema de archivos ~/.aws/credentials

Ver respuesta

Denegar. Un almacén de credenciales no tiene cabida en una tarea de programación asistida. Bloquéalo explícitamente en sandbox.filesystem.denyRead.

4. Red npm.finco.internal

Ver respuesta

Permitir. El registro interno es una herramienta aprobada que la tarea necesita. Añádelo a sandbox.network.allowedDomains.

5. Red registry.npmjs.org

Ver respuesta

Denegar. El equipo de seguridad quiere que los registros públicos queden bloqueados explícitamente. Una entrada en sandbox.network.deniedDomains crea el registro de auditoría que necesitan.

Ilustrativo: verifica los nombres exactos de las claves con la documentación actual de Claude Code antes de aplicarlas.

Escenario: ¿dónde pertenece un límite de sistema de archivos?

Cuando el equipo de seguridad de un cliente pregunta dónde vive un control, la respuesta debe ser ajustes, no instrucciones. Las instrucciones son orientación; los ajustes son política.

Un cliente quiere que Claude Code ejecute tests y haga commits en Git, pero necesita impedir que toque la carpeta de sincronización en la nube ~/Dropbox. ¿Dónde debe ir esta configuración?

• A · En el archivo CLAUDE.md como instrucción de proyecto. Usa lenguaje natural para pedirle a Claude que evite esa carpeta.
• B · En managed-settings.json con una regla de denegación de directorio. Aplicada por el administrador y no puede ser anulada por el desarrollador.
• C · En el settings.json personal del usuario. El desarrollador configura su propio límite.
• D · No es configurable. Claude Code siempre tiene acceso a todo el directorio personal.

Ver respuesta

A · Incorrecta (CLAUDE.md). Una instrucción de CLAUDE.md es orientación, no política. Un desarrollador puede editarla o anularla. Los controles de seguridad que deben mantenerse en todos los usuarios y sesiones pertenecen a managed-settings.json, donde ningún usuario, archivo de proyecto ni prompt puede anularlos.

B · managed-settings.json (respuesta correcta). Es el lugar correcto para este límite. Una regla de denegación de directorio ahí es aplicada por el administrador, y el desarrollador no puede anularla, ni un archivo de proyecto ni una instrucción de CLAUDE.md. Los archivos de ajustes son política; las instrucciones del prompt son orientación. Este límite debe vivir en managed-settings.json, donde solo el administrador puede cambiarlo.

C · Incorrecta (settings.json personal). Poner el límite en el settings.json personal del usuario significa que el desarrollador puede eliminarlo. Un control de seguridad que la persona controlada puede editar no es un control.

D · Incorrecta (no es configurable). No es correcto. Las reglas de denegación de directorio en managed-settings.json restringen explícitamente qué rutas puede acceder Claude Code. El alcance del sistema de archivos es configurable, que es precisamente el objetivo de la lección sobre configuración del sandbox.

Escenario: configuración de red para el registro interno de npm

La gestión de paquetes es un punto de presión habitual en la configuración del sandbox. La cuestión no es si controlarla, sino cómo equilibrar el acceso de los desarrolladores con los requisitos de seguridad del cliente.

Durante la configuración piloto de FinCo, un desarrollador informa de que Claude Code no puede acceder al registro interno de npm (npm.finco.internal) para instalar paquetes. El equipo de seguridad también pide asegurarse de que Claude Code no pueda llegar directamente a los registros públicos de paquetes. ¿Cuál es el enfoque correcto de configuración del sandbox?

• A · Añadir npm.finco.internal a allowedDomains y los registros públicos a deniedDomains. Ambos pasos juntos conceden el acceso que necesita el desarrollador y crean el registro de bloqueo explícito que exige el equipo de seguridad.
• B · Eliminar todas las restricciones de red. La gestión de paquetes no debería estar sujeta al sandbox.
• C · Añadir npm.finco.internal solo a allowedDomains. Claude Code quedará bloqueado para todo lo demás por defecto.
• D · Bloquear npm.finco.internal y enrutar todas las operaciones de paquetes a través de un proxy. Un proxy es una arquitectura válida, pero no sustituye la decisión de configuración del sandbox.

Ver respuesta

A · Correcta. Permite explícitamente el registro interno y, después, deniega explícitamente los públicos. Los dos pasos son necesarios. sandbox.network.allowedDomains concede acceso a los endpoints aprobados, y sandbox.network.deniedDomains crea el registro de bloqueo explícito que el equipo de seguridad necesita para su pista de auditoría.

B · Incorrecta: eliminar las restricciones de red anularía el propósito del sandbox para un cliente de servicios financieros. La revisión de seguridad de FinCo exige un registro explícito de lo que Claude Code puede y no puede acceder. Una política de red totalmente abierta no pasará esa revisión.

C · Parcial (parcialmente correcta). Añadir el registro interno a sandbox.network.allowedDomains es correcto. Pero si el sandbox arranca con una postura de denegación por defecto, aun así necesitas entradas explícitas en sandbox.network.deniedDomains para los registros públicos: por un lado, el equipo de seguridad de FinCo espera registros de política explícitos; por otro, el comportamiento por defecto puede cambiar entre versiones de Claude Code.

D · Incorrecta: un proxy es una elección de arquitectura de red válida, pero es una decisión aparte de la configuración del sandbox. Si se acuerda el enfoque del proxy, el sandbox debe permitir el host del proxy y denegar los registros públicos, no denegar el registro interno.

Ideas clave

• El sandbox define el alcance: qué directorios puede tocar Claude Code y qué hosts puede alcanzar. Ese límite es lo que permite autorizar la operación autónoma con confianza.
• Las claves de sistema de archivos son allowWrite (dónde puede operar), denyWrite (qué no debe modificar) y denyRead (qué no debe leer). La denegación se aplica incluso dentro de rutas permitidas.
• Las claves de red son allowedDomains (dominios alcanzables) y deniedDomains (dominios que nunca deben alcanzarse, con prioridad sobre los permitidos).
• Los límites de red son un control administrativo a nivel de organización, configurado una vez en managed-settings.json. Cuando un equipo de seguridad pregunta dónde vive un control, la respuesta son ajustes, no instrucciones.

Siguiente: SSO (SAML, OIDC), SCIM e IP allowlisting