UX de permisos para agentes: cómo mostrar y ajustar lo que el agente puede hacer
La UX de permisos para agentes define cómo una persona entiende y ajusta lo que puede hacer un agente de IA: modos, reglas, alcance de las decisiones y errores.
¿Por qué los permisos son una experiencia, no solo una configuración?
Un permiso define el margen de acción del agente, pero la persona vive ese margen en cada aviso. Si los avisos son confusos, la persona aprueba sin leer. Si los límites están escondidos, no sabe por qué el agente se detuvo. Si los cambios son difíciles, deja de ajustarlos y se queda con la configuración que le dio el primer día.
Por eso el permiso es un asunto de diseño de interacción: qué se pregunta, cuándo, con qué información y con qué opciones. Los controles técnicos, como las reglas de acceso, sostienen esa experiencia, pero no la reemplazan. El aislamiento del entorno, que limita el daño aunque un permiso falle, se trata en sandboxing y permisos, y la pregunta de fondo sobre qué pasos necesitan una persona está en human-in-the-loop.
¿Qué modos de permiso existen?
Claude Code, en su documentación de permisos, ofrece varios modos que muestran un equilibrio típico entre comodidad y supervisión. Sirven de referencia para diseñar los tuyos:
| Modo | Qué corre sin preguntar | Para qué sirve |
|---|---|---|
| Predeterminado | Solo lectura | Revisar cada acción, trabajo sensible |
| Aceptar ediciones | Lectura, ediciones de archivos y comandos comunes del sistema de archivos (mkdir, mv, cp) | Iterar sobre código que se está revisando |
| Planificación | Solo lectura; propone un plan sin ejecutar cambios | Analizar y proponer antes de editar |
| Omitir permisos | Casi todo | Solo en entornos aislados, como contenedores o máquinas virtuales |
La tabla enseña algo importante: cada modo responde a una pregunta distinta. La persona debe poder cambiar de modo sin reiniciar la sesión, y ver siempre en cuál está. En Claude Code se cambia con Shift+Tab o al arrancar con una opción de línea de comandos. La documentación añade dos modos más: uno que solo deja correr lo que una regla permitió de antemano y otro automático, con un clasificador que decide, disponible solo si tu cuenta cumple ciertos requisitos.
Los modos también tienen un orden de riesgo. Un modo de “omitir permisos” debería ser difícil de activar por accidente, y en un entorno compartido conviene que un administrador pueda desactivarlo. Es una recomendación de diseño, no algo que todas las herramientas ofrezcan.
¿Cómo se presenta una regla?
Las reglas de permiso suelen tener tres resultados: permitir, preguntar o denegar. Su diseño visible importa tanto como su lógica:
- Ver las reglas activas. La persona debe poder revisar qué está permitido, en qué alcance y desde cuándo.
- Entender la precedencia. Si una regla permite y otra deniega, debe quedar claro cuál gana. En Claude Code se evalúan en el orden denegar, preguntar, permitir, y gana la primera que coincide: una regla de denegación amplia bloquea aunque exista una permisión más específica.
- Editar sin código. Un panel con opciones es mejor para la mayoría. Un archivo de configuración sirve para equipos. En Claude Code, el comando
/permissionslista las reglas y el archivo de configuración del que viene cada una.
Los avisos de Claude Code permiten aprobar una vez o guardar la decisión. Según su documentación, una aprobación permanente de un comando se guarda como regla en .claude/settings.local.json, en la raíz del repositorio, y vale para futuras sesiones en cualquier carpeta de ese repositorio. Las aprobaciones de edición de archivos, en cambio, duran hasta que termina la sesión. Son dos alcances distintos con el mismo botón, y el diseño debe mostrar cuál se está eligiendo antes de confirmar.
¿Qué alcance deben tener las decisiones?
Una decisión de “no volver a preguntar” es poderosa y peligrosa. El alcance es lo que la hace segura o no. Algunas dimensiones útiles:
- Tipo de herramienta. Permitir comandos de tests no significa permitir comandos de red.
- Comando o patrón exacto. “Ejecutar
npm test” es más estrecho que “ejecutar npm”. - Proyecto o repositorio. Una decisión en un repositorio no debería valer en otro.
- Una llamada o toda la ejecución. En el OpenAI Agents SDK, una aprobación normal vale solo para esa llamada. Si se marca
always_approve, la decisión se mantiene para las siguientes llamadas a esa herramienta durante el resto de la ejecución, y la superficie de aprobación abarca también a los agentes alcanzados por un traspaso. Quien diseña el aviso debe dejar claro cuál de las dos opciones está eligiendo la persona.
El principio es simple: una decisión debe valer solo para lo que la persona vio.
¿Cómo debe fallar el sistema?
Un sistema de permisos debe fallar hacia la negativa. Si una regla no se puede evaluar, o faltan datos en la acción, la respuesta debe ser pedir aprobación o bloquear, no ejecutar por defecto. El SDK de OpenAI describe ese comportamiento: cuando no puede inspeccionar con seguridad los argumentos de una llamada, la regla no se evalúa y la llamada requiere aprobación manual.
El caso contrario también existe: en esa misma documentación, la aprobación para la herramienta de shell local es opcional y viene desactivada por defecto. Un buen diseño no deja que el límite dependa de que alguien se acuerde de activarlo.
Esa misma lógica debe llegar a la pantalla, en la forma de cada pregunta de aprobación y en las barreras que describe guardrails para lo que el agente nunca debe hacer. Un aviso que dice “No pude verificar si esta acción está permitida; ¿la apruebas?” es más honesto que una ejecución silenciosa.
Ejemplo
Ejemplo ilustrativo: un equipo de diseño usa un agente para preparar prototipos. Al principio, el agente pide permiso para cada edición, y los diseñadores aprueban sin mirar. El equipo cambia el modo a “aceptar ediciones” dentro de la carpeta del prototipo, y deja pedir permiso para cualquier cosa fuera de esa carpeta y para comandos de red.
La primera vez que el agente intenta escribir en la carpeta de marca compartida, el aviso aparece con la ruta exacta y una frase: “Esta carpeta está fuera del proyecto. ¿Permitir esta vez?”. Los diseñadores ahora leen el aviso, porque es raro. El control está donde debía estar.
¿Cuándo NO conviene darle permisos amplios?
- Cuando el agente trabaja con datos personales o de clientes y no hay registro de acciones.
- Cuando el entorno es compartido y la persona no puede revertir cambios ajenos.
- Cuando el permiso “omitir todo” se usa en la máquina de trabajo principal, con acceso a credenciales.
En esos casos, mejor un entorno aislado y permisos estrechos que un agente libre en tu computadora.
Errores comunes
- Ocultar el modo actual, de modo que la persona no sabe con qué permisos corre.
- Ofrecer “permitir siempre” sin mostrar a qué aplica.
- Pedir permiso para cada acción, y terminar con aprobaciones automáticas.
- Dejar que una decisión de un proyecto valga en todos.
- Que el sistema ejecute por defecto cuando no puede evaluar una regla.