La mayoría de los sistemas de permisos para agentes de programación se basan en listas de permitidos: leer archivos sí, escribir archivos sí, ejecutar pruebas sí, para todo lo demás preguntar. Esto funciona hasta que alguien marca un agente como «totalmente de confianza» para detener los prompts, y el agente ejecuta un git push --force un viernes.
Nuestra postura es que cuatro categorías de acciones deben detenerse ante un humano siempre, independientemente de cuánta confianza se tenga en el agente o en quien realiza la solicitud. Los niveles de confianza deciden cuántas otras cosas necesitan aprobación. Estas cuatro nunca se ejecutan en silencio.
Las cuatro
1. Hacer push a una rama compartida. Un commit en una rama de funcionalidad es una sugerencia. Un push a main o a release es una decisión que hereda todo el equipo, a menudo con un despliegue asociado. Es una acción barata de consultar y costosa de revertir.
2. Borrar. Archivos, ramas, tablas, buckets, recursos. La eliminación es la única operación en la que una suposición equivocada sobre la intención no se puede deshacer con una segunda suposición. Los agentes son decididos, y una eliminación con total seguridad es la forma en que se ponen a prueba las copias de seguridad.
3. Gastar dinero. Llamar a una API de pago, aprovisionar un recurso, comprar un dominio, enviar una campaña. Puede que quien hizo la solicitud no sepa que tiene un coste. Quien paga sí debería saberlo.
4. Tocar credenciales. Leer un archivo de claves, exportar variables de entorno, iniciar sesión en un servicio, completar una autenticación de dos factores. Cualquier cosa aquí afecta a la identidad, y la identidad pertenece al propietario de la máquina, no a quienquiera que esté en la sala.
Por qué el modo «totalmente de confianza» aún debería pausarse aquí
Un modo de permisos describe la relación de una persona con el agente: solo lectura, editar pero no hacer push, o confianza total. Esa es la granularidad adecuada para los cientos de llamadas ordinarias que un agente hace en una sesión. Es la granularidad incorrecta para las cuatro anteriores, porque son raras, irreversibles o caras, y porque el coste recae sobre alguien distinto de quien hace la solicitud.
Así que la regla en muti es simple: ninguna plantilla de permisos puede configurar estas cuatro acciones para que se ejecuten en silencio. Incluso en el modo de «confianza total», se detienen y se destacan en el timeline. El prompt es lo bastante infrecuente como para no resultar molesto, y las categorías son lo suficientemente precisas como para que la respuesta suela ser obvia.
Cómo encaja esto con los modos de permisos de Claude Code
Claude Code ya cuenta con una escala: plan (solo lectura), default (preguntar antes de ediciones y comandos), acceptEdits (las ediciones se ejecutan, los comandos preguntan) y bypassPermissions (nada pregunta). Esos modos describen cuánto te pregunta el agente a ti. Las cuatro acciones describen qué debe preguntarse al propietario cuando otra persona hace la solicitud. Se superponen.
La última columna es el añadido de la sala y es idéntica en cada fila. Consulta permission modes, explained.
A quién se debe preguntar
Esta es la parte que la mayoría de los diseños pasa por alto. Cuando un agente compartido necesita a un humano, ¿a qué humano?
- Las credenciales van al propietario. Los inicios de sesión, los códigos de dos factores y el acceso a claves atañen a la identidad del propietario. Se dirigen a él sin importar quién inició la tarea. Quien hizo la solicitud ve que se ha producido una toma de control, no el secreto.
- Las preguntas sobre la intención van a quien hizo la solicitud. «¿Te referías a la base de datos de staging?» tiene que ver con lo que la persona quería. Se dirige a quien hizo la petición.
- Ambos ven el mismo timeline. Ninguno tiene que transmitir contexto al otro; la pregunta y su respuesta se ubican en el mismo hilo que el trabajo.
Credential and dangerous-action prompts route to the owner; intent questions route to the requester; both see the exchange.
Anatomía de una buena tarjeta de aprobación
Una aprobación sobre la que se puede decidir en cinco segundos consta de cinco partes.
Ofrécele tres botones: aprobar, rechazar y continuar en solo lectura. El tercero está infravalorado: permite que el trabajo continúe mientras el paso arriesgado espera.
Permite que las aprobaciones se respondan desde cualquier lugar donde ya esté el propietario: la consola, el teléfono o una tarjeta en una plataforma de chat. Decidir en un lugar debe aplicarse en todas partes. Establece una fecha de caducidad para que una tarjeta olvidada no se ejecute una semana después.
La fatiga por aprobaciones es el verdadero enemigo
Cada prompt entrena a la persona que lo ve. Si hay demasiados, buscará el ajuste para desactivarlos. Tres cosas mantienen la frecuencia baja sin relajar las cuatro reglas.
- Limita el alcance del agente. Un directorio de trabajo por agente significa menos archivos que podría tocar y menos avisos para intervenir.
- Usa los modos ordinarios para llamadas ordinarias. Solo lectura para explorar, editar sin hacer push para la mayor parte del trabajo. Reserva la «confianza total» para personas que, de otro modo, estarían tecleando en tu teclado.
- Haz que las plantillas predeterminadas sean transparentes. Incluye configuraciones predefinidas como solo lectura, editar pero no hacer push y confianza total con nombres claros, para que nadie tenga que diseñar una política desde cero y equivocarse.
La línea de auditoría
Cada solicitud y cada aprobación deberían generar una línea que el propietario pueda exportar: quién preguntó, quién decidió, cuándo, qué regla, qué sucedió y qué se utilizó. No porque nadie lo lea a diario, sino porque el día en que algo sale mal no es el momento de empezar a registrar.
Preguntas frecuentes
¿Preguntar cada vez no ralentiza al agente? Solo para estas cuatro categorías, que son raras en una sesión normal. El coste de la pausa son segundos; el coste del error se mide en horas o en dinero.
¿Qué ocurre si el propietario usa su propio agente? El propietario no está sujeto a los modos de permisos en su propio agente, pero las cuatro acciones se siguen registrando en el timeline para que el historial esté completo.
¿Puede quien hizo la solicitud aprobarla por sí mismo? No. La aprobación corresponde al propietario de la máquina. Quien hizo la solicitud puede cancelar, reintentar o añadir contexto.
Las salas en muti vienen con estas reglas activadas y sin forma de desactivarlas. Si te parece la configuración predeterminada correcta, dale una sala a tu agente.
Publicado el · Actualizado el