Identidades de agentes de IA: Google Cloud generaliza su gestor de acceso

Google Cloud anunció la disponibilidad general de su gestor de autenticación de identidad de agente y API asociadas. Esta evolución responde a un problema que se ha convertido en central: cuando un agente actúa en varias herramientas, no debe reutilizar ciegamente los IDs de usuario o guardar secretos permanentes en su código.

Un agente necesita su propia identidad

Las aplicaciones tradicionales ya distinguen las cuentas humanas, las cuentas de servicios y las cargas de trabajo. Los agentes añaden una dificultad: pueden crearse dinámicamente, actuar en nombre de una persona, utilizar múltiples herramientas durante la misma tarea y mantener un estado durante una duración variable. Una simple clave de API copiada en una variable de entorno no describe quién solicitó la acción o qué el agente se le permitió hacer.

Google presenta la identidad del agente como una identidad criptográfica altamente acreditada, vinculada al ciclo de vida del recurso que alberga al agente. El gestor de autenticación actúa como una caja fuerte centralizada y como intermediario para las conexiones salientes a los servicios de terceros.

Tres modos de autenticación cubiertos

El servicio apoya a tres actores OAuth, cuando el usuario debe consentir el acceso del agente a un servicio; El OAuth de dos partes, adecuado para los intercambios de servicio a servicio; y las claves de API, todavía utilizados por muchas herramientas. El interés de un corredor central no es sólo almacenar secretos. Permite normalizar la atribución, rotación y uso sin exponerlos directamente a todos los componentes.

API agentidentity.googleapis.com y agentidentitycredentials.googleapis.com reemplazar la antigua API de IAM Connectors para gestionar proveedores de autenticación e identidades de agente. Google había planeado una fase de migración durante la cual los recursos existentes se reflejaban en la nueva jerarquía a fin de mover gradualmente políticas y aplicaciones.

Por qué una identidad por agente mejora la auditoría

Con una cuenta compartida, los registros sólo indican que una aplicación genérica usó un recurso. Con una identidad distinta, es posible vincular una operación con un agente, su entorno y la política que le concedió acceso. Esto facilita el análisis de un incidente y la aplicación de cualquier privilegio.

Esta granularidad es particularmente útil para los agentes especializados. Un agente de apoyo puede leer una base de datos documental y crear un proyecto de respuesta sin cambiar la facturación. Un agente comercial puede enriquecer un CRM sin acceder a secretos de infraestructura. Un agente de desarrollo puede abrir una solicitud de fusión sin los derechos de despliegue en producción.

La caja secreta no es suficiente: la delegación debe ser limitada

Una arquitectura segura debe distinguir entre la identidad del agente, la persona que lanza la tarea y la identidad realmente utilizada con la herramienta. La delegación debe seguir siendo explícita. Un usuario autorizado para ver los datos no debe permitir automáticamente que todos los agentes de su organización lo lean.

También se debe definir la longitud y el alcance de las fichas. Los identificadores efímeros reducen las consecuencias de una fuga, mientras que las autorizaciones dirigidas evitan que una tarea limitada tenga acceso global. Cuando una herramienta sólo ofrece una llave estática, el corredor puede mejorar el almacenamiento y la rotación, pero no puede inventar una granularidad que el servicio remoto no proporciona.

Existen salvaguardias de la Organización

Google Cloud también ha puesto a disposición las restricciones de política organizativa personalizadas sobre los recursos de Identidad de Agentes, así como la integración con Controles de Servicio VPC. Una organización puede enmarcar la creación o modificación de proveedores de autenticación, colocar API dentro de un área de servicio, y especificar las reglas de entrada y salida para identidades de agente.

Estos controles acercan a los agentes a las prácticas habituales de gobernanza en la nube. Permiten a los equipos de plataforma y seguridad establecer reglas comunes, en lugar de permitir que cada prototipo invente su propio almacenamiento secreto.

Un método de aplicación progresiva

1. Inventario de acciones: enumerar las herramientas llamadas, los datos consultados y posibles cambios.
2. Funciones separadas: crear identidades diferentes para los agentes que no tienen las mismas responsabilidades.
3. Reducir las autoridades: proporcionar sólo las operaciones necesarias de los recursos necesarios.
4. Duración corta: preferir fichas temporales y revocar el acceso cuando el agente desaparece.
5. Establecer contexto: mantener la identidad del usuario del iniciador, tarea, herramienta y resultado.
6. Desviaciones de prueba: simular una inyección rápida, una herramienta comprometida y un intento de acceder fuera del perímetro.

Lo que la aplicación todavía necesita para decidir

El agente de identidad administra la autenticación; no reemplaza las reglas de aplicación del negocio. El hecho de que un agente sea reconocido no significa que todas sus aplicaciones deben ser aceptadas. Las transacciones irreversibles o financieras pueden requerir validación humana, doble control o política contextual.

También debe considerarse la confidencialidad de los periódicos. Una ruta útil de auditoría describe la acción y su resultado, pero no debe copiar un token, un documento sensible o todo el impulso que contiene datos personales. La observabilidad depende tanto de lo excluido como de lo que se retiene.

Una fundación para industrializar sin trivializar el riesgo

Los primeros agentes prototipo a menudo comienzan con una clave compartida porque es el camino más corto. Esta solución se vuelve frágil a medida que aumenta el número de herramientas, usuarios y entornos. La disponibilidad general de un servicio de identidad dedicado muestra que el ecosistema está pasando gradualmente de la demostración a la explotación controlada.

Para una empresa, el beneficio no es sólo un producto específico de la nube. reside en el modelo de arquitectura: una identidad verificable por agente, un corredor de secretos, fichas limitadas, reglas centrales y una pista de auditoría. Estos principios siguen siendo válidos independientemente de cuál sea el proveedor seleccionado.

Ver las notas de la versión de Google Cloud IAM · Prepare una arquitectura de agente controlado con SDX →