Descripción general de la identidad del agente

Agent Identity proporciona una identidad criptográfica con certificación sólida para cada agente que se basa en el estándar SPIFFE. Con la identidad del agente, este puede autenticarse de forma segura en servidores de MCP, recursos de la nube, endpoints y otros agentes, ya sea en su propio nombre o en el de un usuario final. Agent Identity usa la credencial propia del agente y el administrador de autenticación de Agent Identity. Puedes usar el administrador de autenticación para crear y administrar proveedores de autenticación, que son los parámetros de configuración específicos que se usan para adquirir, administrar y proteger claves de API, IDs de cliente de OAuth, secretos de cliente de OAuth y tokens de OAuth de usuario final delegados.

A diferencia de las cuentas de servicio, las identidades de agentes no se comparten entre varias cargas de trabajo de forma predeterminada, no se pueden suplantar y no permiten que los desarrolladores generen claves de cuentas de servicio de larga duración. Los tokens de acceso generados para Google Cloud están vinculados criptográficamente a los certificados X.509 únicos del agente para evitar el robo de tokens.

Agent Identity funciona con Agent Registry y Agent Gateway para ayudar a proteger y administrar los agentes de IA. Agent Identity aprovisiona identidades criptográficas y administra credenciales, Agent Registry cataloga las herramientas y los destinos de tu entorno, y Agent Gateway aplica políticas de acceso y, además, inspecciona el tráfico de red cuando los agentes llaman a esos destinos.

Los siguientes servicios admiten la identidad del agente:

Modelos de autenticación

Para autenticarse con varias herramientas y servicios, la identidad del agente admite varios modelos de autenticación. El modelo que usa un agente depende del método de autenticación que ofrece el recurso de destino y de si el agente actúa con su propia autoridad o en nombre de un usuario final.

Autoridad Método de autenticación Recurso objetivo Caso de uso y solución
Autoridad delegada por el usuario OAuth 2.0 (3 partes) Herramientas y servicios externos Cuando un agente actúa en nombre de un usuario específico (por ejemplo, para acceder a las tareas de Jira o a los repositorios de GitHub de un usuario). Configuras un proveedor de autenticación de OAuth de 3 niveles en el administrador de autenticación de Agent Identity para administrar el consentimiento del usuario y los tokens. Para obtener más información, consulta Autentica con OAuth de 3 niveles con el administrador de autenticación.
Autoridad propia del agente Identidad basada en la nube (identidad del agente) Google Cloud servicios Cuando un agente alojado en Google Cloud necesita acceder a otros servicios de Google Cloud con su propia identidad. Para obtener más información, consulta Autentica en Google Cloud con la identidad propia de un agente.
Identidad basada en la nube (tokens de ID de OIDC) Herramientas y servicios externos Cuando un agente alojado en Google Cloud necesita autenticarse en backends externos, APIs personalizadas o plataformas en la nube de terceros con su propia identidad y la federación de identidades de OpenID Connect (OIDC). Para obtener más información, consulta Autentica en servicios externos con la identidad propia de un agente.
OAuth 2.0 (2 segmentos) Herramientas y servicios externos Se recomienda para la autenticación de máquina a máquina con servicios externos que admiten OAuth. Configuras un proveedor de autenticación de OAuth de 2 segmentos en el administrador de autenticación de Agent Identity para controlar las credenciales de cliente y los tokens de acceso. Para obtener más información, consulta Autentica con OAuth de 2 niveles con el administrador de autenticación.
Clave de API Herramientas y servicios externos Para servicios externos que requieren una clave criptográfica o una contraseña para la autenticación. Configura un proveedor de autenticación de claves de API en el administrador de autenticación de Agent Identity para almacenar y administrar las claves de forma segura. Para obtener más información, consulta Autentica con una clave de API con el administrador de autenticación.
Autenticación básica HTTP Herramientas y servicios externos Usa contraseñas de texto simple. No se recomienda este método. Puedes almacenar contraseñas de forma similar a una clave de API. Para obtener más información, consulta Autentica con una clave de API con el administrador de autenticación.

Arquitectura de delegación de identidades

Para aplicar límites de confianza entre usuarios humanos, cargas de trabajo autónomas y herramientas externas sin depender de la identidad temporal como cuenta de servicio, la identidad de agente usa un framework de delegación de tres identidades. Este framework separa y coordina tres contextos de identidad distintos en tu entorno:

  • Identidad del usuario: Es la identidad del usuario final que inicia la acción, autenticada a través de OAuth 2.0 estándar o OpenID Connect (OIDC) con Google Identity o un proveedor de identidad (IdP) de personal federado.
  • Identidad del agente: Es la identidad de SPIFFE única y con certificación criptográfica del agente implementado y el certificado X.509 aprovisionado automáticamente, que representa al agente que actúa bajo su propia autoridad.
  • Identidad delegada: Es el contexto de autoridad combinado cuando el agente actúa en nombre del usuario humano que inicia la acción con credenciales de OAuth de 3 segmentos (3LO) con alcance intermediadas por el administrador de autenticación de Agent Identity.

En el siguiente diagrama, se ilustra cómo interactúan la identidad del usuario, la identidad del agente y la identidad delegada en los límites de confianza de entrada, entorno de ejecución y salida:

Diagrama de arquitectura de delegación de identidad que asigna la identidad del usuario, la identidad del agente y la identidad delegada en los límites de confianza de entrada, entorno de ejecución y salida.

Para obtener más información sobre cómo la plataforma evalúa y propaga cada capa de identidad en los límites de confianza, consulta Arquitectura de delegación de identidad.

Componentes centrales

La identidad del agente incluye varios componentes clave que, en conjunto, ayudan a proporcionar autenticación y autorización seguras.

Identidad basada en SPIFFE

A cada agente se le asigna una cadena de identidad única, o ID de SPIFFE, según el estándar de SPIFFE. Esta identidad se certifica de forma sólida, se vincula al ciclo de vida del agente y se asigna directamente al URI del recurso en el que se aloja el agente.

La identidad sigue este formato:

spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Por ejemplo:

  • spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent

Cuando se usa una identidad de agente en una política de permisos de IAM, el identificador de la principal tiene el siguiente formato:

principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Ejemplos:

  • Vertex AI Agent Engine (organización): principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Vertex AI Agent Engine (proyecto sin organización): principal://agents.global.proj-9876543210.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Gemini Enterprise: principal://agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-test-agent

Los identificadores usan lo siguiente:

  • TRUST_DOMAIN: Es el dominio de confianza de tu jerarquía de recursos:
    • Para proyectos en una organización: agents.global.org-ORGANIZATION_ID.system.id.goog
    • Para proyectos sin una organización: agents.global.proj-PROJECT_NUMBER.system.id.goog
  • SERVICE: Es el nombre corto del servicio de Google Cloud (por ejemplo, aiplatform o discoveryengine).
  • RESOURCE_PATH: Es la ruta de acceso completa al recurso que aloja el agente.

Como el agente en sí es la principal, otorgas permisos directamente a este identificador para controlar a qué recursos puede acceder el agente.

Ciclo de vida de la identidad y los permisos

Debes administrar las vinculaciones de IAM para las identidades de tus agentes. Borrar un agente no quita las vinculaciones de IAM que hacen referencia a su principal. Estas vinculaciones permanecen en tus políticas como otorgamientos inactivos, y debes quitarlas de forma manual como parte de la retirada de un agente.

La identidad de un agente se deriva del ID del recurso que lo aloja, como el ID del recurso reasoningEngines. Si borras un agente y, luego, implementas un reemplazo, incluso con el mismo nombre visible, código y configuración, el agente nuevo recibe un ID de recurso nuevo y, por lo tanto, un identificador de principal nuevo. Las vinculaciones de IAM existentes que hacían referencia a la identidad anterior no se aplican a la principal nueva. Debes otorgar los roles necesarios a la principal nueva.

Credenciales del agente

Las credenciales de agente proporcionan una prueba criptográfica de la identidad de un agente. El sistema admite certificados X.509, tokens de acceso de Google Cloud y tokens de ID de OIDC. Se aprovisiona y administra automáticamente un certificado X.509 en el agente para ayudar a admitir una autenticación más sólida.

Estos certificados X.509 se encadenan a una autoridad de certificación (AC) raíz administrada por Google. Puedes ver los certificados de la AC públicos predeterminados en los siguientes extremos:

De forma predeterminada, las identidades de los agentes usan TLS mutua (mTLS) con certificados X.509 cuando se comunican directamente con las APIs de Google Cloud . Cuando los agentes interactúan a través de Agent Gateway, también usan la demostración de prueba de posesión (DPoP), lo que crea credenciales de doble vinculación para la seguridad de extremo a extremo. Esta vinculación doble significa que los agentes se autentican con mTLS para el acceso propio a la puerta de enlace y usan DPoP para las interacciones más allá de la puerta de enlace.

administrador de autenticación de Agent Identity

El administrador de autenticación de Agent Identity es un almacén de credenciales centralizado y un agente de autenticación que simplifica la autenticación de herramientas salientes para tus agentes. Permite que los agentes se autentiquen con una clave de API o un ID y un secreto de cliente de OAuth, o en nombre de un usuario a través de la delegación de OAuth con tokens de acceso de usuario final. En el administrador de autenticación, configuras los proveedores de autenticación que definen el tipo de autenticación y las credenciales para aplicaciones de terceros específicas.

El acceso al administrador de autenticación de Agent Identity se rige por IAM, y el agente usa su propio ID de SPIFFE de agente para autenticarse en el administrador de autenticación. Todos los eventos de acceso de los usuarios finales también se pueden atribuir al ID de SPIFFE del agente, lo que permite una administración sencilla.

El administrador de autenticación de Agent Identity automatiza la adquisición de credenciales de OAuth, como abrir un diálogo para el acceso y el consentimiento del usuario. También proporciona visibilidad del acceso de los usuarios finales y permite revocarlo, lo que garantiza una mejor administración de los permisos delegados por los usuarios.

Para obtener más información, consulta la descripción general del administrador de autenticación de Agent Identity.

Seguridad y administración

La identidad del agente está completamente integrada en los sistemas de políticas de Google, como IAM, el límite de acceso de la entidad (PAB) y los Controles del servicio de VPC, que permiten mejorar la seguridad y la administración. También se integra con el registro de auditoría para garantizar la responsabilidad y proporcionar registros de auditoría claros tanto cuando el agente actúa como sí mismo como cuando actúa en nombre de un usuario final.

  • Acceso adaptado al contexto: De forma predeterminada, una política de acceso adaptado al contexto administrada por Google ayuda a proteger las credenciales del agente aplicando la vinculación de tokens de mTLS y DPoP. Este enfoque garantiza que los tokens vinculados a certificados no se puedan reproducir fuera de su entorno de ejecución de confianza.
  • Integración de IAM: Compatibilidad con las políticas de permisos y denegación de IAM estándar.
  • Límite de acceso de la entidad (PAB): Una política de límite de acceso de la entidad restringe los recursos a los que puede acceder un agente, independientemente de otros permisos que tenga. Las políticas de límite de acceso de las entidades aplicadas a la identidad del agente se evalúan como parte de las llamadas salientes (de salida). Las identidades de agentes que están sujetas a las políticas de límite de acceso de las entidades solo pueden acceder a los recursos especificados en esas políticas, lo que aísla estrictamente al agente a su límite designado.
  • Controles del servicio de VPC: Compatibilidad con la protección del perímetro y el uso de principales:
    • Protección perimetral: Puedes agregar la API de Agent Identity (agentidentity.googleapis.com) y la API de Agent Identity Credentials (agentidentitycredentials.googleapis.com) a un perímetro de servicio para ayudar a controlar el acceso a estas APIs. Para usar estas APIs dentro de un perímetro de servicio, los clientes deben enrutar las solicitudes a través de la VIP restringida (restricted.googleapis.com).
    • Reglas de entrada y salida: Se admite el uso de identidades de agentes como principales en las reglas de entrada y salida para permitir el acceso a los recursos protegidos por un perímetro de servicio.

Cómo funciona la identidad de agentes

La identidad del agente autentica y autoriza las acciones del agente a través de un flujo de trabajo diseñado para ayudar a mejorar la seguridad:

  1. Asignación de identidad: Cuando implementas un agente, Google Cloud le asigna una identidad SPIFFE única y un certificado X.509. Cada certificado X.509 es válido durante 24 horas y Google Cloud lo mantiene actualizado automáticamente para preservar la seguridad.
  2. Adquisición de credenciales: El método que usan los agentes para adquirir credenciales depende de lo que intenten acceder. A continuación, se muestran algunos ejemplos:
    • Servicios de Google Cloud acceso: El agente solicita un token de acceso vinculado. Este token está vinculado criptográficamente al certificado X.509 único del agente para ayudar a evitar el robo de tokens. Para obtener más información, consulta Seguridad y administración.
    • Accede a herramientas externas: Para autenticarse directamente en un servicio externo con su propia identidad, el agente solicita un token de ID de OIDC. Para recuperar credenciales almacenadas (como claves de API o tokens de OAuth) de un proveedor de autenticación, el agente usa el administrador de autenticación de Agent Identity, que admite tanto la autoridad delegada por el usuario como la autoridad propia del agente.

Beneficios de la identidad del agente

La identidad del agente mejora la seguridad en comparación con las cuentas de servicio estándar.

  • Aislamiento sólido: A diferencia de las cuentas de servicio, las identidades de los agentes no se comparten entre varias cargas de trabajo de forma predeterminada, no se pueden suplantar y no permiten que los desarrolladores generen claves de cuentas de servicio de larga duración.
  • Seguridad de las credenciales: Las políticas de acceso adaptado al contexto predeterminadas hacen que los tokens vinculados no se puedan reproducir, lo que ayuda a proteger contra el robo de tokens y la apropiación de cuentas.
  • Enfoque de privilegio mínimo: Proporciona identidades por agente en lugar de cuentas de servicio compartidas para eliminar los agentes con permisos excesivos.
  • Menos fricción: Automatiza los flujos de OAuth complejos y administra las claves de API para una integración de herramientas más sencilla.
  • Observabilidad mejorada: Proporciona registros de auditoría claros. Cuando un agente actúa en nombre de un usuario, los registros muestran las identidades del agente y del usuario.

Limitaciones

  • Roles de bucket heredados de Cloud Storage: No puedes otorgar roles de bucket heredados a las identidades de agentes (por ejemplo, storage.legacyBucketReader).

¿Qué sigue?