En un registro aparece que “María” descargó 3.000 expedientes a las 03:17. María dormía. Un agente que actuaba en su nombre reutilizó su token durante una tarea programada. El acceso era válido; la atribución, inútil.
Un agente necesita identidad propia y contexto de delegación. Son dos cosas distintas: quién ejecuta y en nombre de quién lo hace.
Autenticar no es autorizar
La identidad responde “¿quién llama?”. La autorización responde “¿puede hacer esto sobre este recurso ahora?”. La delegación añade “¿con qué mandato de usuario o proceso?”.
Un agente de compras puede estar autenticado correctamente, actuar por Laura y aun así carecer de permiso para aprobar su propia orden. El sistema receptor, no el prompt, debe aplicar esa separación de funciones.
NIST publicó en febrero de 2026 un documento conceptual centrado en identidad y autoridad de agentes de software e IA, precisamente por el riesgo de dar acceso a múltiples datos, herramientas y aplicaciones sin controles adecuados (NIST).
La identidad mínima que merece quedar en una acción
El identificador del agente debe ser estable para auditoría, aunque sus instancias sean efímeras. Conviene asociar propietario, entorno, versión de configuración y propósito aprobado. Una ejecución concreta añade ID de sesión y de tarea.
Credenciales de vida corta, no secretos enterrados
Una API key almacenada en una variable durante meses ofrece al agente toda la capacidad de esa clave, dentro y fuera de la tarea. Es preferible intercambiar identidad por un token breve, limitado a una audiencia y a scopes concretos.
RFC 9700, práctica vigente de seguridad OAuth publicada en 2025, recomienda restringir privilegios al mínimo, limitar la audiencia y utilizar mecanismos contra repetición cuando proceda (IETF). Para workloads dinámicos, SPIFFE define identidades verificables y credenciales cortas rotadas mediante una Workload API (SPIFFE).
La elección tecnológica depende del entorno. El principio permanece: el código del agente no debería conocer un secreto raíz que le permita fabricar autoridad.
Delegar sin convertir al agente en el usuario
Hay tres patrones habituales:
| Patrón | Útil para | Riesgo a controlar |
|---|---|---|
| servicio propio | tareas programadas del sistema | permisos demasiado amplios |
| delegación de usuario | actuar sobre recursos del usuario | confundir capacidad del usuario con necesidad de la tarea |
| mandato aprobado | acción concreta con condiciones | reutilización fuera de plazo o propósito |
Un mandato puede expresar “preparar borradores de respuesta para estos tickets durante una hora”. Enviar mensajes, borrar tickets o leer otros proyectos quedan fuera aunque el usuario pudiera hacerlo manualmente.
La aprobación humana debe vincularse a la acción que se mostró. Si cambian destinatario, importe o adjunto después de aprobar, el sistema necesita otra validación.
Permisos que se calculan en tiempo de ejecución
Los permisos efectivos son la intersección de varias políticas:
- capacidades permitidas al agente;
- permisos del usuario o proceso delegante;
- alcance de la tarea;
- clasificación del recurso;
- restricciones de entorno, horario o importe;
- aprobaciones aún válidas.
Esta intersección evita que un agente herede sin filtro todos los privilegios de un administrador. También permite ejecutar tareas de sistema sin fingir que un usuario sigue presente.
El registro debe contar una historia completa
Guardar la llamada HTTP no basta. Para investigar una acción se necesita: agente, versión, instancia, delegante, tarea, herramienta, recurso, parámetros relevantes, política aplicada, aprobación, respuesta y resultado final.
No registre secretos ni datos completos si bastan identificadores o huellas. La auditoría también tiene permisos y retención. Un log exhaustivo y accesible para cualquiera crea otro repositorio sensible.
La trazabilidad útil permite responder quién pudo, quién pidió, quién ejecutó y quién aprobó.
Revocar es parte del diseño
Cuando un usuario pierde acceso o se retira un agente, las tareas largas no pueden conservar autoridad indefinida. Verifique permisos al emitir tokens y antes de acciones críticas. Mantenga listas de trabajos activos, capacidad de cancelación y caducidad.
También hay que separar revocar identidad, credencial, versión y mandato. Una vulnerabilidad en una versión del agente puede exigir detener solo esa versión, sin deshabilitar todo el servicio.
Preguntas frecuentes
¿Cada agente necesita un usuario en cada aplicación?
No siempre. Puede utilizar identidad federada y delegación mediante tokens. Lo importante es que el sistema receptor distinga actor y autoridad y aplique permisos verificables.
¿Por qué no basta con registrar el usuario final?
Porque impide distinguir una acción manual de una automática, comparar versiones o revocar al agente sin afectar al usuario.
¿Los scopes OAuth resuelven todo?
No. Pueden ser demasiado gruesos y no expresan por sí solos importe, fila, proyecto o estado. Combine scopes con políticas en el recurso y contexto de tarea.
¿Dónde se guardan las credenciales?
En un gestor de secretos o servicio de identidad, preferiblemente emitidas bajo demanda. No en prompts, memoria conversacional, repositorios ni logs.
La autonomía empieza por poder decir “este agente no”
Un sistema es gobernable cuando puede limitar y retirar autoridad sin apagar a todas las personas ni aplicaciones. Dar nombre propio al agente parece un detalle de infraestructura. En realidad, es la base para responsabilizar, aprender y escalar.
Fuentes y lecturas recomendadas
- Identity and Authority of Software Agents — NIST
- RFC 9700: OAuth 2.0 Security Best Current Practice
- SPIFFE Concepts
- SPIFFE Workload API
Fuentes y vigencia revisadas el 18 de agosto de 2026.