Configurar barandillas

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

Las barandillas cubren las trece clases de efecto que declara toda herramienta que muta el sistema. Se aplican en el servidor, en el momento en que se llama a la herramienta, nunca mediante una instrucción en un prompt.

Definir 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 eliminar una regla que hayas definido, pulsa el botón de restablecimiento 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 procede: Este ámbito, Heredado o Valor predeterminado. La matriz se resuelve en el modo Agent (chat), así que Preajuste del modo nunca aparece aquí: usa la sonda de hipótesis 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 de hipótesis de más abajo sobre git push origin main. El resultado indica deny con origen workspace.

Entender cómo se resuelve una decisión

La resolución es primero por especificidad y luego por restrictividad:

Primero las reglas de Espacio, después las de agente y después las de espacio de trabajo. El primer ámbito con una regla coincidente decide y la resolución se detiene
Si no coincide ninguna regla, se aplica el preajuste del modo: un modo de solo lectura (plan, revisión, orquestación) rechaza once de las trece clases
Si el modo no tiene nada que decir, se aplica el valor predeterminado

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 por lo más restrictivo: denegar gana a preguntar primero, que gana a permitir. Una acción que declara varias clases resuelve cada una de forma independiente y luego las combina por lo más restrictivo.

Una decisión de Preguntar primero muestra un único aviso 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 deliberado: una ejecución sin control es peor que una rechazada.

Clases de acción y valores predeterminados

Clase de acción	Valor predeterminado
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 hace fallar en CI una prueba de trinquete, así que nada llega con un conjunto de efectos vacío en silencio.

Probar una regla con la sonda de hipótesis

Antes de cambiar una regla, comprueba 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)
Rellena opcionalmente Comando (por ejemplo git push origin main), Agente, Espacio y Modo
Lee el resultado: la decisión, el motivo y Origen:

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

Definir el dial de autonomía de un espacio

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

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 de espacio: se comporta como Actuar con aprobación
Solo proponer	Toda herramienta controlada se deniega de plano, con un mensaje que indica al agente que proponga la acción en su lugar
Actuar con aprobación	Las acciones de riesgo pasan por la puerta de aprobación que deniega por defecto
Actuar libremente	Preaprueba todo lo que no se haya resuelto como denegación firme

El dial solo llega al arnés integrado. El adaptador Claude Code ejecuta sus propias herramientas al margen de esta puerta.

Saber dónde no llegan las barandillas

La tabla Dónde se aplican las reglas que aparece al final de la misma página es la versión integrada de esto: para cada clase de efecto, indica si cada ejecutor la intercepta en la puerta de política, la deja en manos del entorno aislado o no puede interceptarla en absoluto.

El adaptador Claude Code solo está sujeto a control 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 la guardia. Sus comandos de bash llegan a ella 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 están controlados 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 entorno aislado respalde estas reglas depende del host. Cuando cc_server encuentra un backend, envuelve la CLI de Claude Code y la herramienta bash del arnés, de modo que una regla que tú no escribiste sigue teniendo una base del sistema operativo por debajo. En Windows no hay ninguna, y en Linux o WSL2 sin bwrap y socat tampoco: allí, las barandillas junto con la superficie de herramientas del modo constituyen todo el control existente, no una segunda línea de este. Comprueba en qué caso estás con Configurar políticas del entorno aislado.