Un agente con demasiados permisos convierte un error en un incidente
Un agente con permisos excesivos puede convertir una acción equivocada en un incidente porque el alcance de sus credenciales determina cuánto puede leer, modificar, enviar, desplegar o borrar. El modelo de control debe combinar identidad propia, permisos limitados por tarea, políticas externas, aprobación para operaciones críticas, registros auditables y revocación independiente.
La seguridad no depende de que el modelo sea infalible. Si interpreta mal una instrucción, procesa contenido manipulado o elige una herramienta incorrecta, esos controles deciden si el fallo queda contenido en un recurso y una operación o alcanza sistemas y datos que la tarea nunca necesitó.
Separar la identidad del agente de la cuenta humana
El agente no debería operar directamente con la sesión, la clave de API ni la cuenta administrativa de la persona que le asignó la tarea. Necesita una identidad de carga de trabajo distinguible, asociada con un propietario, un caso de uso, un entorno y una versión del agente. Esto permite atribuir las acciones y suspender al ejecutor automático sin bloquear al empleado.
La iniciativa de estándares para agentes de NIST incluye investigación sobre autenticación e infraestructura de identidad para interacciones seguras entre personas y agentes o entre varios agentes, además de evaluaciones de seguridad. En una organización, el inventario de identidades debería indicar propietario, finalidad, herramientas autorizadas, datos accesibles, entorno, fecha de revisión y mecanismo de baja.
También conviene separar las identidades por función y entorno. Un agente que prepara cambios en desarrollo no necesita credenciales de producción; uno que resume correo no debería compartir identidad con otro que envía mensajes. La división permite retirar una capacidad concreta sin interrumpir las demás automatizaciones.
Expresar el privilegio mínimo como reglas verificables
“Acceso al correo” y “acceso a la base de datos” describen integraciones, no autorizaciones suficientemente precisas. Cada permiso debe expresar al menos la acción, el recurso, el ámbito y las condiciones: leer mensajes de una carpeta, consultar vistas aprobadas, crear una versión candidata o desplegar un artefacto determinado. Lectura y escritura, así como preparación y ejecución, deben concederse por separado.
La guía de autorización de OWASP recomienda privilegio mínimo, denegación por defecto, comprobación de permisos en cada solicitud, pruebas de las reglas y registros adecuados. El control debe ejecutarse en el servidor, una pasarela o una función equivalente: ocultar una opción de la interfaz o pedir al modelo que no la use no impide el acceso.
Siempre que la infraestructura lo permita, la credencial debe emitirse para la tarea, expirar al terminar y quedar restringida al recurso solicitado. Si un conector solo admite una clave permanente y de alcance global, esa limitación constituye un riesgo de arquitectura; un prompt más estricto no reduce la autoridad real de la clave.
Una matriz para correo, datos y despliegues
Antes de pasar a producción, cada capacidad puede documentarse mediante seis campos: acción, identidad, permiso, aprobación, registro y revocación. La matriz convierte una descripción general del agente en controles que los equipos de seguridad y operaciones pueden comprobar.
- Correo: acción: redactar y enviar una respuesta; identidad: agente de atención asociado con un equipo responsable; permiso: leer el buzón asignado y crear borradores, sin acceso a otras carpetas; aprobación: exigida para destinatarios externos, adjuntos o envíos masivos; registro: mensaje de origen, destinatarios, herramienta, decisión de política, aprobador y resultado, sin duplicar contenido sensible innecesario; revocación: retirar el token del conector y deshabilitar solo esa identidad.
- Base de datos: acción: responder una consulta operativa; identidad: agente analítico del entorno correspondiente; permiso: solo lectura sobre vistas autorizadas, con límites de tiempo, volumen y clasificación de datos; aprobación: exigida para exportaciones o consultas fuera del patrón permitido; registro: consulta, vistas utilizadas, volumen devuelto, solicitante y decisión; revocación: invalidar la credencial temporal y retirar la asignación a las vistas.
- Despliegue: acción: publicar una versión; identidad: agente de entrega separado del que genera código; permiso: proponer cambios y desplegar únicamente un artefacto aprobado en el servicio y entorno definidos; aprobación: exigida para producción, migraciones o cambios de permisos; registro: commit, artefacto, pruebas, política aplicada, aprobador y respuesta de la plataforma; revocación: anular la credencial de despliegue y conservar una vía independiente de reversión.
Son configuraciones de referencia, no permisos universales. La organización debe ajustar cada fila según la sensibilidad de los datos, la reversibilidad de la operación y su separación de funciones. Una acción de bajo impacto puede autorizarse automáticamente; una escritura irreversible o un cambio de privilegios exige controles adicionales.
Interponer una política determinista y auditable
El modelo puede proponer una acción, pero no debería decidir si está autorizado para ejecutarla. Una pasarela determinista comprueba identidad, acción, recurso, entorno, vigencia de la credencial, límites operativos y aprobación. Si falta un atributo o ninguna regla coincide, deniega la solicitud en lugar de inferir la intención probable del agente.
El análisis Security Considerations for Artificial Intelligence Agents identifica superficies de ataque en herramientas, conectores, límites de alojamiento y coordinación entre agentes, y describe una defensa por capas con mitigaciones de entrada y del modelo, ejecución aislada y políticas deterministas para acciones de consecuencias elevadas. El aislamiento restringe archivos, red, procesos y tiempo de ejecución; la autorización restringe la autoridad empresarial. Ninguno sustituye al otro.
La aprobación humana debe activarse por una consecuencia observable, como contactar por primera vez con un destinatario externo, acceder a datos restringidos, ejecutar una escritura irreversible, modificar permisos o desplegar en producción. La pantalla debe mostrar la acción exacta, el recurso, el alcance, la identidad solicitante y el cambio previsto. La autorización tiene que caducar y quedar vinculada a esa operación para impedir su reutilización.
El registro debe enlazar la solicitud original, la identidad del agente, la herramienta, los parámetros relevantes, la versión de la política, la decisión, la aprobación y el resultado. Su acceso e integridad también requieren protección: un registro que revela secretos o puede ser modificado por el propio agente deja de ser una prueba fiable.
La entrada a producción se demuestra
El agente está preparado para ejecutar acciones reales cuando el equipo puede demostrar que los controles funcionan, no solo describirlos. La revisión previa debería cubrir esta secuencia:
- Inventariar las identidades, herramientas, conectores, datos, entornos y propietarios.
- Completar la matriz de seis campos para cada acción y denegar todo lo que no esté contemplado.
- Probar solicitudes permitidas y denegadas, credenciales vencidas, aprobaciones ausentes y accesos a recursos ajenos.
- Comprobar que la revocación invalida los tokens y las sesiones activas dentro del tiempo exigido por el riesgo.
- Simular una instrucción errónea o una entrada hostil y verificar que el registro permite reconstruir la decisión.
- Revisar los permisos no utilizados y cualquier nueva capacidad incorporada por los conectores.
El criterio final no es que el agente nunca falle, sino que cada fallo encuentre límites técnicos: una identidad atribuible, una autoridad estrecha, una decisión externa al modelo, supervisión proporcional y una revocación efectiva.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.