Cuando los agentes de IA generativa interactúan con herramientas, APIs o servicios externos (como BigQuery, Jira, GitHub o Google Maps), necesitan un mecanismo seguro para autenticar las solicitudes salientes. El administrador de autenticación de identidad del agente (administrador de autenticación) proporciona esto actuando como un almacén de credenciales centralizado y un agente de autenticación que simplifica la autenticación de herramientas salientes.
Beneficios de usar el administrador de autorización
El administrador de autorización proporciona los siguientes beneficios para el desarrollo de agentes:
- Bóveda de credenciales centralizada: Almacena claves de API, secretos de clientes de OAuth y tokens de usuarios en una bóveda administrada por Google, lo que ayuda a evitar secretos codificados y almacenamiento de bases de datos personalizadas.
- OAuth 2.0 automatizado: Controla los flujos de OAuth 2.0 de varios pasos, como el consentimiento del usuario, el intercambio de códigos de autorización y las actualizaciones de tokens, sin código de backend personalizado.
- Integración perfecta del ADK: Se integra de forma nativa con el Kit de desarrollo de agentes (ADK) para recuperar e insertar encabezados de autenticación salientes, como
AuthorizationoX-Goog-Api-Key, en las invocaciones de herramientas y servidores del Protocolo de contexto del modelo (MCP). - Control de acceso detallado al ID de SPIFFE: Usa identidades de agentes basadas en SPIFFE para definir políticas precisas de Identity and Access Management (IAM), lo que ayuda a garantizar que solo los principales y desarrolladores de agentes autorizados puedan acceder a proveedores de autenticación específicos.
Cómo funciona el administrador de autorización
El administrador de autenticación actúa como una bóveda de credenciales entre tu entorno de Agent Runtime en Gemini Enterprise Agent Platform y los extremos de servicio externos.
Cuando un agente llama a una herramienta externa, el ADK intercepta la ejecución de la herramienta, solicita la credencial adecuada de la bóveda del administrador de autenticación y adjunta los encabezados de autenticación necesarios antes de enviar la solicitud a la API de destino.
En el siguiente diagrama de flujo, se ilustran la arquitectura de alto nivel y el ciclo de vida de la recuperación de credenciales:
- El usuario final activa un evento o una instrucción que requiere autenticación de herramientas externas.
- El agente implementado (con el ADK) intercepta de forma transparente la solicitud de la herramienta y consulta la bóveda segura del administrador de autenticación.
- El administrador de autenticación devuelve la credencial segura (clave de API o token de OAuth) al agente.
- El agente invoca la API o herramienta externa con la credencial adjunta.
- El servicio de terceros valida la credencial y devuelve los datos solicitados al agente.
- El agente usa los datos devueltos para generar y entregar la respuesta final al usuario.
Ejemplos de integraciones de terceros
El administrador de autenticación admite patrones estándar de OAuth 2.0 y claves de API, lo que lo hace compatible con muchos servicios de terceros.
En la siguiente tabla, se enumeran algunos servicios de terceros verificados, sus métodos de autenticación admitidos y la documentación de configuración.
| Servicio | Métodos de autenticación compatibles | Documentación de configuración de credenciales |
|---|---|---|
| Jira de Atlassian | OAuth de 3 segmentos, clave de API | Guía de Jira sobre OAuth 2.0 |
| Dropbox | OAuth de 3 segmentos | Guía de OAuth de Dropbox |
| GitHub | OAuth de 3 segmentos* | Apps de OAuth de GitHub |
| GitLab | OAuth de 3 segmentos | Proveedor de OAuth de GitLab |
| Microsoft | OAuth de 3 segmentos* | Plataforma de identidad de Microsoft |
| Salesforce | OAuth de 3 segmentos, OAuth de 2 segmentos | Apps conectadas de Salesforce |
| ServiceNow | OAuth de 3 segmentos*, OAuth de 2 segmentos | Configuración de OAuth de ServiceNow |
* Para obtener detalles sobre las limitaciones y los requisitos del servicio, consulta Consideraciones específicas del servicio.
Consideraciones específicas del servicio
- GitHub y Microsoft: El administrador de autorización admite integraciones de un solo alcance para GitHub y Microsoft. El administrador de autorización no admite la solicitud de varios permisos. Para obtener más información, consulta Error de varios alcances de GitHub o Microsoft.
- ServiceNow: En ServiceNow, los administradores configuran los permisos permitidos a nivel de la aplicación. Independientemente de lo que solicite un agente, ServiceNow solo otorga estos permisos configurados. Si un agente requiere un alcance que no está configurado, es posible que la autenticación falle o que se ingrese en un bucle de solicitudes. Asegúrate de que la configuración de la aplicación de ServiceNow incluya todos los permisos que necesita tu agente. Para obtener más información, consulta Bucle de autenticación de ServiceNow o permisos inesperados.
Ubicaciones
El administrador de autenticación de identidad del agente está disponible en regiones de América, Europa y Asia-Pacífico. Para obtener una lista de las regiones admitidas, consulta Ubicaciones de Agent Identity.
¿Qué sigue?
- Autenticación con una clave de API y el administrador de autenticación
- Autenticación con OAuth de 2 segmentos con el administrador de autenticación
- Autenticación con OAuth de 3 segmentos con el administrador de autenticación
- Descripción general de la identidad del agente
- Administra proveedores de autenticación de Agent Identity
- Ubicaciones de identidad del agente
- Soluciona problemas del administrador de autenticación de Agent Identity