Controles de administrador de Claude Code: guía completa para equipos de IT y DevOps (2026)
Rama Adi Nugraha
Katelin Teen
Última edición June 9, 2026
Por qué Claude Code necesita controles de administrador
Cuando implementas un agente de programación en una organización de ingeniería, el perfil de riesgo es diferente al de implementar una herramienta de chat. Claude Code puede ejecutar comandos de shell, leer archivos en toda una base de código, abrir pull requests y, si se le dan los permisos adecuados, acceder a internet o escribir en archivos de secretos. Sin controles, aparecen dos modos de fallo: los desarrolladores se instalan en un uso cauteloso y confirman cada acción manualmente, o conceden permisos generales y terminan con un agente que técnicamente puede hacer cualquier cosa.
Ninguno es lo que quieres. Lo que realmente quieres es algo más parecido a la Directiva de grupo para IA: defines lo que la herramienta puede hacer a nivel organizacional, los desarrolladores obtienen un entorno productivo dentro de esos límites, y tienes capacidad de auditoría si algo sale mal.
Para eso están diseñados los controles de administrador de Claude Code. Vamos a recorrer cada capa del sistema.
La jerarquía de configuración de cuatro niveles
Cada configuración de Claude Code se resuelve a través de una pila de precedencia. De mayor a menor prioridad:
- Managed – implementado por IT, máxima prioridad, no puede ser anulado por nada
- Argumentos CLI – anulaciones solo para la sesión (
--model sonnet,--permission-mode plan) - Proyecto local (
.claude/settings.local.json) – anulaciones personales para este repositorio, en gitignore - Proyecto compartido (
.claude/settings.json) – compartido por el equipo, confirmado en git - Usuario (
~/.claude/settings.json) – valores predeterminados globales personales
La capa gestionada es el techo y las configuraciones de usuario son el suelo. Las configuraciones de proyecto son donde los equipos estandarizan las herramientas. Las configuraciones con valor de array como permissions.allow se fusionan en todos los ámbitos en lugar de reemplazarse entre sí: una regla de allow en las configuraciones de usuario se apila con una regla de allow en las configuraciones de proyecto. Los valores escalares siguen el principio de ganador-se-lleva-todo desde el ámbito más alto que los define.
Un matiz que vale la pena conocer: el modo auto se ignora cuando se establece en configuraciones de proyecto o locales a partir de v2.1.142. Si estás estableciendo defaultMode: "auto" en una configuración de proyecto y te preguntas por qué no tiene efecto, esa es la razón: tiene que venir de las configuraciones de usuario o gestionadas.
Implementar configuraciones gestionadas
Cuatro mecanismos de entrega, todos leen el mismo formato JSON:
Gestionado por servidor (Teams/Enterprise): Envía configuraciones desde la consola de administración en claude.ai. Requiere un plan Claude for Teams o Enterprise. Usa forceRemoteSettingsRefresh: true para bloquear el inicio de sesión hasta que el push se confirme – útil cuando tu actualización de política necesita entrar en vigor antes de que cualquier desarrollador pueda continuar trabajando.
MDM de macOS (Jamf, Kandji, Mosyle): Implementa un perfil de configuración apuntando al dominio plist com.anthropic.claudecode. Las claves de nivel superior reflejan los nombres de campos JSON; las configuraciones anidadas usan diccionarios plist, los arrays usan arrays plist. Enfoque estándar para organizaciones que ya gestionan Macs con MDM.
Directiva de grupo de Windows / Intune: Escribe JSON en HKLM\SOFTWARE\Policies\ClaudeCode con un valor Settings de tipo REG_SZ. Implementa mediante un Objeto de directiva de grupo o un perfil de configuración de Intune. Para políticas solo a nivel de usuario (cuando no hay ninguna fuente a nivel de administrador presente), usa HKCU\SOFTWARE\Policies\ClaudeCode.
Basado en archivos: Coloca managed-settings.json en:
- macOS:
/Library/Application Support/ClaudeCode/ - Linux / WSL:
/etc/claude-code/ - Windows:
C:\Program Files\ClaudeCode\
El método basado en archivos también admite un directorio drop-in managed-settings.d/ en la misma ubicación. Los archivos se ordenan alfabéticamente y se fusionan profundamente: los escalares de los archivos posteriores ganan, los arrays se concatenan y se deduplictan. Útil si múltiples herramientas de seguridad o equipos necesitan contribuir fragmentos de política separados sin sobrescribirse mutuamente.
Para políticas dinámicas derivadas de la postura del dispositivo o un servicio de cumplimiento remoto, la clave policyHelper apunta a un ejecutable que calcula el JSON de configuración al inicio. El binario escribe un envelope JSON (con configuraciones bajo una clave managedSettings) en stdout, y Claude Code lo recoge antes de que comience la sesión. Disponible desde v2.1.136.
Para verificar qué está activo, ejecuta /status dentro de Claude Code. La pestaña Estado muestra una línea Setting sources que enumera cada capa activa, con el canal de entrega entre paréntesis: Enterprise managed settings (remote), (plist), (HKLM), (file).
Permisos: reglas allow, ask y deny
El sistema de permisos es cómo expresas qué puede hacer Claude sin preguntar y qué no puede tocar en absoluto. Tres tipos de reglas:
- Allow – Claude ejecuta la herramienta automáticamente, sin solicitud
- Ask – Claude solicita confirmación al desarrollador antes de ejecutar (valor predeterminado para la mayoría de las herramientas)
- Deny – Claude no puede usar la herramienta en absoluto
Las reglas siguen el formato Tool o Tool(specifier). Un deny simple como "Bash" elimina la herramienta completa del contexto de Claude, de modo que Claude nunca intenta usarla. Un deny con alcance como "Bash(rm *)" mantiene la herramienta disponible pero bloquea las llamadas coincidentes en tiempo de ejecución.
El orden de evaluación es siempre deny primero, luego ask, luego allow – y la primera regla coincidente gana independientemente del ámbito del que provenga. Un deny en las configuraciones de usuario bloquea un allow a nivel de proyecto. Un deny gestionado no puede ser desbloqueado por ningún ámbito inferior.
Una base práctica en .claude/settings.json para un entorno de equipo:
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git status)",
"Bash(git stash *)"
],
"deny": [
"Bash(curl *)",
"Bash(wget *)",
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"WebFetch"
]
}
}
Esto aprueba automáticamente los comandos de desarrollo comunes mientras bloquea las herramientas de red y las lecturas de archivos sensibles.
Patrones de reglas de permisos que debes conocer
Los comodines coinciden entre argumentos. Bash(npm run *) coincide con npm run test --watch – el * abarca múltiples argumentos incluidos los espacios. Bash(git *) coincide con git log --oneline --all. Un espacio antes de * impone un límite de palabra: Bash(ls *) coincide con ls -la pero no con lsof.
El curl con restricción de URL es frágil. Bash(curl http://github.com/ *) falla con curl -X GET http://github.com/... (opciones antes de la URL), curl https://github.com/... (protocolo diferente), o variables de entorno que contienen la URL. Para una restricción de dominio confiable, usa WebFetch(domain:github.com) para los dominios permitidos y deniega completamente las herramientas de red Bash. La explicación completa está en la referencia de permisos.
Los comandos compuestos se dividen antes de coincidir. Una regla de allow para npm test no cubre npm test && curl evil.com. Claude Code divide en &&, ||, ;, | y comprueba cada subcomando de forma independiente.
Los patrones Read/Edit siguen la sintaxis de gitignore. Read(./.env) y Read(**/.env) son equivalentes – ambos bloquean cualquier .env en o bajo el directorio actual. Usa Read(//**/.env) para bloquear archivos .env en cualquier parte del sistema de archivos.
Modos de permisos
Seis modos de permisos cambian cómo se manejan las llamadas a herramientas no coincidentes:
| Modo | Qué hace |
|---|---|
default | Solicitar en el primer uso de cada herramienta |
acceptEdits | Aprobar automáticamente ediciones de archivos y comandos de sistema de archivos seguros |
plan | Solo lectura: sin modificaciones de archivos |
auto | Las comprobaciones de seguridad en segundo plano aprueban automáticamente las llamadas alineadas (vista previa de investigación) |
dontAsk | Denegar automáticamente a menos que se haya pre-aprobado mediante reglas allow |
bypassPermissions | Omitir todas las solicitudes: solo para contenedores/VMs aislados |
Establece defaultMode en la configuración para bloquear el modo de inicio. Para evitar que el modo bypassPermissions se active alguna vez, añade a tus configuraciones gestionadas:
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}
Esto cierra el flag --dangerously-skip-permissions por completo: los desarrolladores ven un error si intentan usarlo. El mismo patrón para el modo auto: "disableAutoMode": "disable".
Configuraciones solo gestionadas: los controles de bloqueo exclusivos del administrador
Varias configuraciones solo tienen efecto cuando se implementan a través de configuraciones gestionadas. Colocarlas en archivos de usuario o de proyecto no tiene ningún efecto: son genuinamente solo para administradores:
| Configuración | Qué aplica |
|---|---|
allowManagedPermissionRulesOnly | Impide que las configuraciones de usuario y de proyecto definan reglas allow/ask/deny. Solo se aplican las reglas gestionadas. |
allowManagedHooksOnly | Solo se ejecutan los hooks de las configuraciones gestionadas o los plugins habilitados forzosamente. Los hooks de usuario y de proyecto están bloqueados. |
allowManagedMcpServersOnly | Solo se usan los servidores MCP en allowedMcpServers de las configuraciones gestionadas. |
strictKnownMarketplaces | Controla qué marketplaces de plugins pueden añadir los usuarios. Un array vacío bloquea todas las nuevas incorporaciones de marketplaces. |
strictPluginOnlyCustomization | Fuerza que las habilidades, agentes, hooks y/o servidores MCP provengan solo de plugins. |
forceLoginMethod | Restringir el inicio de sesión a cuentas claudeai o cuentas console. |
forceLoginOrgUUID | Requerir inicio de sesión en un UUID de org de Anthropic específico. |
requiredMinimumVersion | Bloquear el inicio si la versión de Claude Code está por debajo de este valor. |
requiredMaximumVersion | Bloquear el inicio si la versión de Claude Code está por encima de este valor. |
claudeMd | Inyectar instrucciones de toda la organización que aparecen en cada sesión. |
channelsEnabled | Habilitar o deshabilitar canales (integraciones) en toda la organización. |
forceRemoteSettingsRefresh | Bloquear el inicio hasta que las configuraciones gestionadas se obtengan nuevamente del servidor. |
La combinación de allowManagedPermissionRulesOnly: true + allowManagedHooksOnly: true te da un perímetro sólido: ningún desarrollador puede ampliar lo que Claude está autorizado a hacer más allá de lo que definen tus configuraciones gestionadas. Todo pasa por reglas y hooks aprobados por IT, nada más.
Sandbox: aislamiento de sistema de archivos y red a nivel del sistema operativo
El sandbox es una capa de seguridad separada de los permisos. Los permisos rigen lo que Claude intenta hacer. El sandbox aplica lo que los comandos Bash pueden alcanzar realmente a nivel del sistema operativo, utilizando el aislamiento de procesos nativo de macOS (Seatbelt) y Linux seccomp/namespaces para aplicar límites de lectura/escritura del sistema de archivos y reglas de acceso a la red.
Una configuración de sandbox base para una máquina de desarrollador:
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": [
"~/.aws/credentials",
"~/.ssh/id_rsa",
"~/.ssh/id_ed25519"
],
"allowWrite": ["/tmp/build", "~/.kube"]
},
"network": {
"allowedDomains": [
"github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com"
]
}
}
}
Con autoAllowBashIfSandboxed: true (el valor predeterminado), los comandos Bash que se mantienen dentro de los límites del sandbox se ejecutan sin solicitar confirmación: el límite del sandbox sustituye a los diálogos de confirmación por comando. Los desarrolladores obtienen un flujo más ágil; tú obtienes la aplicación de la política.
Tres flags de sandbox solo para administradores que vale la pena conocer para entornos más estrictos:
sandbox.network.allowManagedDomainsOnly: true– solo los dominios enallowedDomainsgestionados son accesibles; las adiciones a nivel de proyecto se ignoransandbox.filesystem.allowManagedReadPathsOnly: true– solo se respetan las rutasfilesystem.allowReadgestionadassandbox.network.allowUnixSockets– requerido en macOS para permitir el acceso al socket de Docker (/var/run/docker.sock)
El sandbox se aplica solo a los comandos Bash y sus procesos hijos. No restringe las herramientas integradas de Read/Write de Claude: estas están gobernadas por las reglas de permisos anteriores. Usa ambas capas juntas para la defensa en profundidad: las reglas de permisos evitan que Claude intente acceso no autorizado, y el sandbox previene cualquier cosa que se cuele a nivel del sistema operativo.
Para entornos de contenedores, CI y WSL, consulta la guía de sandboxing de Anthropic: la configuración difiere en esos entornos.
Hooks para la aplicación de políticas
Los Hooks son comandos de shell, endpoints HTTP o prompts evaluados por LLM que se activan en puntos específicos del ciclo de vida. Para uso administrativo, PreToolUse es el evento clave: se activa antes de cualquier llamada a herramienta y puede bloquear la llamada antes de que ocurra, incluso si una regla allow lo permitiría de otro modo.
Un hook de seguridad basado en shell que bloquea comandos destructivos:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "/usr/local/bin/claude-security-check.sh",
"args": []
}
]
}
]
}
}
El hook recibe la llamada completa a la herramienta como JSON en stdin. Para bloquear:
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "rm -rf bloqueado por la política de seguridad de la organización"
}
}
El código de salida 0 sin salida significa "sin decisión": el flujo normal de permisos continúa. El hook puede denegar, pero el silencio no aprueba.
Para políticas centralizadas basadas en HTTP, usa type: "http" para enviar eventos de llamadas a herramientas a tu servicio de seguridad y leer la decisión de la respuesta. Esto permite que un equipo central ejecute la evaluación de políticas sin distribuir scripts de shell a cada máquina de desarrollador.
Otros dos eventos útiles para la gobernanza:
ConfigChange– se activa cuando un archivo de configuración cambia a mitad de sesión. Úsalo para detectar cuándo los desarrolladores modifican sus reglas de permisos durante una sesión, y publica en tu SIEM o Slack para visibilidad.SessionStart– se activa al abrir la sesión. Útil para inyectar metadatos de auditoría, verificar requisitos de versión o confirmar que el usuario está en la red antes de permitir operaciones sensibles.
Con allowManagedHooksOnly: true en las configuraciones gestionadas, solo se ejecutan los hooks implementados a través de tu canal gestionado. Los hooks escritos por desarrolladores en el proyecto .claude/settings.json se ignoran silenciosamente. Consulta la referencia completa de hooks para todos los eventos disponibles.
Configuración de red y proxy
Para entornos que enrutan el tráfico a través de un proxy corporativo, Claude Code lee las variables de entorno estándar de proxy:
HTTPS_PROXY=https://proxy.example.com:8080
HTTP_PROXY=http://proxy.example.com:8080
NO_PROXY="localhost,192.168.1.1,.internal.example.com"
Establécelas en el bloque env de las configuraciones gestionadas para que se apliquen a cada sesión sin configuración por parte del desarrollador:
{
"env": {
"HTTPS_PROXY": "https://proxy.example.com:8080",
"NO_PROXY": "localhost,.internal.example.com"
}
}
Para la inspección TLS empresarial (CrowdStrike Falcon, Zscaler), Claude Code confía tanto en su conjunto de CA de Mozilla incluido como en el almacén de certificados del sistema operativo de forma predeterminada. Si tu proxy usa una CA personalizada que no está en el almacén del sistema operativo:
{
"env": {
"NODE_EXTRA_CA_CERTS": "/etc/ssl/certs/enterprise-ca.pem"
}
}
Para la autenticación TLS mutua:
{
"env": {
"CLAUDE_CODE_CLIENT_CERT": "/etc/ssl/certs/claude-client.pem",
"CLAUDE_CODE_CLIENT_KEY": "/etc/ssl/private/claude-client-key.pem"
}
}
Tu lista de permitidos del firewall necesita como mínimo estas URLs:
| URL | Requerido para |
|---|---|
api.anthropic.com | Llamadas a la API de Claude |
claude.ai | Autenticación de cuenta Claude.ai |
platform.claude.com | Autenticación de cuenta de consola |
downloads.claude.ai | Descargas de plugins y actualizaciones automáticas |
bridge.claudeusercontent.com | Extensión Claude in Chrome |
raw.githubusercontent.com | Notas de versión y marketplace de plugins |
Al implementar a través de Amazon Bedrock, Google Vertex AI o Microsoft Foundry, el tráfico del modelo va a tu proveedor de nube en lugar de a api.anthropic.com. Establece CLAUDE_CODE_USE_BEDROCK=1 (o el equivalente) en el bloque env y configura ANTHROPIC_BEDROCK_BASE_URL si enrutas a través de una puerta de enlace LLM. La configuración completa del proveedor de nube está en la guía de integraciones de terceros de Anthropic.
Gobernanza de MCP y plugins
Los servidores MCP amplían Claude con integraciones de herramientas externas: Jira, Notion, GitHub, bases de datos internas. Desde el punto de vista de la gobernanza, el riesgo es que los desarrolladores se conecten a servidores no confiables o instalen plugins de marketplace no verificados.
Controlar el acceso MCP a través de las configuraciones gestionadas:
{
"allowedMcpServers": [
{ "serverName": "github" },
{ "serverName": "jira" }
],
"deniedMcpServers": [
{ "serverName": "filesystem" }
],
"allowManagedMcpServersOnly": true
}
Con allowManagedMcpServersOnly: true, los archivos .mcp.json del proyecto se ignoran: solo los servidores en la lista de permitidos gestionada se ejecutan. Las entradas de la lista de denegación aún se fusionan de todos los ámbitos, por lo que cualquier ámbito puede bloquear un servidor incluso cuando la lista de permitidos está en vigor.
Controlar los marketplaces de plugins:
{
"strictKnownMarketplaces": [
{ "source": "github", "repo": "acme-corp/approved-claude-plugins" }
],
"blockedMarketplaces": [
{ "source": "github", "repo": "untrusted-org/plugins" }
]
}
strictKnownMarketplaces con una lista específica significa que los desarrolladores solo pueden añadir marketplaces que estén en esa lista. Un array vacío [] bloquea todas las nuevas adiciones de marketplaces por completo. blockedMarketplaces se aplica antes de las operaciones de red o sistema de archivos: las fuentes bloqueadas nunca tocan el disco.
strictPluginOnlyCustomization va más allá, exigiendo que todas las habilidades, agentes, hooks y servidores MCP provengan de plugins en lugar de archivos de usuario o de proyecto:
{
"strictPluginOnlyCustomization": ["skills", "hooks"]
}
Pasa true para bloquear las cuatro superficies (habilidades, agentes, hooks, MCP) o un array con solo los que deseas bloquear. Esto garantiza que toda la personalización de Claude Code en tu organización fluya a través de plugins aprobados y distribuidos en lugar de configuración ad-hoc de los desarrolladores. Consulta la descripción general del plugin de Claude Code para entender el contexto de lo que habilita el sistema de plugins.
CLAUDE.md como contexto para toda la organización
Los archivos CLAUDE.md son la capa de instrucciones: le dicen a Claude qué priorizar, mientras que los archivos de configuración definen qué se le permite hacer. La configuración gestionada claudeMd inyecta instrucciones de toda la organización en cada sesión, independientemente del contenido de CLAUDE.md a nivel de proyecto:
{
"claudeMd": "Siempre ejecuta `make lint` antes de confirmar. Nunca modifiques archivos en /vendor. Seguridad: usa consultas parametrizadas, nunca registres credenciales. Documentación interna en wiki.internal/engineering."
}
A diferencia de un CLAUDE.md a nivel de proyecto que los desarrolladores podrían anular localmente, el claudeMd gestionado no puede ser excluido ni ignorado. Es un canal confiable para los estándares de codificación de toda la organización, los requisitos de seguridad y los enlaces a recursos internos que deben estar presentes en cada sesión.
Para contexto específico del proyecto, confirma CLAUDE.md en la raíz del repositorio: cada colaborador obtiene las mismas instrucciones, y la guía de implementación de Claude Code explica cómo estructurarlos para monorepos grandes. La configuración claudeMdExcludes te permite omitir archivos CLAUDE.md de directorios de vendor o código de terceros que no deseas que contamine el contexto de Claude.
Monitorear el uso de Claude Code
Claude Code exporta telemetría a través de OpenTelemetry, que se integra con cualquier stack compatible con OTLP: Datadog, Honeycomb, Grafana:
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_ENDPOINT": "https://your-collector:4318",
"OTEL_RESOURCE_ATTRIBUTES": "service.name=claude-code"
}
}
Las métricas disponibles incluyen actividad de sesión, recuentos de uso de herramientas por tipo, uso del modelo y tasas de error. Para las sesiones en la nube, todas las operaciones se registran automáticamente para el cumplimiento.
El hook ConfigChange (descrito anteriormente) proporciona señales en tiempo real cuando los archivos de configuración cambian a mitad de sesión. Combinándolo con tu SIEM obtienes un rastro de auditoría de las modificaciones de configuración.
Para los informes de uso a nivel de equipo, el blog usage-analytics-claude-code tiene una guía completa sobre la configuración de análisis de uso de Claude Code, incluidas las métricas OTLP disponibles y lo que cada una te indica.
Teams vs Enterprise: lo que cada plan añade para los administradores
| Capacidad | Teams | Enterprise |
|---|---|---|
| Configuraciones de proyecto (.claude/settings.json) | Sí | Sí |
| Configuraciones gestionadas basadas en MDM/archivo | Sí | Sí |
| Configuraciones gestionadas por servidor (push de consola de administración) | Limitado | Completo |
| SSO y captura de dominio | No | Sí |
Aplicación de forceLoginOrgUUID | No | Sí |
| Configuraciones de políticas gestionadas para toda la organización | Parcial | Completo |
| Control remoto y controles de administrador de sesión web | Sí | Sí |
| Acceso a la API de cumplimiento (SOC 2 / ISO 27001) | No | Sí |
| Panel de uso centralizado | Sí | Sí |
| Soporte dedicado / SLA | No | Sí |
Para implementar Claude Code en equipos de aproximadamente menos de 50 personas, Claude for Teams con configuraciones gestionadas basadas en archivos o MDM generalmente cubre lo esencial. Enterprise añade SSO, forceLoginOrgUUID para aplicar la membresía a la organización, y configuraciones gestionadas por servidor enviadas desde una consola central: la opción adecuada para organizaciones con Active Directory, Okta o gestión de identidades similar, o con requisitos de cumplimiento que necesitan documentación del Anthropic Trust Center (SOC 2 Tipo 2, ISO 27001 ambos certificados a partir de 2026).
La guía completa de Claude Code empresarial cubre la adquisición, el aprovisionamiento de usuarios y los pasos de configuración de SSO.
Una plantilla de inicio rápido para las configuraciones gestionadas
Aquí hay una managed-settings.json base que cubre lo esencial para la mayoría de las organizaciones de ingeniería conscientes de la seguridad. Impleméntala en /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux), o envíala a través de MDM/Directiva de grupo:
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git status)",
"Bash(git stash *)",
"Bash(make *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(//home/**/.ssh/*)",
"Read(//root/.ssh/*)"
],
"disableBypassPermissionsMode": "disable"
},
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": [
"~/.aws/credentials",
"~/.ssh/id_rsa",
"~/.ssh/id_ed25519",
"~/.ssh/id_ecdsa"
]
},
"network": {
"allowedDomains": [
"github.com",
"*.github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com",
"*.anthropic.com"
]
}
},
"claudeMd": "Sigue el CLAUDE.md del proyecto para los estándares de codificación. Nunca registres credenciales, tokens o secretos. Usa consultas parametrizadas. Documentación interna: wiki.internal/engineering",
"companyAnnouncements": [
"La política empresarial de Claude Code se aplica a todas las sesiones. Preguntas: security@yourcompany.com"
],
"requiredMinimumVersion": "2.1.100",
"availableModels": ["opus", "sonnet", "haiku"]
}
Esta plantilla cierra --dangerously-skip-permissions, bloquea las lecturas de claves SSH y credenciales de AWS, habilita el sandbox con Bash sandboxed aprobado automáticamente, restringe la red de salida a dominios aprobados, inyecta una política de seguridad mínima y fija una versión mínima.
Después de ejecutar esto durante una semana y auditar lo que tus desarrolladores realmente necesitan en la lista de permitidos, considera añadir "allowManagedPermissionRulesOnly": true para el bloqueo más estricto posible. Esa configuración se omite aquí intencionalmente: solo debe añadirse después de que estés seguro de que la lista de permitidos cubre el flujo de trabajo real de tu equipo.
La referencia completa de settings.json cubre todas las ~80 claves disponibles si necesitas ajustar más, y la guía de mejores prácticas de Claude Code cubre la configuración del lado del desarrollador que complementa esta capa de administración.
Prueba eesel.ai
Si estás pensando detenidamente en la gobernanza de IA para tu organización de ingeniería, probablemente estés respondiendo las mismas preguntas en soporte, operaciones y otros equipos. eesel.ai implementa agentes de IA autónomos directamente dentro de las herramientas que esos equipos ya usan: Zendesk, Freshdesk, Slack, Jira y más de 100 más, con el mismo enfoque que el sistema de permisos de Claude Code: los agentes operan dentro de límites claros que tú configuras, el equipo mantiene el control sobre lo que pueden y no pueden hacer, y la configuración lleva minutos desde el historial de conocimiento existente. Sin nueva interfaz que adoptar, sin necesidad de ingeniería de prompts.
Preguntas frecuentes
¿Cómo evito que los desarrolladores usen --dangerously-skip-permissions en Claude Code?
permissions.disableBypassPermissionsMode en "disable" en tus configuraciones gestionadas de Claude Code. Dado que las configuraciones gestionadas están en la cima de la pila de precedencia, no pueden ser anuladas por ninguna configuración de usuario o proyecto, ni siquiera por argumentos de línea de comandos. Consulta la referencia de permisos de Anthropic para ver la sintaxis completa.¿Cuál es la diferencia entre las configuraciones gestionadas de Claude Code y las configuraciones de proyecto?
.claude/settings.json, se confirman en git y se aplican a todos los colaboradores del repositorio, pero pueden ser anuladas por configuraciones locales o de usuario. Usa configuraciones gestionadas para la política de cumplimiento; usa configuraciones de proyecto para las convenciones del equipo.¿Puedo restringir qué modelos de Claude pueden usar los desarrolladores en Claude Code?
availableModels a tus configuraciones gestionadas para limitar qué modelos pueden seleccionar los usuarios mediante /model o --model, por ejemplo ["sonnet", "haiku"] para excluir Opus. Combínalo con la clave model para establecer un valor predeterminado específico para toda la organización. Para implementaciones de Bedrock o Vertex, la variable de entorno ANTHROPIC_DEFAULT_SONNET_MODEL fija versiones exactas del modelo.¿Cómo implemento los controles de administrador de Claude Code en todas las máquinas de los desarrolladores?
com.anthropic.claudecode), Directiva de grupo de Windows o Intune (escribiendo JSON en HKLM\SOFTWARE\Policies\ClaudeCode), o un archivo colocado en /Library/Application Support/ClaudeCode/managed-settings.json en macOS o /etc/claude-code/managed-settings.json en Linux. Los tres leen el mismo formato JSON. Para configuraciones gestionadas por servidor en planes Team/Enterprise, usa la consola de administración.¿Qué hace allowManagedPermissionRulesOnly en los controles de administrador de Claude Code?
true en las configuraciones gestionadas, impide que las configuraciones de usuario y proyecto definan reglas de allow, ask o deny de permisos. Solo se aplican las reglas en tus configuraciones gestionadas. Este es el bloqueo de permisos más estricto disponible: útil cuando la política de seguridad requiere que ningún desarrollador pueda auto-autorizar una herramienta que Claude Code no ha sido pre-aprobado para usar.
