Cuando los agentes dejan de responder y comienzan a ejecutar acciones, ya no basta con preguntar qué modelo se utiliza. También hay que saber quién actúa, en nombre de quién, con qué permiso y durante cuánto tiempo.
En septiembre de 2026, la Blueprint Alliance, impulsada por Okta y empresas de identidad, seguridad, datos e IA, propuso tratar cada agente como una identidad de primera clase. La idea es directa: la autonomía sin una identidad verificable convierte una integración en acceso compartido y dificulta contener errores.
Por qué una clave de API no es una identidad
Una clave demuestra que alguien posee un secreto, pero rara vez explica qué agente hizo la llamada, quién la autorizó o para qué tarea. Si varios flujos comparten credenciales, revocar uno puede interrumpir todos.
La identidad incluye contexto y ciclo de vida: registro único, responsable, finalidad, sistemas permitidos, políticas, credenciales temporales, historial y estado activo o revocado.
El agente es un nuevo tipo de usuario
Las personas trabajan a un ritmo limitado. Un agente puede hacer miles de llamadas, delegar a subagentes y funcionar de forma continua. Copiar la cuenta de un empleado no es adecuado.
Tampoco debe recibir una cuenta de administrador para evitar errores de integración. Cuanto mayor sea el acceso permanente, mayor será el impacto de una equivocación, una inyección de prompt o una intrusión.
Cuatro elementos de una identidad segura
1. Identidad única e inventariada
Cada agente en producción debe tener identificador, finalidad, versión, responsable, entorno e integraciones. Los agentes olvidados o creados fuera del proceso forman parte del shadow AI.
2. Mínimo privilegio
Un agente de cobros puede leer facturas vencidas y registrar contactos, pero no cambiar datos bancarios. Los permisos corresponden a las acciones y recursos necesarios.
3. Acceso temporal y por tarea
En lugar de credenciales permanentes, el agente recibe un token corto asociado a la tarea, al usuario y al alcance. Al terminar, el acceso expira.
4. Delegación trazable
Si un agente principal llama a un subagente, la cadena conserva quién inició, quién delegó y qué límite se heredó. El subagente no puede obtener más poder que quien delega.
Actuar en nombre de una persona
Un agente corporativo que ejecuta una rutina no es igual que uno que actúa por petición de un usuario. En el segundo caso, la autorización debe combinar identidad del agente y del usuario.
Si una comercial no puede conceder más de un 10 % de descuento, su agente tampoco. Se aplican las políticas de la persona y las restricciones propias del agente, prevaleciendo el límite más estricto.
Ejemplo: agente conectado al CRM y WhatsApp
El agente recibe una conversación, consulta la ficha y actualiza una oportunidad. Puede leer el historial, crear tareas y enviar mensajes aprobados. No puede exportar la base, eliminar oportunidades o modificar permisos.
Para aplicar un descuento solicita autorización temporal a un responsable. El token sirve para esa oportunidad, dentro del límite y durante pocos minutos. La auditoría registra usuario, agente, regla, aprobación y efecto.
OAuth, cuentas de servicio y tokens cortos
OAuth delega acceso sin entregar la contraseña. Las cuentas de servicio representan automatizaciones corporativas. Los tokens breves reducen la ventana de abuso. La elección depende del sistema, pero deben evitarse secretos permanentes y compartidos.
Una integración antigua puede exigir credenciales tradicionales. En ese caso, utiliza un almacén de secretos, rotación, proxy de acceso y aislamiento. El agente no necesita conocer la contraseña; necesita una capacidad limitada.
Políticas basadas en intención
Los roles siguen siendo útiles, pero un agente necesita contexto adicional: acción, recurso, importe, horario, entorno, riesgo, usuario delegante y confianza.
Por ejemplo: «permitir crear un pedido de reposición hasta 2.000 euros para proveedores autorizados; por encima, exigir confirmación». La intención empresarial queda separada del modelo elegido.
Descubrimiento y ciclo de vida
- Descubrir: localizar agentes, claves, cuentas e integraciones.
- Registrar: asignar identidad, finalidad y responsable.
- Autorizar: aplicar alcance mínimo y duración.
- Monitorizar: observar uso, delegaciones y anomalías.
- Revisar: confirmar si el acceso sigue siendo necesario.
- Contener: suspender agente, token o herramienta.
- Retirar: eliminar credenciales al cerrar el flujo.
Checklist para producción
- cada agente tiene responsable y finalidad;
- no se comparten credenciales humanas;
- los permisos son específicos por acción y recurso;
- los tokens caducan y pueden revocarse;
- las delegaciones conservan el límite original;
- las acciones críticas requieren confirmación;
- los registros identifican agente, usuario y versión;
- la contención no obliga a apagar toda la plataforma;
- el acceso se revisa tras cambios del proceso.
Identidad, observabilidad y gobierno
La observabilidad muestra qué ocurrió; la identidad explica quién podía hacerlo; el gobierno define por qué y bajo qué reglas. Un log detallado no compensa permisos excesivos, y una política no ayuda si todos utilizan la misma clave.
Integraciones preparadas para agentes
El crecimiento de los agentes obliga a revisar API, gateways, OAuth, cuentas de servicio y permisos. El proyecto no termina en el prompt: identidad y seguridad forman parte de la arquitectura.
ProativaIA desarrolla agentes y automatizaciones con IA, crea integraciones y software a medida. Podemos estructurar identidades, permisos, delegaciones y aprobaciones para que cada agente disponga solo del acceso necesario.