Guía de seguridad de Claude Code: permisos, MCP y sandboxing

Los chatbots tradicionales viven detrás de una API, así que lo peor que pueden hacer es alucinar. Pero un agente de IA para programar se mete en tu repositorio, tu terminal y (a menudo) en tus credenciales en la nube, lo que lo acerca mucho más a entornos de desarrollo con privilegios que cualquier cosa que antes llamábamos chatbot.

La cuestión es cómo usar Claude Code con seguridad sin perder ritmo. Con permisos, controles MCP y sandboxing, ajustados con cabeza, lo conseguirás.

En este artículo verás cómo funciona de verdad el modelo de seguridad de Claude Code, en qué puntos debes fijarte y qué prácticas lo mantienen útil sin darle más acceso del que querías.

Si eres completamente nuevo en Claude y Claude Code, apúntate a nuestro curso gratuito Claude Code 101 para dominar lo básico en una tarde.

Entender el modelo de seguridad de Claude Code

Antes de tocar una sola regla, necesitas un mapa mental de lo que realmente controla Claude Code.

Hay cinco piezas: un sistema de permisos que decide qué se permite, controles de acceso a herramientas que acotan capacidades concretas, permisos MCP para integraciones externas, sandboxing para aislamiento a nivel de SO y auditabilidad para revisar a posteriori. Cada una resuelve un problema distinto, pero se complementan.

Sistema de permisos

El sistema de permisos es la capa estática.

Declaras qué puede hacer Claude en settings.json usando tres listas: allow, ask y deny. Las reglas se evalúan primero deny, luego ask y después allow, y manda la primera coincidencia. Una regla deny bloquea la llamada aunque una allow más amplia también la hubiera cubierto.

Si ninguna regla coincide, Claude recurre al defaultMode de la sesión (más sobre modos en la siguiente sección).

Controles de acceso a herramientas

Los permisos se asocian a herramientas, no al agente completo.

Claude Code incluye sus propias herramientas integradas: por ejemplo Bash para comandos de shell, Read, Edit y Write para el sistema de archivos, WebFetch para peticiones HTTPS, WebSearch para búsquedas, y algunas más. Cada regla nombra una herramienta y (opcionalmente) un especificador entre paréntesis, como Bash(git commit:*) o Read(./.env).

Así se aplica el principio de mínimo privilegio. Puedes permitir Bash(npm run:*) para tests sin darle a Claude acceso completo al shell.

Permisos MCP

Los servidores MCP amplían Claude Code con herramientas para las que no fue diseñado inicialmente.

Cada servidor aporta su propio set de herramientas (uno de GitHub añade herramientas de pull requests, uno de base de datos añade herramientas de consultas, etc.). El sistema de permisos también los cubre, pero con otra sintaxis: las reglas usan el formato mcp__servername__toolname en lugar del especificador entre paréntesis.

Recuerda que MCP prácticamente duplica el problema, porque no solo decides qué puede hacer Claude con tu shell, sino también con cada sistema externo que conectes.

Sandboxing

El sandboxing es la seguridad a nivel de sistema operativo bajo la herramienta Bash.

Las reglas de permisos le dicen a Claude lo que debe hacer. El sandboxing impone lo que puede hacer, restringiendo el acceso al sistema de archivos y las llamadas de red salientes a nivel de SO. En macOS funciona de serie con Seatbelt. En Linux y WSL2, primero tienes que instalar bubblewrap y socat.

Las dos capas funcionan de forma parecida pero cubren escenarios distintos. Los permisos impiden que Claude lo intente, y el sandboxing evita que tenga éxito si una inyección de prompt logra convencerle para intentarlo.

Auditabilidad

La última pieza es poder ver qué ha pasado.

El comando /permissions lista cada regla activa y el archivo de configuración de donde sale, para que puedas responder «¿por qué ejecutó Claude eso?». Los hooks (PreToolUse, PostToolUse y otros) te permiten registrar cada llamada de herramienta en tu propio sistema. Para equipos, los exportadores de OpenTelemetry envían datos de uso y llamadas de herramientas a la plataforma de observabilidad que ya tengas.

Permisos y control de acceso en Claude Code

La mayor parte de la seguridad viene de la configuración de permisos, así que es donde más tiempo invertirás ajustando.

Acceso a archivos

Por defecto, Claude puede leer y editar archivos en el directorio desde el que lo iniciaste.

La lectura la controla la herramienta Read, y la edición Edit y Write. Cada una acepta un patrón de ruta entre paréntesis, con sintaxis estilo gitignore. Por ejemplo, Read(**/.env) coincide con cualquier archivo .env a cualquier nivel, y Edit(src/**) con todo lo que haya bajo src/.

Un deny en Read cubre las herramientas de archivos propias de Claude Code (Read, Grep, Glob, LS), pero es solo un mejor esfuerzo. Un script de Python o Node ejecutado con Bash puede seguir abriendo el archivo, porque esa lectura ocurre a través del shell y no de la herramienta Read de Claude. Si el secreto importa, combina el deny de Read con un deny de Bash para cat, head y tail sobre esas rutas.

Para ampliar el acceso más allá del directorio de trabajo, usa additionalDirectories en settings.json. Así das a Claude acceso a una librería compartida fuera del repo o a un archivo de configuración en tu directorio personal, sin eliminar por completo el límite del directorio de trabajo.

Ejecución de comandos

La herramienta Bash es la que más cuidadosamente debes acotar.

Una regla Bash sin más permite cualquier comando. Una regla acotada como Bash(npm run:*) solo permite invocaciones que coincidan. Aquí debes usar el patrón con dos puntos y asterisco, y Claude Code entiende operadores de shell, así que una regla como Bash(safe-cmd:*) no coincide con safe-cmd && rm -rf /.

Algunos comandos se ejecutan sin preguntar en cualquier modo, porque se tratan como de solo lectura por defecto. La lista incluye ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd y formas de git de solo lectura. No puedes reducir esta lista a mano, pero sí añadir una regla ask o deny para cualquiera y anular el valor por defecto.

Para todo lo que no esté preaprobado, Claude pide permiso en el modo por defecto. El aviso muestra el comando exacto y te deja aprobarlo una vez, aprobar futuras llamadas que coincidan con un patrón o denegarlas.

Modos de permiso

Las reglas de permisos son estáticas, pero los modos de permiso cambian cómo se comportan las llamadas no cubiertas.

Hay cinco:

• default: pregunta al primer uso de cada herramienta.

• acceptEdits: aprueba automáticamente ediciones de archivos en el directorio de trabajo y sigue controlando los comandos de shell. Útil cuando confías en las ediciones pero no en el shell.

• plan: Claude lee y analiza, pero no puede editar archivos ni ejecutar comandos. El modo adecuado para revisión de código o sesiones de planificación.

• dontAsk: deniega automáticamente todo lo que no esté explícitamente en allow.

• bypassPermissions: omite todos los avisos. Solo es seguro en entornos totalmente aislados como un contenedor o VM.

Puedes alternar entre los tres modos principales con Shift+Tab en mitad de la sesión, o seleccionar uno como predeterminado en settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

Para equipos, las configuraciones gestionadas te dan una capa que el usuario no puede sobrescribir. El archivo sigue el mismo formato JSON y se encuentra en una ruta del sistema:

• /Library/Application Support/ClaudeCode/managed-settings.json en macOS

• /etc/claude-code/managed-settings.json en Linux

• C:\ProgramData\ClaudeCode\managed-settings.json en Windows

Las reglas deny en configuraciones gestionadas se aplican a todos los proyectos de la máquina, que es como haces cumplir normas tipo «nadie lee archivos .env» o «nadie ejecuta bypassPermissions» en toda la organización.

El principio detrás de todo esto es el mínimo privilegio, el mismo que aplicarías a cualquier cuenta de servicio. 

Empieza con el conjunto de permisos más pequeño que permita trabajar y amplíalo solo cuando te topes con un bloqueo. Las propias recomendaciones de Anthropic van en esa línea: revisa los cambios que hace Claude, audita tus reglas con /permissions y guarda en control de versiones las configuraciones específicas de proyecto para que el equipo esté de acuerdo en qué puede tocar Claude.

Sandboxing en Claude Code

Cuanto más dejes que Claude actúe de forma autónoma, más sentido tiene el sandboxing.

La herramienta Bash es la más expuesta, ya que los comandos de shell pueden leer cualquier archivo que tú puedas leer y modificar aquello para lo que tengan permiso de escritura. El sandboxing impone límites a nivel de SO a cada comando de Bash y sus procesos hijo, de modo que Claude puede ejecutar más libremente dentro del perímetro sin que apruebes cada llamada. Anthropic lo integró específicamente para dar soporte a ejecuciones autónomas más seguras.

Un detalle importante: el sandbox solo cubre Bash y sus procesos hijo. No restringe las herramientas Read, Edit o Write, que siguen pasando por el sistema de permisos.

Sandboxing nativo

El sandbox nativo está integrado en Claude Code y se activa con /sandbox.

En macOS usa el framework Seatbelt y no hay nada que instalar. En Linux y WSL2, instala bubblewrap para el aislamiento del sistema de archivos y socat para el proxy de red. Windows nativo no está soportado, así que ejecuta Claude Code dentro de una distribución WSL2.

El límite del sistema de archivos es fácil de entender. La lectura funciona en todas partes salvo en rutas denegadas, y las escrituras solo funcionan dentro del directorio de trabajo y las rutas adicionales que permitas. Si intentas escribir en ~/.bashrc desde el sandbox recibirás «Operation not permitted» antes de que Claude sepa siquiera que ha fallado.

El límite de red es algo distinto. El tráfico saliente pasa por un proxy fuera del sandbox, que comprueba cada solicitud frente a tu lista allowedDomains. Los dominios nuevos disparan un aviso de permiso, así que ves exactamente a qué intenta acceder Claude.

Una configuración funcional se ve así:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

En el uso interno de Anthropic, el sandboxing reduce los avisos de permiso en un 84%.

Contenedores de desarrollo

Los dev containers son el siguiente nivel de aislamiento.

Anthropic ofrece un devcontainer de referencia para Claude Code que monta un entorno Ubuntu, monta tu repo y da al agente un shell donde trabajar. La ventaja frente al sandbox nativo es la reproducibilidad: todo el equipo tiene el mismo entorno, con las mismas herramientas y la misma configuración.

La contrapartida es la sobrecarga. 

Con contenedores añades la build, el montaje de archivos y (a veces) un ciclo de feedback más lento. Para una persona desarrolladora, el sandbox nativo suele ser suficiente. Para equipos o CI, este setup compensa.

Aislamiento basado en Docker

Para sesiones autónomas de larga duración, Docker puede ampliar aún más el perímetro del sandbox.

El setup suele ser así:

• Imagen base mínima: elimina gestores de paquetes y herramientas de red que la tarea no necesite.
• Usuario sin privilegios: Claude nunca se ejecuta como root, así no puede modificar archivos de sistema ni instalar paquetes globales.
• Sistema de archivos root de solo lectura: monta el root del contenedor como solo lectura, con solo directorios de salida concretos en escritura.
• Proxy de salida: enruta la red saliente por un proxy que permita el registro de paquetes (npm, PyPI) y deniegue el resto, para que npm install funcione pero un curl arbitrario no.
• Límites de recursos: limita CPU, memoria e I/O para que un proceso no tumbe el host.

Docker Sandboxes da a cada sandbox su propia microVM con un demonio de Docker privado. El demonio del host ni siquiera ve los sandboxes en docker ps. El perímetro se acerca más al de una VM que al de un contenedor, cerrando la mayoría de vías de escape que preocupan a los desarrolladores.

Estrategias de sandboxing para empresa

Para organizaciones, la pregunta es cómo superponer técnicas de sandbox, no si usarlas.

Así suele enfocarlo la mayoría:

• Las reglas de permisos van en managed-settings.json y los desarrolladores no pueden anularlas.

• El sandboxing nativo se ejecuta por debajo de la capa de permisos.

• Los dev containers o Docker por debajo de eso.

• Para escenarios de máxima confianza (acceso a producción, manejo de secretos), una VM dedicada sin montajes del sistema de archivos del host es la última capa.

Claude Code en la web es una versión gestionada de la misma idea. Cada sesión se ejecuta en una VM gestionada por Anthropic, las credenciales sensibles como los tokens de git se sitúan fuera del sandbox en un proxy, y el perímetro lo hace cumplir la infraestructura.

Seguridad MCP en Claude Code

MCP es la parte de Claude Code que crece más rápido.

Cada servidor MCP que conectas multiplica lo que Claude puede hacer, pero también multiplica la superficie a la que puede llegar una inyección de prompt o una dependencia comprometida. 

Por ejemplo:

• Un servidor MCP de GitHub da a Claude acceso a pull requests.
• Un servidor MCP de base de datos le da tu esquema y consultas.
• Un servidor de Slack le da tus canales.

Nada de eso es un problema en sí, pero implica que MCP necesita su propia gobernanza. El contenido obtenido mediante una herramienta MCP (una página web o la respuesta de una API) puede contener instrucciones inyectadas que Claude ejecute como si las hubieras escrito tú. Además, cada servidor añade una credencial y una vía de autenticación que hay que gestionar aparte.

Permisos de herramientas

Las herramientas MCP usan una convención de nombres distinta a las integradas.

El formato de regla es mcp__servername__toolname, sin especificador entre paréntesis. Por ejemplo, mcp__github__create_pull_request permite a Claude llamar exactamente a esa herramienta, y un deny en mcp__github__delete_repo bloquea la peligrosa. Las listas allow, ask y deny funcionan igual que para Bash o Read.

Se aplican las mismas prioridades: primero deny, luego ask y después allow. Un deny en configuraciones gestionadas para mcp__github__delete_* es válido en todos los proyectos de la máquina.

Permisos de recursos

Los servidores MCP pueden exponer recursos además de herramientas.

Un recurso es un dato que el servidor pone a disposición de Claude para leer (un archivo en un servidor de gestión de proyectos o una fila en un servidor de base de datos). El acceso a recursos pasa por la misma comprobación de confianza que las llamadas de herramientas, y la primera conexión a un servidor MCP ejecuta una verificación de confianza antes de que se pueda acceder a cualquiera de sus herramientas o recursos.

El buen por defecto es tratar los recursos como otra herramienta más. Si no concederías la credencial, no concedas el acceso al recurso.

Servidores MCP aprobados

El directorio de Anthropic lista conectores que Anthropic ha revisado según sus criterios de publicación.

Para organizaciones, un buen patrón es usar una lista de permitidos interna. Hay dos ajustes que te dan el control:

• allowedMcpServers: un patrón glob de servidores que los desarrolladores pueden añadir a sus proyectos (por ejemplo, company-* para permitir solo servidores mantenidos internamente).

• deniedMcpServers: un patrón de servidores que no se pueden añadir, aunque el desarrollador lo intente.

Para servidores obligatorios que deban estar presentes en cada sesión, un archivo managed-mcp.json ubicado en las configuraciones gestionadas es la forma de distribuirlos. Los desarrolladores no pueden eliminar ni modificar las entradas.

Un ajuste a evitar en repos compartidos es enableAllProjectMcpServers, que aprueba automáticamente cualquier servidor MCP definido en .mcp.json. Es cómodo para trabajo individual y peligroso para cualquier cosa versionada, porque una PR maliciosa podría añadir un servidor a .mcp.json y ejecutarlo sin aviso.

Acceso a herramientas con mínimo privilegio

El mismo principio que con los permisos de Bash, aplicado a MCP.

La pregunta inicial es qué credencial usa cada servidor. Un servidor MCP de base de datos debería conectarse a una réplica de solo lectura, no al primario con permisos de escritura. Un servidor MCP de API debería usar un token acotado al mínimo conjunto de endpoints necesario, no un token personal con acceso completo a la organización. Y así sucesivamente.

Los subagentes son otra forma de acotar el acceso MCP. Una definición de subagente en .claude/agents/ puede declarar exactamente a qué herramientas tiene acceso (usando la sintaxis mcp:<server>:<tool>), de modo que un «deploy-agent» tenga el servidor de infraestructura y un «review-agent» solo Read, Grep y Glob. El agente no puede llamar a herramientas que no se le hayan dado.

Gobernanza de MCP

Para un equipo u organización que ejecute Claude Code a escala, MCP necesita la misma forma de gobernanza que cualquier otra integración en producción.

Eso implica un registro de servidores aprobados con responsables asignados, trazabilidad extremo a extremo de invocaciones de herramientas (qué herramientas MCP se llamaron, por quién, con qué parámetros) y una revisión periódica de la lista de aprobados. Los exportadores de OpenTelemetry en Claude Code te dan los datos de auditoría en un formato que encaja con la pila de observabilidad que ya uses.

Para organizaciones grandes, una pasarela MCP centralizada es la versión más limpia. 

Los desarrolladores se conectan a la pasarela en lugar de registrar servidores individuales. La pasarela gestiona la autenticación, aplica control de acceso basado en roles a nivel de herramienta y emite una única traza de auditoría. También evita la dispersión de credenciales, porque un set de credenciales en la pasarela sustituye a que cada desarrollador guarde una copia de cada clave de API.

Gestión de secretos y datos sensibles

Claude Code puede leer todo lo que tú puedes leer, lo que hace que los secretos sean alcanzables.

Por defecto, Claude Code puede leer todos los archivos a los que tu usuario tenga acceso. Eso incluye archivos .env en tu proyecto, credenciales de AWS en ~/.aws/, claves privadas SSH en ~/.ssh/, los tokens de GitHub en tu archivo rc del shell y las variables de entorno de cualquier subproceso que cree Claude. Es totalmente normal y está diseñado así.

Mantén los secretos fuera del espacio de trabajo

Lo primero es asegurarte de que no haya secretos en el directorio que esté leyendo Claude.

.env son los más habituales. Están en la raíz del proyecto, los cargan todas las herramientas de desarrollo y contienen justo los valores que no quieres en un contexto de Claude (URLs de bases de datos y claves de API). 

Aquí tienes un par de patrones útiles:

• Mueve los secretos a un directorio fuera del árbol de trabajo, por ejemplo ~/.config/myapp/secrets.env, y cárgalos con un gestor de entornos o una configuración de direnv que apunte al archivo externo.

• En trabajo con contenedores, guarda una carpeta .secrets/ fuera del bind mount para que el archivo sea invisible desde dentro del contenedor.

• Añade Read(**/.env) y Read(**/.env.*) a tu lista permissions.deny y acompáñalas con denegaciones Bash(cat:*/.env) para que un script de shell no pueda leer lo que la herramienta Read no puede.

Usa un gestor de secretos

Para algo más que proyectos de demo, el lugar adecuado para los secretos es un gestor de secretos.

El patrón es el mismo con cualquier proveedor (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Los secretos se guardan en el gestor. Tu shell o runtime los obtiene bajo demanda y los expone solo al proceso que los necesita. Claude no llega a ver el valor real.

Para Claude Code en concreto, esto implica ajustar CLAUDE_CODE_SUBPROCESS_ENV_SCRUB para eliminar credenciales de Anthropic y de cloud de los subprocesos, o usar sandbox.credentials para desactivar variables concretas en comandos dentro del sandbox. Lo primero evita que Claude pase tu ANTHROPIC_API_KEY a un script de build, y lo segundo cubre el caso general de cualquier variable sensible que acabe en un comando de shell.

Restringe el acceso al repositorio

La tercera opción es a nivel de repo.

Si una persona desarrolladora no necesita acceso de escritura a configuración exclusiva de producción, su sesión de Claude Code tampoco. Parece obvio, pero lo normal es que los equipos tengan más acceso del que usan a diario, y Claude hereda todo eso.

Dos pasos que puedes dar:

• Separa la configuración de producción en un repo aparte con acceso más estricto, para que el entorno de desarrollo donde trabaja Claude no tenga secretos de producción de entrada.

• Usa tokens con alcance acotado para cualquier servicio con el que interactúe Claude. Por ejemplo, un token de GitHub para revisión de código no necesita repo:delete.

Seguridad de Claude Code para equipos

Una persona sola puede cambiar settings.json como quiera. Un equipo no, porque la seguridad global es tan débil como la configuración más floja en la máquina más floja. Para despliegues de equipo y organización, Claude Code tiene una capa de controles aparte que un admin impone y los usuarios no pueden sobrescribir.

Configuraciones gestionadas

Las configuraciones gestionadas son la base.

El archivo está en una ruta del sistema que requiere permisos de admin para escribir:

• /Library/Application Support/ClaudeCode/managed-settings.json en macOS

• /etc/claude-code/managed-settings.json en Linux

• C:\ProgramData\ClaudeCode\managed-settings.json en Windows

Los ajustes de este archivo tienen prioridad sobre los de usuario y los de proyecto. Una regla deny aquí es una denegación en todos los proyectos de la máquina, y el desarrollador no puede quitarla editando su settings.json. La mayoría de organizaciones distribuyen el archivo mediante MDM (Mobile Device Management) o el mismo canal de configuración que usan para otras herramientas de desarrollo.

A este nivel gestionado, conviene conocer estos ajustes:

• permissions.deny para rutas sensibles y comandos peligrosos

• defaultMode ajustado a default o plan (nunca bypassPermissions)

• allowManagedPermissionRulesOnly: true para bloquear el conjunto de permisos

• enableAllProjectMcpServers: false para exigir aprobación explícita de MCP

• Configuración del exportador de OpenTelemetry para logging

Políticas de permisos compartidas

Si un equipo acuerda qué puede hacer Claude, debería versionar ese acuerdo.

Las configuraciones a nivel de proyecto están en .claude/settings.json en la raíz del repo. Todo lo que se versiona aquí aplica a cualquiera que ejecute Claude en ese repo. El archivo es el lugar adecuado para allows y denies específicos del proyecto.

Con esto en mente, hay una separación entre configuraciones gestionadas y de proyecto que debes conocer:

• Las gestionadas contienen la política de la organización (nadie ejecuta bypassPermissions, nadie lee .env).

• Las de proyecto contienen convenciones de flujo de trabajo (los tests de este repo se ejecutan con npm test; el script de deploy de este repo está vetado).

Gobernanza de equipo

Para un despliegue en equipo, la capa de políticas necesita un responsable.

La mayoría de equipos que usan Claude Code a escala acaban con un grupo pequeño, normalmente seguridad e ingeniería de plataforma, que gestiona las configuraciones gestionadas, la lista de MCP permitidos, los scripts de hooks y la canalización de OpenTelemetry. Ese mismo grupo revisa solicitudes de excepción y ajusta la política a medida que surgen nuevos casos de uso.

Conviene tener por escrito estas piezas:

• Qué repos están en alcance y cuáles no, con modos según riesgo (un repo con datos regulados probablemente ejecuta Claude en modo plan, mientras que un repo de un sitio de marketing puede ir en acceptEdits).
• Quién puede conceder excepciones y cómo se registran.
• Una cadencia de revisión (trimestral es común) en la que el equipo repasa reglas de permisos, servidores MCP y datos de incidentes.

Registro de auditoría

Claude Code emite eventos de OpenTelemetry por cada decisión de herramienta, conexión a servidor MCP, cambio de modo de permiso y solicitud a la API. No fluye ningún dato hasta que un admin configura el endpoint OTLP en las configuraciones gestionadas.

Este es un bloque mínimo de configuraciones gestionadas para telemetría:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Por defecto, el contenido de los prompts y los parámetros de herramientas se excluyen de la exportación, así que los eventos que recoges son metadatos, no la conversación completa. Para incluir el texto del prompt, ajusta OTEL_LOG_USER_PROMPTS=1. Para incluir argumentos de herramientas (lo más útil para auditoría), ajusta OTEL_LOG_TOOL_DETAILS=1. Ambas decisiones tienen implicaciones de privacidad, así que la mayoría las trata como opciones de política deliberadas y configura su backend de telemetría para filtrar o enmascarar antes de almacenar.

Monitorización de uso

El mismo flujo de OpenTelemetry que sirve para auditoría sirve para monitorizar el uso.

Claude Code exporta métricas de uso de tokens, coste por solicitud, número de sesiones y tasas de decisiones de herramientas. Al agregarlas, sabrás qué equipos obtienen más valor, qué flujos generan más rechazos y qué modelos impulsan el coste. Backends como Datadog, Honeycomb, SigNoz, Elastic y Splunk ingieren el formato estándar OTLP.

Un pico de eventos permission_decision con decision=deny puede significar que Claude intenta hacer demasiado, pero también que las reglas allow del equipo son demasiado estrictas.

Errores comunes de seguridad en Claude Code

Un pequeño conjunto de malas configuraciones aparece en la mayoría de incidentes con Claude Code. Aquí tienes cuáles son y cómo solucionarlas.

Permisos demasiado amplios

La forma más rápida de desactivar el sistema de permisos es permitir demasiado.

Los avisos por comando añaden fricción, y la solución fácil es un allow amplio Bash(*) o un defaultMode: bypassPermissions. Ambos deshacen gran parte de lo que hace el sistema de permisos.

Acota las reglas allow a herramientas y comandos concretos que realmente uses (por ejemplo Bash(npm test:*) y Bash(git status)) y deja que el resto pase por aviso. Al principio verás más prompts, pero en unas sesiones habrás permitido los comandos que usas y casi dejarán de aparecer.

Acceso MCP sin restricciones

El segundo error es conectar servidores MCP sin revisar qué credenciales usan o a qué alcanzan.

Suele ocurrir porque alguien activa enableAllProjectMcpServers, conecta varios servidores del directorio público de MCP y nunca vuelve a revisarlos. Cuando un servidor con credencial débil filtra algo sensible, la conexión está tan atrás en la configuración que nadie recuerda haberla aprobado.

La solución es la misma que con los permisos. Usa una lista de permitidos explícita con allowedMcpServers, un managed-mcp.json interno para los servidores que todos necesitan y una cadencia de revisión de la lista.

Sin sandboxing

Si el sandboxing está desactivado, el sistema de permisos es lo único entre Claude y tu sistema de archivos.

Vale para sesiones interactivas cortas en las que apruebas cada comando. No vale para ejecuciones autónomas, sesiones con reglas allow más amplias o trabajos que toquen código de fuentes externas.

/sandbox lo activa. Si faltan dependencias, el menú te muestra cuáles instalar en tu plataforma. Una vez activo, caen los avisos de permiso y el SO captura los casos que tus reglas allow no cubren.

Aceptar cambios a ciegas

acceptEdits es tan cómodo como peligroso.

Cuando Claude reescribe una función y tú lo supervisas, el auto-aceptar está bien. Cuando Claude itera por 30 archivos durante una hora, tiendes a dejar de leer los diffs y a empezar a confiar en el agente. Ahí es donde pueden surgir problemas.

Dos hábitos que deberías adoptar:

• Haz commit siempre antes de dejar que Claude actúe de forma autónoma, para que el rollback sea un simple git reset.

• Revisa el diff antes de cada commit firmado por Claude, no el diff acumulado al final de la sesión.

Ignorar las trazas de auditoría

Un equipo que ejecuta Claude Code sin telemetría no puede responder a «¿qué sesión hizo eso?». Los eventos se acumulan localmente en cada máquina y se quedan ahí. La primera vez que necesitas una traza de auditoría es el peor momento para descubrir que no la configuraste.

El mínimo útil es exportar eventos tool_decision, permission_decision y api_request a la plataforma de observabilidad que el equipo ya use. A partir de ahí, construyes paneles y alertas según vayan surgiendo casos de uso.

Conclusión

El peor caso para un chatbot es una mala respuesta. Para un agente de programación, es un comando de shell ejecutándose en producción con tus credenciales.

Por eso importan los tres pilares:

• Los permisos deciden qué puede hacer Claude
• Los controles MCP deciden a qué sistemas externos puede llegar
• El sandboxing decide qué pasa cuando los dos primeros no bastan

Cada uno cubre un modo de fallo que los otros no. Juntos definen el perímetro real dentro del que trabaja Claude.

Si quieres certificarte en IA generativa, aquí tienes comparativas, cursos destacados, consejos de preparación y preguntas frecuentes sobre las mejores certificaciones en IA generativa de 2026.