Configurar barandillas

Esta guía te muestra cómo configurar barandillas: las reglas que deciden si la acción de un agente se ejecuta, si pide aprobación primero o si se deniega.

Las barandillas cubren las trece clases de efecto que declara toda herramienta que modifica el estado. Se aplican del lado del servidor, en el punto en que se llama a la herramienta, nunca mediante una instrucción en un prompt.

Define una decisión para una clase de acción

Ve a Ajustes → Espacio de trabajo → Permisos de agentes
Elige un ámbito con el control segmentado: Espacio de trabajo, Agente (y luego elige el agente) o Espacio (y luego elige el espacio)
En la fila de la clase de acción, elige Permitir, Preguntar primero o Denegar
Para descartar una regla que definiste, presiona el botón de restablecer que aparece al final de esa fila (Restablecer al valor heredado); la decisión vuelve al ámbito más amplio

Cada fila muestra la decisión efectiva como una etiqueta de estado y una insignia que indica de dónde proviene: Este ámbito, Heredado o Valor predeterminado. La matriz se resuelve en el modo Agente (chat), así que Preajuste del modo nunca aparece aquí; usa la sonda «¿Qué pasaría si?» con un modo de solo lectura seleccionado para ver esa capa.

Escribir una regla requiere el rol admin. Leer la matriz, no.

Punto de control: define Enviar a un remoto como Denegar en el ámbito del espacio de trabajo y luego ejecuta la sonda «¿Qué pasaría si?» de abajo sobre git push origin main. El resultado indica deny con el origen workspace.

Entiende cómo se resuelve una decisión

La resolución es primero la especificidad, luego la restrictividad:

Primero las reglas de Espacio, luego las de agente y luego las del espacio de trabajo. El primer ámbito con una regla coincidente decide y la resolución se detiene
Si ninguna regla coincide, se aplica el preajuste del modo: un modo de solo lectura (Plan, Revisión, Orquestación) deniega once de las trece clases
Si el modo no tiene nada que decir, se aplica el valor predeterminado integrado

Dentro de un mismo ámbito, una regla de comando se resuelve por el prefijo coincidente más largo, y un conflicto igual de específico se resuelve como el más restrictivo: denegar gana a preguntar primero, y preguntar primero gana a permitir. Una acción que declara varias clases resuelve cada una de forma independiente y luego las combina aplicando la más restrictiva.

Una decisión de Preguntar primero muestra una sola solicitud de aprobación que cubre todas las clases que se resolvieron como prompt. Si no hay ningún aprobador conectado, se deniega, tanto para comandos de shell como para llamadas a herramientas del arnés. Es a propósito: una ejecución sin compuerta es peor que una rechazada.

Clases de acción y valores predeterminados integrados

Clase de acción	Valor predeterminado integrado
Eliminar un archivo	Preguntar primero
Escribir fuera del árbol de trabajo	Permitir
Crear un commit	Permitir
Enviar a un remoto	Preguntar primero
Abrir una pull request	Preguntar primero
Publicar una revisión o fusionar	Preguntar primero
Escribir en un rastreador externo	Preguntar primero
Acceder a la red	Permitir
Leer un secreto	Permitir
Instalar un paquete	Permitir
Ejecutar un proceso	Permitir
Cambiar la estructura del espacio de trabajo	Permitir
Controlar un recinto (rig)	Permitir

La taxonomía es cerrada. Una herramienta nueva que se publique sin declarar sus clases falla una prueba de trinquete en CI, así que nada llega con un conjunto de efectos vacío en silencio.

Prueba una regla con la sonda «¿Qué pasaría si?»

Antes de cambiar una regla, verifica cómo la resuelve ya la política actual.

En la misma página, desplázate hasta ¿Qué pasaría si?
Elige una Acción (una de las trece clases)
De manera opcional, completa Comando (por ejemplo git push origin main), Agente, Espacio y Modo
Lee el resultado: la decisión, el motivo y Origen:

La sonda ejecuta, sobre tus reglas activas, el mismo resolutor que usa la ruta que aplica las reglas, así que la respuesta es exacta. Si te sorprende, cambia una regla en la matriz de arriba y vuelve a sondear.

Ajusta el control de autonomía de un espacio

El control es por agente y por espacio, y se combina con las reglas en lugar de reemplazarlas.

Abre el espacio
Abre Gestionar participantes desde el encabezado del espacio
En Autonomía, en la fila del agente, elige un nivel:

Nivel	Efecto
Predeterminado	Sin ajuste en el espacio: se comporta como Actuar con aprobación
Solo proponer	Toda herramienta con compuerta se deniega de plano, con un mensaje que le pide al agente proponer la acción en su lugar
Actuar con aprobación	Las acciones riesgosas llegan a la compuerta de aprobación, que deniega ante cualquier falla
Actuar libremente	Preaprueba todo lo que no se haya resuelto como una denegación estricta

El control solo llega al arnés integrado. El adaptador de Claude Code ejecuta sus propias herramientas fuera de esta compuerta.

Conoce hasta dónde no llegan las barandillas

La tabla Dónde se aplican las reglas, al final de la misma página, es la versión dentro de la aplicación de esto: por cada clase de efecto, indica si cada ejecutor la intercepta en el control por política, la deja al sandbox o no puede interceptarla en absoluto.

El adaptador de Claude Code solo tiene compuerta en parte de sus propias llamadas a herramientas. Claude Code se inicia con --dangerously-skip-permissions, así que sus llamadas de lectura, escritura y edición nunca pasan por las barandillas. Sus comandos de bash llegan a ellas mediante un hook que clasifica la línea de comandos, y sus push pasan por la pasarela de push como los de cualquier agente. También quedan sujetos a compuerta la superficie de herramientas MCP a la que llama de vuelta y el comando de shell que Control Center lanza para iniciarlo.
El propio verbo de salida de un modo (submit_plan, propose_orchestration) está fijado y nunca se puede denegar; de lo contrario, un modo sería estructuralmente incapaz de producir su único entregable.
Que el sandbox respalde estas reglas depende del host. Donde cc_server encuentra un backend, envuelve la CLI de Claude Code y la herramienta bash del arnés, así que una regla que tú no escribiste igual tiene un piso del sistema operativo debajo. En Windows no hay ninguno, y en Linux o WSL2 sin bwrap y socat tampoco lo hay: ahí, las barandillas más la superficie de herramientas del modo son toda la aplicación de las reglas, no una segunda línea de defensa. Verifica en qué caso estás con Configurar políticas de sandbox.