IBM da a cada agente de IA dueño registrado y credenciales que caducan. La credencial revocable es el control
IBM Agent Identity y HashiCorp Vault 2.2, ambos en GA, unen un registro del dueño de cada agente con credenciales de corta duración, revocables a mitad de sesión. Cómo encajan las capas.
Escuche este artículo · 4 min
Narración completa del artículo, generada con IA.

Imagine la versión de las 2 de la madrugada de un incidente con agentes. Un agente de conciliación empieza a escribir en una tabla que solo debería leer. El ingeniero de guardia quiere detener a ese agente sin detener a los otros veinte que comparten su cuenta de servicio, y quiere saber quién aprobó su acceso en primer lugar. En la mayoría de las empresas hoy ninguna de las dos cosas se puede hacer rápido: la credencial es compartida y de larga duración, y la aprobación vive en un ticket.
Los anuncios de IBM en TechXchange del 27 de octubre giran en torno a ese escenario. IBM Agent Identity y HashiCorp Vault 2.2, ambos en disponibilidad general (GA), dividen el problema en un registro y una credencial.
Las capas
Del registro de dueño al acceso revocable
IBM Agent Identity
- Dueño de cada agente
- Estado del ciclo de vida
- Autoridad que se le otorgó
El registro: quién responde por el agente
HashiCorp Vault 2.2
- Cuenta propia y protegida para cada agente
- Credenciales de corta duración y alcance limitado
- Revocación de la sesión en tiempo real
El control: a qué puede llegar el agente ahora mismo
Runtime seguro (NVIDIA OpenShell)
- Ejecución regida por políticas
- Acciones rastreables
Bases de datos, API y sistemas de operación
- Aceptan solo la credencial que emitió Vault
Agent Identity mantiene una entrada autoritativa para cada agente: quién es su dueño, si está en desarrollo, en producción o retirado, y qué autoridad se le otorgó. IBM comparte ese contexto con Vault. Ese registro es la mitad del mandato de lo que describimos como los dos permisos que necesita un agente que actúa para la empresa: alguien responsable lo otorgó, para un alcance, hasta una fecha.
Vault 2.2 da a cada agente su propia cuenta protegida, emite credenciales limitadas a lo que ese agente necesita, las renueva automáticamente y añade cifrado postcuántico. Cuando un agente intenta algo para lo que no está autorizado, se le puede denegar el acceso y revocar la sesión en tiempo real. Ambos se integran además con el runtime seguro OpenShell de NVIDIA, de modo que las acciones se pueden rastrear hasta una identidad verificada.
Por qué la credencial importa más que la política
Hoy la mayor parte de la gobernanza de agentes se escribe como política: qué debería hacer el agente, qué herramientas puede invocar, qué datos puede ver. La política es necesaria, y sostuvimos que la gobernanza de agentes necesita varias autoridades independientes. Pero una política solo sirve a las 2 de la madrugada si algo la aplica en la siguiente petición.
Una credencial de corta duración es ese algo. Si las credenciales caducan en minutos y están acotadas a un solo agente, tres cosas pasan a ser ciertas. Detener un agente no detiene a los demás. Una credencial filtrada vale poco después de su vida útil. Y el registro de dueño le da al equipo de incidentes un nombre al que llamar. El último informe de amenazas de Microsoft sostuvo que los agentes hacen que un IAM débil falle más rápido; credenciales por agente y con caducidad son la respuesta directa.
Lea la línea de estado
El anuncio de IBM es concreto. En disponibilidad general (GA): Vault 2.2, Agent Identity, las capacidades de evaluación de watsonx Orchestrate, IBM Concert y las políticas de Terraform. En preview pública: Secure Hub, el Terraform Developer Portal y el servidor MCP remoto de Terraform, entre otros. En tech preview: las capacidades de Orchestrate para descubrir y contener agentes entre plataformas, la función típica de un plano de control de agentes. Vault ya protege identidades no humanas en organizaciones como ABN AMRO, Adobe, BlackRock y Target, pero eso es uso consolidado de Vault, no adopción de las nuevas funciones para agentes.
Una prueba para cualquier despliegue de identidad de agentes
Sea cual sea su stack, estas cuatro preguntas le dicen si la identidad de agentes es real o decorativa:
- ¿Puede revocar el acceso de un agente sin tocar ningún otro agente ni cuenta humana?
- ¿Cada agente tiene un dueño con nombre, que sigue en la empresa y sigue siendo responsable?
- ¿Cuánto vive una credencial de agente y dónde se define ese número?
- ¿El sistema de destino ve la identidad propia del agente o una cuenta de integración compartida?
Si la respuesta a la última es «una cuenta compartida», empiece por ahí. Todos los demás controles dependen de saber qué agente hizo la petición.