Limita los permisos del agente

Describe la tarea antes de conceder acceso

Un agente que lee código necesita permisos distintos de otro que despliega un servicio. No concedas ambos conjuntos de permisos porque el mismo producto admita las dos acciones.

Define los permisos con tres elementos: una acción, un recurso y una condición. Para una corrección ficticia de informes, el agente puede escribir en una rama de funcionalidad mientras la tarea esté activa. Puede leer archivos autorizados del repositorio. No puede modificar datos de producción ni reglas de protección del repositorio.

La aplicación exacta de los límites depende de la herramienta. Si un token no puede expresar una restricción de rama, usa controles adicionales del repositorio o un servicio de ejecución. Documenta con honestidad los permisos que siguen disponibles.

Impón el límite fuera del modelo

Un prompt no es un sistema de control de acceso. El componente de ejecución debe comprobar la acción solicitada y su destino frente a los permisos actuales. No debe aceptar como prueba que el modelo afirme que ya existe aprobación.

AWS recomienda permisos limitados y credenciales temporales para las cargas de trabajo adecuadas. OWASP aplica un criterio similar de mínimo privilegio a agentes y herramientas. Estos principios necesitan una implementación en los sistemas reales de identidad y ejecución. Guía de AWS IAM, guía de OWASP para agentes.

Usa credenciales de corta duración cuando se admitan. Mantén los secretos ajenos a la tarea fuera del entorno. Una tarea de lectura del repositorio no debe heredar una contraseña de base de datos de producción del shell del desarrollador.

Vincula la aprobación a la acción real

Aprobar la preparación de un cambio no implica aprobar su despliegue. Una decisión de despliegue debe identificar el artefacto, el entorno de destino y las condiciones pertinentes. Si cambian, la decisión anterior puede dejar de ser aplicable.

Considera un agente que propone una lectura segura de base de datos y, tras recibir aprobación, ejecuta otra consulta. Un mecanismo útil de aprobación comprueba la operación que realmente se ejecuta. Un mensaje genérico de «continúa», sin un destino definido, puede ocultar esta diferencia.

Separa también la identidad de la capacidad. Registra qué persona o carga de trabajo inició la ejecución. Verifica que esa identidad siga teniendo permiso cuando se produzca la acción. Retirar el acceso a una persona debe tener un efecto explícito sobre el trabajo en cola.

Prueba una denegación y una interrupción

Verifica algo más que el recorrido satisfactorio. En un entorno de pruebas aislado, intenta una acción sobre un recurso fuera de los permitidos. Confirma que el sistema de ejecución la rechaza. Inspecciona el evento de auditoría sin registrar credenciales.

Después, prueba la cancelación o la caducidad de las credenciales. Determina qué trabajo se detiene de inmediato y qué operación puede terminar. Un botón de parada no revierte necesariamente una acción que ya ha llegado a otro sistema.

Conserva un registro breve de permisos junto a la tarea. Incluye la persona responsable, el alcance aprobado, los controles reales, la prueba de denegación y la caducidad. Así, una revisión posterior tendrá el detalle suficiente para mejorar el flujo de trabajo.