Permisos por diseño: qué permite, pregunta y bloquea Claude Code

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

Al terminar esta lección podrás explicar cómo Claude Code clasifica las operaciones, configurar qué acciones requieren aprobación y mostrarle a un cliente dónde está la frontera de permisos.

Permitir, preguntar o denegar

Claude Code no pide permiso para todo. Pide lo que corresponde.

Antes de configurar cualquier regla de permisos, Claude Code opera sin clasificación. Eso dificulta auditar lo que se ejecutó y acotar el radio de impacto cuando algo sale mal.

Operación	Antes	Después
Ejecutar tests	Sin control	Permitir (allow)
git push	Sin control	Preguntar (ask)
rm -rf	Sin control	Denegar (deny)

Antes

• Todas las operaciones se ejecutan sin clasificar.
• No hay pista de auditoría para las acciones sensibles.
• Es difícil acotar el alcance de un fallo si algo sale mal.
• Los desarrolladores no saben qué puede hacer Claude de forma autónoma.

Después

• Las operaciones se clasifican en permitir, preguntar o denegar.
• El comportamiento es predecible dentro de límites definidos.
• Toda acción sujeta a control es auditable.
• Los desarrolladores saben exactamente dónde termina su autonomía.

La clasificación permitir / preguntar / denegar se define en los archivos de ajustes y se bloquea mediante managed-settings.json con allowManagedPermissionRulesOnly: true. Una vez bloqueada, los usuarios no pueden reclasificar operaciones por su cuenta.

El principio: permite el trabajo no destructivo y de alta frecuencia; pregunta por las acciones irreversibles y las llamadas de red externas; deniega lo que no tiene ningún motivo legítimo para ejecutarse.

flowchart LR
    OP["Operación"] --> AL["Permitir (allow)<br/>no destructiva y de alta frecuencia, por ejemplo una lectura local"]
    OP --> AS["Preguntar (ask)<br/>irreversible o llamada de red externa"]
    OP --> DE["Denegar (deny)<br/>catastrófica o sin motivo legítimo para ejecutarse"]

Quién controla qué

Anthropic controla el suelo del modelo. Tú configuras todo lo que está por encima.

Capa	Responsable	Qué incluye	En una revisión de seguridad
Seguridad del modelo	Anthropic	IA constitucional, entrenamiento de seguridad RLHF, rechazo a nivel de pesos y aplicación de la política de uso. Ningún cliente puede desactivarla ni reconfigurarla.	Es la línea que señalas cuando un cliente pregunta si puede debilitar el comportamiento de seguridad del modelo. No puede, y eso es una característica, no una carencia.
Integridad de la plataforma	Anthropic	Clasificadores en tiempo de ejecución, evaluación previa al lanzamiento y protecciones a nivel de plataforma. Se aplican de forma universal, no por tenant.	Se aplica igual a todos los tenants. El cliente no lo configura ni lo ve, así que no pertenece a su sección del cuestionario.
Control de operaciones	Cliente	Reglas de permitir, preguntar y denegar; control de acceso basado en roles; consentimiento de conectores; políticas de permisos. Configurable mediante managed settings.	Aquí es visible tu trabajo como consultor. El modelo de permitir / preguntar / denegar y quién puede cambiarlo es el núcleo de la sección del cliente.
Auditoría y gobernanza	Cliente	Managed settings, SSO y SCIM, ventanas de retención de datos, acceso a la Compliance API y flujos de revisión.	Se corresponde directamente con los requisitos innegociables de FinCo: SSO con Okta, trazabilidad y la revisión por escrito. Cada uno tiene un control configurable aquí.

flowchart TB
    subgraph ANT["Anthropic controla"]
        A1["Seguridad del modelo"]
        A2["Integridad de la plataforma"]
    end
    subgraph CLI["El cliente configura"]
        C1["Control de operaciones"]
        C2["Auditoría y gobernanza"]
    end

Usa esta división en dos bloques cuando un cliente pregunte quién es responsable de qué en una revisión de seguridad. La capa de Anthropic no se puede desactivar. La capa del cliente es donde se hace visible tu trabajo como consultor.

Roles y consentimiento

El control de acceso basado en roles define quién puede configurar Claude Code. El consentimiento de conectores define a qué puede conectarse.

Primary Owner

Control total de la organización, gestión de facturación y acceso a todos los ajustes. Es el asiento de administración para el responsable del proyecto (engagement).

Quién lo tiene en FinCo: normalmente, una persona responsable del lado del cliente. Hay un único Primary Owner por organización, así que es el asiento de quien responde por todo el despliegue.

Owner

Gestión de miembros, aprobación de conectores y configuración de managed settings. Es el rol operativo de administración para la gobernanza del día a día.

Quién lo tiene en FinCo: el equipo de seguridad o de plataforma que gestiona la gobernanza diaria. Es el rol que realmente edita managed-settings.json y aprueba conectores.

Member

Puede usar Claude Code y configurar ajustes personales dentro de los límites que fijó el administrador. No puede anular managed settings.

Quién lo tiene en FinCo: los 1.800 desarrolladores. Trabajan libremente dentro de las barreras, pero no pueden aflojarlas, que es exactamente lo que exigen los requisitos innegociables del equipo de seguridad.

Consentimiento de conectores (connector consent)

Las conexiones MCP con OAuth requieren aprobación del Owner antes de activar el acceso a recursos por usuario. Es una puerta de gobernanza adicional sobre la lista de permitidos de MCP.

Por qué es independiente: la lista de permitidos dice qué servidores pueden existir; el consentimiento gobierna si los recursos de un usuario concreto pueden realmente ser accedidos. Son dos puertas, no una.

En el modelo de dos bloques, el Owner controla los ajustes del archivo managed-settings.json, y los usuarios no pueden anularlos. El Primary Owner controla los ajustes que los usuarios pueden configurar dentro de los límites que fija el Owner. Cuando un cliente pregunte «¿quién puede cambiar esto?», la respuesta es: si está en managed settings, solo puede cambiarlo el Owner; si es un ajuste configurable por el usuario, este puede cambiarlo, pero solo dentro de las restricciones que el Owner ya haya establecido.

Roles personalizados y grupos

Los cuatro roles predeterminados son un punto de partida. Los roles personalizados y los grupos son la forma de gobernar a escala.

Los administradores pueden crear roles más allá de los cuatro predeterminados y asignarlos a grupos. La distinción entre roles y grupos es lo que evita que un despliegue acumule permisos no previstos con el tiempo.

Roles

• Definen qué puede hacer un usuario dentro de Claude.
• Hay cuatro roles integrados: Primary Owner, Owner, Admin y Member.
• Los administradores pueden crear roles personalizados además de estos.
• Los roles son acumulativos: un usuario en varios grupos acumula todos los roles de cada uno. Asígnalos con intención.

Grupos

• Son colecciones de usuarios.
• Son multipropósito, no solo control de acceso.
• Gobiernan los límites de gasto por equipo o departamento.
• Controlan qué plugins se distribuyen a qué usuarios.
• Se crean manualmente o se sincronizan desde tu IDP mediante SCIM.

Como los roles se acumulan, asignar grupos en exceso genera una acumulación de permisos no previstos. La pregunta correcta en la mayoría de los despliegues no es «¿qué rol necesita esta persona?», sino «¿qué grupo es responsable de esta función, y pertenece a él esta persona?».

La forma más directa, hoy, de controlar a qué conectores y skills puede acceder un grupo es empaquetar las herramientas aprobadas en un plugin empresarial y asignar ese plugin a los grupos correspondientes mediante RBAC. Así funciona a escala el control de acceso del Día 1: los ingenieros reciben por defecto conectores preaprobados, gobernados y desplegados antes de que nadie inicie sesión.

En la hoja de ruta

Los controles de conector a nivel de rol (la capacidad de restringir qué roles pueden usar un conector específico, o qué capacidades dentro de él) todavía no están disponibles. El modelo previsto empieza con el acceso activado o desactivado por conector y después añade capacidades acotadas dentro de cada uno. Cuando un cliente pregunte si puede controlar el acceso a conectores por rol, indícale que está previsto y usa el patrón plugin + RBAC como camino actual.

Comprueba tu comprensión

Clasificador de operaciones

Elige una categoría para cada operación. El razonamiento aparece en cualquier caso.

1. Ejecutar la suite de tests después de guardar un archivo (npm test)

Ver respuesta

Permitir. No destructiva y de alta frecuencia. Controlarla interrumpiría al desarrollador constantemente sin reducir el riesgo real.

2. Leer un archivo fuente para incluirlo en el contexto (cat src/app.js)

Ver respuesta

Permitir. Una lectura local es reversible y no tiene radio de impacto. Es exactamente el tipo de operación que debe ejecutarse en silencio.

3. Hacer push de commits al repositorio compartido (git push origin)

Ver respuesta

Preguntar. Un push es irreversible y va a un repositorio compartido. FinCo necesita que cada una de estas acciones tenga una aprobación deliberada y trazable, así que se controla, no se bloquea.

4. Llamar a una API externa en el primer uso (POST api.jira)

Ver respuesta

Preguntar. Una llamada de red sale del entorno local. Incluso una integración rutinaria merece confirmación en la primera ejecución, para que el límite siga siendo visible y auditable.

5. Borrar por la fuerza un árbol de directorios (rm -rf /)

Ver respuesta

Denegar. Catastrófica e irreversible, sin lugar legítimo en un flujo de trabajo asistido. Denegar elimina la opción por completo en lugar de depender de que alguien lea con atención un aviso de aprobación.

Actividad: verdadero o falso

Indica si cada enunciado es verdadero o falso y despliega la respuesta para comprobarla.

«Un usuario con rol Member puede configurar su propio archivo settings.json personal.»

Ver respuesta

Verdadero. Los Member controlan su capa de ajustes personal. No pueden anular managed settings ni los ajustes compartidos del proyecto en los que no tienen permiso de escritura. La capa gestionada está por encima de todo lo que el individuo puede tocar.

«Un administrador puede usar managed-settings.json para impedir que los usuarios definan sus propias reglas de permitir y denegar.»

Ver respuesta

Verdadero. Definir allowManagedPermissionRulesOnly: true bloquea el modelo de permisos a las reglas definidas por el administrador. Los usuarios ya no pueden añadir ni modificar sus propias entradas de permitir, preguntar o denegar.

«Claude Code siempre pide aprobación del usuario antes de ejecutar cualquier comando bash.»

Ver respuesta

Falso. Las operaciones de la categoría permitir se ejecutan en silencio. Solo las clasificaciones de preguntar y denegar disparan un aviso o un bloqueo. El valor de la gestión de permisos está en la clasificación deliberada, no en preguntar por todo.

«En Claude Enterprise, los grupos funcionan únicamente como contenedores de control de acceso: un grupo corresponde a un único conjunto de permisos.»

Ver respuesta

Falso. Los grupos son multipropósito. Gobiernan el acceso mediante roles, controlan los límites de gasto por equipo o departamento y determinan qué plugins se distribuyen a cada usuario. Un grupo incluso puede crearse solo para atribuir gasto, sin asignarle ningún rol.

El modelo de permisos es por capas: Anthropic fija el suelo, el administrador establece la política mediante managed settings y los usuarios operan dentro de esa política. Se trata de que el límite sea deliberado y auditable.

Escenario: clasifica las tres operaciones

Un desarrollador de FinCo tiene tres operaciones recurrentes en su flujo de trabajo estándar: ejecutar automáticamente la suite de tests después de guardar archivos, hacer push de commits al host corporativo de GitLab y llamar a una API interna de Jira para actualizar el estado de un ticket. En un despliegue estándar de Claude Code para FinCo, ¿cómo clasificarías estas tres operaciones?

• A · Las tres como permitir. Las operaciones estándar de los desarrolladores deben ejecutarse sin interrupciones.
• B · Tests como permitir, push a GitLab como preguntar y llamada a Jira como preguntar. Controla las acciones irreversibles y las llamadas de red; deja correr libremente las automatizaciones seguras.
• C · Tests como permitir, push a GitLab como permitir y llamada a Jira como preguntar. Deja correr las operaciones de solo lectura y locales; controla las llamadas a APIs externas.
• D · Las tres como preguntar. Exige aprobación para cada operación, para mantener la cobertura de auditoría.

Ver respuesta

A · Incorrecta: permitir los push de git sin confirmación crea una brecha de auditoría para operaciones irreversibles. El requisito innegociable de FinCo es que cada acción sea trazable. Un push que sale sin aprobación no puede deshacerse, y no queda registro de una aprobación deliberada. Las llamadas de red a APIs externas también merecen confirmación en el primer uso.

B · Correcta. Las ejecuciones de tests son seguras de automatizar porque no son destructivas y son de alta frecuencia. Los avisos de aprobación constantes romperían el flujo de trabajo. Los push de git son irreversibles y deben confirmarse. La llamada a la API de Jira va por la red a un servicio externo, así que merece preguntar en la primera ejecución, aunque sea una operación habitual.

C · Parcial (casi correcta): los push a GitLab deben ser preguntar, no permitir. Un push es irreversible y va a un repositorio compartido. El trabajo del consultor es asegurar que el modelo de permisos refleje el riesgo real: un push a un repositorio compartido es irreversible, por eso se controla.

D · Incorrecta: exigir aprobación para cada operación anula el propósito del desarrollo asistido por IA. El objetivo es poner controles donde importan: en las acciones irreversibles y en las llamadas de red externas. Sobre-permisionar en preguntar genera fatiga de alertas y hace que los desarrolladores aprueben sin leer.

Ideas clave

• Clasificar cada operación en permitir, preguntar o denegar hace que el límite sea deliberado y auditable. Sin clasificación no hay rastro ni forma de acotar un fallo.
• Permite lo no destructivo y de alta frecuencia, pregunta por las acciones irreversibles y las llamadas de red externas, y deniega lo que no tiene motivo legítimo para ejecutarse.
• Anthropic fija el suelo del modelo y no puede desactivarse; el cliente configura el control de operaciones y la auditoría y gobernanza.
• Los roles definen qué puede hacer cada usuario y se acumulan; los grupos son multipropósito, así que asignarlos en exceso genera permisos no previstos.
• La lista de permitidos de MCP y el consentimiento de conectores son dos puertas distintas; los controles de conector por rol todavía están en la hoja de ruta.

Siguiente: Bash aislado y alcance del sistema de archivos