Diseñar superficies de permisos de IA: inventario y revocación

Un usuario le pide a un agente que actualice un registro y la interfaz responde con una casilla de verificación que permite la acción. No puede saber si el agente puede leer archivos, acceder a la red o almacenar credenciales. Una simple casilla de «permitir» es un fallo de diseño.

Las superficies de permisos son la capa de producto donde los usuarios aprenden qué puede tocar un agente, qué no puede y cómo recuperarlo. Trátalas como el proceso de pago, la incorporación o los estados de error: una experiencia diseñada con estados, etiquetas y retroalimentación.

Inventaria el agente antes de diseñar el interruptor

Inventaria cada capacidad a la que el agente puede acceder antes de dibujar un solo control. La lista necesita una fila por agente, herramienta, plugin, servidor o extensión, además de los datos, archivos, redes y secretos a los que puede acceder.

Comienza por la máquina o el entorno de despliegue y luego sigue los componentes que dependen entre sí. Cualquier componente que pueda ejecutar código, almacenar credenciales, navegar de forma amplia o acceder a la red debe estar en la lista. Geiger es un comando de solo lectura que inventaria agentes de IA, arneses, servidores MCP, plugins y extensiones de IA en una máquina e informa sobre lo que cada uno puede tocar.

Prefiere herramientas de inventario que se mantengan en solo lectura. Geiger no realiza escrituras excepto cuando el usuario especifica explícitamente un archivo de salida JSON.

Mantén el inventario separado de la superficie orientada al usuario. Los ingenieros necesitan el mapa completo; los usuarios necesitan un resumen. Deja que la lista impulse las etiquetas, los límites y la auditoría.

Las etiquetas son la superficie de permisos

Etiqueta cada punto de contacto en lenguaje claro. La fila debe indicar que el agente puede leer archivos, no solo mostrar una categoría.

Geiger etiqueta cada hallazgo con categorías de capacidad que incluyen EXECUTES, HOLDS-SECRETS, BROAD-FILESYSTEM, BROAD-WEB y NETWORK.

Usa esas categorías como etiquetas cortas, pero asocia cada etiqueta con la ruta de evidencia o la acción de ejemplo que la respalda. Un usuario debe poder preguntar cómo se demostró la etiqueta y obtener una respuesta concreta.

Muestra ambas capas cuando una capa de aplicación se sitúa delante de un servidor. Geiger detecta envoltorios de política que añaden una capa de aplicación antes de los servidores MCP e informa sobre ambas capas en lugar de ocultar el servidor real.

Los límites deben ser revocables

Convierte cada etiqueta en un límite de acción que el usuario pueda modificar. El control debe indicar que el agente puede leer archivos, con un estado de desactivación claro y una razón para la restricción.

Delimita los permisos a la persona que el agente representa. Los agentes Sana de Workday están limitados al usuario que representan y a los permisos que ese usuario tiene actualmente.

Vigila la aplicación oculta detrás de una página de configuración. Si el usuario no puede ver qué cambió, cuándo cambió y quién puede anularlo, el límite es decorativo.

Haz que la revocación sea inmediata y legible. El estado final implica una capacidad eliminada, una acción detenida y un alcance restante visible. Muestra el nuevo alcance en la misma vista donde el usuario lo revocó. Si la revocación requiere un ticket de soporte, añade un control directo antes del lanzamiento.

La aplicación visible genera confianza

Muestra la aplicación donde el usuario está trabajando. Coloca una línea de estado, una insignia o una pequeña entrada de registro junto a la acción, no en una consola de administración separada. Mantén la entrada de registro lo suficientemente corta para leerla en el flujo de trabajo.

Aplica la misma lógica a las pistas de auditoría que al límite de permisos. En la arquitectura Sana de Workday, Gemini solo conserva registros de interacción, y el registro principal de auditoría permanece dentro de Workday y del entorno del cliente.

Vincula la superficie de permisos al producto que posee la acción. Workday lanzó Sana en marzo y amplió su colaboración con Google para que los agentes creados con Sana puedan encontrarse en Gemini Enterprise.

La vista de auditoría debe responder a tres preguntas: qué se permitió, qué se bloqueó y qué cambió. Cuando la interfaz no puede responderlas, corrige la vista de auditoría antes de pedir confianza.

Antes de publicar, verifica la superficie contra los cinco controles:

• Inventario de capacidades: lista cada agente, herramienta, plugin, servidor y extensión, además de los datos, archivos, redes y secretos a los que puede acceder.
• Etiquetas de puntos de contacto: muestra cada capacidad en lenguaje claro, con evidencia de la afirmación.
• Límites de acción: convierte cada etiqueta en un control que el usuario pueda modificar, con un estado de desactivación claro y una razón.
• Controles de revocación: elimina la capacidad, detén la acción y muestra el alcance restante en la misma vista.
• Aplicación y auditoría visibles: muestra los bloqueos junto a la acción y responde qué se permitió, bloqueó y cambió.