Guia tecnica
La guía definitiva para las identidades de agentes de IA en AWS, Azure y GCP.
Detrás de cada agente de IA hay una identidad que necesita ser autenticada, autorizada y supervisada. Sin embargo, en AWS, Azure y GCP, estas identidades se comportan de manera diferente. Si eres un profesional de la seguridad, esta es tu guía práctica para diseñar un enfoque coherente y seguro en entornos multinube.
Guia tecnica
La guía definitiva para las identidades de agentes de IA en AWS, Azure y GCP.
Detrás de cada agente de IA hay una identidad que necesita ser autenticada, autorizada y supervisada. Sin embargo, en AWS, Azure y GCP, estas identidades se comportan de manera diferente. Si eres un profesional de la seguridad, esta es tu guía práctica para diseñar un enfoque coherente y seguro en entornos multinube.
Sección 1
¿Por qué existe esta guía?
Tus agentes de IA ya actúan como identidades. La pregunta es: ¿sabes cuáles?
Cuando un agente envía un correo electrónico, se está autenticando como alguienCuando consulta una base de datos, tiene de alguien permisos. Cuando accede a un recurso compartido de archivos, alguien Aparece en los registros de auditoría. ¿Pero quién?
Esto es lo que la documentación del proveedor no te dirá:
- Los agentes de Azure pueden actuar bajo múltiples identidades en una sola conversación: usuario, fabricante y el propio agente.
- La configuración predeterminada de GCP comparte una única identidad en todos sus agentes dentro de un mismo proyecto.
- AWS te da control total, lo que significa que cualquier mala configuración es completamente tu responsabilidad.
Esta guía cubre lo que la documentación de la plataforma no cubre: no cómo para configurar agentes, pero Lo que Las identidades que realmente utilizan al actuar y lo que eso implica para su nivel de seguridad.
Las tres plataformas de un vistazo:
Plataforma
Filosofía de la identidad
AWS
Tu cuenta, tu identidad. Control total, responsabilidad total.
Azure
Identidad flexible para la complejidad empresarial.
GCP
Infraestructura gestionada, identidad configurable.
Para quién es esta guía:
Responsables de seguridad encargados de la gestión de identidades y accesos (IAM), la seguridad en la nube o la gobernanza de la IA en entornos de producción.
Lo que aprenderás:
- ¿Por qué la identidad del agente es diferente de las identidades no humanas tradicionales?
- Cómo conceptualiza cada plataforma en la nube principal la identidad del agente
- ¿Qué modelo de identidad utiliza cada plataforma (con ejemplos específicos)?
- Los principales riesgos de identidad para cada plataforma
- Listas de verificación prácticas para la gestión de identidades
Antes de empezar, pregúntate:
- ¿Sabes qué identidades utilizan tus agentes para cada herramienta?
- ¿Puede un usuario con pocos privilegios activar acciones de alto privilegio a través de un agente?
- ¿Es posible revocar el acceso del agente sin volver a implementar el código?
- ¿Disponen de un registro de auditoría único para las acciones de cada agente?
- ¿Puedes rastrearlo hasta un empleado?
Si respondiste “no” a alguna de estas preguntas, no estás solo, y esta guía te ayudará.
Esta no es una guía genérica sobre seguridad en la nube. Se centra específicamente en la identidad del agente; es decir, quién es el agente cuando actúa.
La idea principal
No se puede predecir qué hará un agente de IA a continuación.
Esto no es un error, es precisamente la clave. Los agentes son valiosos porque son adaptables. Pero esa adaptabilidad plantea desafíos de seguridad de identidad para los que los controles tradicionales de NHI no fueron diseñados.
Sección 2
Por qué las identidades de los agentes son diferentes
Antes de profundizar en las especificaciones de la plataforma, veamos qué hace únicas las identidades de los agentes de IA. Este contexto es fundamental para evaluar las directrices específicas de la plataforma que se presentan a continuación.
Comparación rápida: Humano vs. Sistema Nacional de Salud tradicional vs. Agente de IA
Dimensión
Personas
Seguro Nacional de Salud tradicional
Filosofía de la identidad
Comportamiento
Variable, basado en el juicio
Determinista, guionizado
No determinista, adaptativo
Toma de decisiones
Contextual, responsable
Preprogramado o ninguno
Basado en modelos y sensible al contexto.
Patrones de acceso
Variable, auditable
Predecible, consistente
Variable, dependiente de la tarea
Permisos
Basado en roles, revisable
Estático, de larga duración
Variable, dependiente de la tarea
Susceptibilidad a la entrada adversaria
Ingeniería social
Requiere robo de credenciales o cambio de código/configuración.
Subversión de entrada de solicitud/herramienta
Tres riesgos de identidad únicos para los agentes
1. Secuestro de decisiones mediante manipulación
Las cuentas de servicio ejecutan flujos de trabajo deterministas. Para modificar su funcionamiento, un atacante normalmente necesita tener control sobre el código del flujo de trabajo o sobre su configuración/entradas en tiempo de ejecución.
En cambio, los agentes de IA responden a indicaciones. Para cambiar qué they Para ello, necesitas elaborar la información adecuada.
Implicación: La inyección instantánea altera la toma de decisiones de un agente mientras opera con una identidad válida, produciendo efectos similares a la suplantación de identidad sin comprometer las credenciales. La identidad no cambia; lo que se ve comprometido es la selección de herramientas, las acciones y las decisiones que el agente toma bajo esa identidad. Los controles de acceso tradicionales no pueden evitarlo.
Ejemplo: Un atacante inserta instrucciones en un documento que el agente procesa, lo que provoca que llame a su conector SQL autorizado con SELECCIONAR * DE clientes DONDE límite_crédito > 100000 y pasar los resultados a su herramienta de correo electrónico; ambas herramientas están permitidas, pero la consulta y la ruta de exfiltración nunca fueron la intención.
2. Dispersión de credenciales en las superficies de interacción
Las credenciales NHI tradicionales (cuentas de servicio, claves API) suelen filtrarse a través de superficies de código/configuración: secretos comprometidos, archivos de configuración, variables de entorno.
Los agentes aumentan las vías de fuga de información, ya que los secretos pueden transmitirse a través de mensajes y respuestas en lenguaje natural, la entrada/salida de herramientas, las transcripciones de chat y los registros de depuración, especialmente durante el desarrollo y la resolución de problemas. Esto se puede evitar con un buen diseño, pero es común en las primeras implementaciones.
Ejemplo: El agente incluye accidentalmente la clave API en una respuesta, o la solicitud al usuario incluye credenciales confidenciales que el agente expone.
Implicación: La higiene de las credenciales debe extenderse a la entrada/salida de los agentes, no solo al código y la configuración.
Principio de diseño: Mantenga los secretos fuera del ámbito del lenguaje natural. Transfiera las credenciales a través de conectores seguros/administradores de secretos y parámetros de herramientas estructurados, no mediante texto de solicitud.
3. Requisitos de permisos dinámicos
Las cuentas de servicio ejecutan tareas programadas y predecibles, por lo que es fácil establecer una base de referencia de lo que es "normal". Los permisos estáticos funcionan para las cuentas de servicio porque su comportamiento es estático.
Los agentes de IA responden a las solicitudes de los usuarios, por lo que cada interacción es diferente. Lo que se considera "normal" cambia constantemente. Los permisos estáticos pueden ser excesivos (lo que conlleva riesgos) o insuficientes (lo que provoca fallos de funcionamiento). Los usuarios forman parte del límite de acceso. Un usuario con pocos privilegios puede activar una acción que requiere muchos privilegios si la identidad de la herramienta del agente tiene un alcance excesivo o se delega desde una cuenta de creador/servicio con privilegios.
Implicación: Los agentes necesitan permisos limitados a la tarea específica, no un acceso amplio y permanente.
EjemploOtorgar acceso de lectura a una base de datos solo durante la duración de una consulta, no de forma permanente. La detección de anomalías tradicional (es decir, la desviación de la línea base) no funciona bien porque no se puede predecir qué hará un agente de IA a continuación.
Por qué los controles tradicionales del Sistema Nacional de Salud son insuficientes
Enfoque tradicional
Por qué falla para los agentes
Otorgar permisos amplios y permanentes
Los agentes necesitan permisos dinámicos limitados a la tarea específica.
Asignaciones de permisos estáticos
Incluso con tokens de corta duración, el alcance de los permisos suele ser estático y demasiado amplio.
Supervisar las desviaciones del cronograma.
Los agentes no tienen horarios predecibles.
revisiones de acceso anuales
En entornos de ritmo acelerado, los agentes pueden crearse y modificarse con frecuencia.
Suponga un comportamiento coherente
Los agentes son inherentemente variables
Una nota sobre la terminología:
Cada proveedor de servicios en la nube ofrece múltiples estructuras similares a agentes bajo diferentes marcas: agentes de Bedrock, agentes de Copilot Studio, proyectos de AI Foundry, agentes de Vertex AI, entre otros. En esta guía, definimos "agente" como cualquier sistema impulsado por IA que puede invocar herramientas o acceder a recursos de forma autónoma bajo una identidad. El nombre específico del producto es menos importante que el modelo de identidad que utiliza.
Si utilizas múltiples nubes:
Usted gestiona varios modelos de identidad simultáneamente. Cada sección de la plataforma que se describe a continuación es independiente, pero es importante tener en cuenta que el desafío de la gobernanza se agrava al interactuar con diferentes nubes.
Sección 3
Cómo funcionan las identidades de los agentes en cada plataforma.
La pregunta fundamental: ¿Quién es este agente?
Cada nube responde a esta pregunta de manera diferente, según su filosofía de identidad. Antes de entrar en detalles, aquí presentamos un marco unificador para comprender las diferencias.
El espectro de la identidad: Propiedad → delegación → opacidad
Todos los modelos de identidad de agente se sitúan en algún punto de este espectro:
Posición
Qué significa
Ejemplo
Propiedad del activo:
Usted posee y controla todos los componentes de identidad.
AWS
Delegación
La identidad cambia según el contexto.
Azure
Opacidad
Entorno de ejecución gestionado por el proveedor con inspección/telemetría limitada del cliente en el contexto de ejecución.
GCP
Las plataformas pueden abarcar más de una posición dependiendo del producto (por ejemplo, Copilot Studio frente a Foundry).
Estos modelos optimizan diferentes cosas:
- Propiedad del activo: Maximiza el control del cliente y delimita claramente el radio de acción, pero requiere una ingeniería IAM disciplinada.
- Delegación Puede mejorar la rendición de cuentas humana (es decir, acciones vinculadas al iniciador), pero introduce contextos de identidad mixtos y aumenta el riesgo de herencia de privilegios a través de conectores/creadores.
- Opacidad Reduce los gastos operativos, pero limita la inspección y el análisis forense.
Tenga en cuenta este espectro al leer el enfoque de cada plataforma.
TL; DR
AWS: Tu cuenta, tu identidad.
El control total implica la responsabilidad total: defina los roles de IAM, aplique el principio de mínimo privilegio y asuma la responsabilidad de sus errores.
Lista de verificación de gestión de identidad
- Agente de mapeo → rol de ejecución → (roles relacionados con la herramienta, si corresponde)
- Revisar los permisos de cada rol (Privilegios mínimos)
- Seguimiento del linaje del agente: quién lo creó, qué herramientas utiliza y (para agentes basados en chat) qué usuarios pueden invocarlo.
- Utilice límites de permisos (medidas de control de IAM que establecen los permisos máximos que puede tener un rol, independientemente de las políticas asociadas).
- Supervise las suposiciones de rol para detectar anomalías (horas inesperadas, frecuencia inusual, direcciones IP de origen desconocidas o acceso a recursos fuera del alcance esperado del agente).
AWS: Tu cuenta, tu identidad (Bedrock y AgentCore)
La filosofía de AWS
AWS trata a los agentes de IA de la misma manera que trata cualquier otra carga de trabajo: La verificación de identidad tiene su origen en su cuenta.Esto incluye tus roles de IAM, tus buckets de S3 y tus registros de CloudWatch. Si bien Bedrock es un servicio administrado (AWS opera el entorno de ejecución), tus controles de identidad (los roles, las políticas y los registros de auditoría) residen en tu cuenta.
En AWS, la identidad siempre se gestiona mediante IAM. La identidad de un agente es un rol de IAM, al igual que la de una función Lambda o una instancia EC2. Si sabe cómo proteger IAM, tendrá la base para proteger la identidad de los agentes (aunque estos presentan riesgos específicos, como se explica en la Sección 2).
Cómo se aplica esto a los agentes de Bedrock
AWS Bedrock es el servicio administrado de Amazon para la creación de agentes de IA. Al crear un agente Bedrock, AWS aprovisiona todo lo necesario dentro de tu cuenta, pero debes comprender cómo se estructura la identidad.
Cada agente de Bedrock tiene un Función de ejecución del agente, la identidad principal que el agente utiliza para actuar.
Si el agente tiene grupos de acciones (las herramientas y capacidades que configura para su agente), cada grupo de acciones tiene implicaciones de identidad:
Tipo de grupo de acción
Impacto de la identidad
función lambda
Lambda se ejecuta bajo su propio rol de ejecución (independiente del rol de agente). Lambda puede llamar a API externas, acceder a servicios de AWS o ejecutar lógica personalizada, todo ello bajo su rol de IAM.
Control de retorno
No requiere ninguna función adicional; la acción devuelve el control a la aplicación que la invocó, la cual se encarga de la ejecución bajo su propia identidad.
El resultado
Un agente puede involucrar múltiples roles de IAM, según la configuración del grupo de acciones: el rol de ejecución del agente, además de cualquier rol de ejecución de Lambda u otros roles de servicio invocados por los grupos de acciones. Usted crea y administra estos roles. Bedrock no los crea automáticamente.
Qué significa esto para usuarios:
- Puedes ver a qué tiene permitido acceder el agente dentro de AWS (a través de las políticas de IAM), pero los registros no te dirán por qué el agente decidió acceder a algo.
- Usted controla la identidad y es responsable de protegerla.
- Los patrones de seguridad estándar de AWS se aplican directamente.
Pregunta clave a responder:
¿Qué roles de IAM corresponden a qué agentes?
Riesgo clave para la identidad:
Roles con privilegios excesivos que otorgan más acceso del que el agente necesita.
Dado que usted crea el rol de IAM, cualquier error es responsabilidad suya. Comience con permisos mínimos y amplíelos solo cuando sea necesario.
Impacto en caso de compromiso:
Roles con privilegios excesivos que otorgan más acceso del que el agente necesita. Dado que usted crea el rol de IAM, cualquier error es responsabilidad suya. Comience con permisos mínimos y amplíelos solo cuando sea necesario.
Ya sea mediante robo de credenciales, concesión excesiva de permisos o manipulación inmediata que provoque acciones no deseadas:
El atacante obtiene acceso a todo lo que puede modificar el rol de ejecución del agente: modelos base, buckets de S3, bases de conocimiento, además de cualquier rol de IAM adicional si los grupos de acciones invocan otros servicios de AWS (funciones Lambda, puntos finales de API Gateway, etc.).
El radio de la explosión está limitado por los permisos de IAM que hayas configurado.
También en AWS: AgentCore (Code-First)
Para los desarrolladores que crean agentes mediante código (no con la interfaz de usuario sin código de Bedrock), AWS ofrece AgentCore. El modelo de identidad sigue la misma filosofía de AWS, donde los agentes utilizan roles de IAM, pero con diferencias clave:
Definición de identidad basada en el enfoque "code-first": A diferencia de la configuración basada en consola de Bedrock, la identidad de AgentCore se define mediante configuraciones de infraestructura como código y de despliegue. Los roles de IAM se especifican normalmente en manifiestos de aplicaciones o plantillas de IaC, lo que otorga a los desarrolladores un control total, pero exige que lo hagan correctamente.
Mayor riesgo de configuración incorrecta: Debido a que la identidad está definida por código, AgentCore conlleva un mayor riesgo de:
- Roles con privilegios excesivos codificados en la configuración de la aplicación.
- Credenciales incrustadas en el código fuente
- Ámbito de permisos inconsistente en los distintos entornos (desarrollo/pruebas/producción).
- Credenciales subidas accidentalmente al control de versiones (que quedan expuestas en el historial de Git incluso después de su eliminación).
Responsabilidad del desarrollador: La correcta definición del alcance de los permisos recae principalmente en el equipo de desarrollo, con menos orientación a través de la consola que el enfoque gestionado de Bedrock. No existe ningún asistente que guíe la configuración del principio de mínimo privilegio.
Tiene la misma base de IAM que Bedrock, pero los riesgos operativos cambian: de la mala configuración por parte del administrador a la mala configuración por parte del desarrollador.
Variación de la identidad entre versiones de agentes (AWS Bedrock)
Soportes de la roca madre versiones y alias Para los agentes, un alias puede redirigir el tráfico a diferentes versiones del agente, lo cual es útil para implementaciones graduales o pruebas A/B. Sin embargo, esto genera un riesgo de gobernanza de identidades.
Las distintas versiones pueden tener diferentes:
- Roles de ejecución
- Configuraciones de barandillas de seguridad
- Ámbitos de permisos
El riesgo: Los equipos de seguridad pueden creer que un agente está protegido porque la versión actual cuenta con las medidas de seguridad adecuadas, cuando en realidad el tráfico se redirige a una versión anterior menos restringida mediante un alias. Esto representa un riesgo para el ciclo de vida y la gobernanza, no una vulnerabilidad en Bedrock en sí, pero requiere una gestión explícita de versiones y alias en el programa de seguridad del agente.
TL; DR
Azure: Múltiples identidades, un solo agente.
El modelo de autenticación flexible permite integraciones empresariales, pero fragmenta la responsabilidad. Es importante saber qué modo de autenticación utiliza cada conector.
Lista de verificación de gestión de identidad
- Mapa que indica el modo de identidad que utiliza cada conector.
- Permisos de audita del creador (considere la posibilidad de crear cuentas de servicio dedicadas).
- Tenga en cuenta que un agente puede generar tres ubicaciones de registro de auditoría.
- Cree cuentas dedicadas para la propiedad de los conectores (no cuentas personales).
- Planificar el ciclo de vida del propietario del conector (¿qué ocurre cuando se marcha?)
Azure/Microsoft: Identidad flexible para la complejidad empresarial.
La filosofía de Microsoft
Microsoft reconoce que los entornos empresariales son complejos. Los diferentes conectores necesitan diferentes autenticaciones: a veces debe autenticarse el usuario, a veces una cuenta de servicio, a veces la persona que creó el agente. En lugar de imponer un modelo, Azure admite múltiples modos de identidad simultáneamente.
Esta flexibilidad permite integraciones potentes, pero crea complejidad: el mismo agente puede actuar con identidades diferentes dependiendo de lo que esté haciendo.
Cómo se aplica esto a Copilot Studio
Microsoft documenta dos modos de autenticación principales para las acciones de Copilot Studio:
Modo de autenticación
Cuando se utiliza
¿Quién está "actuando"?
La auditoría muestra
Autenticacion de usuario
Cuando el acceso deba restringirse a usuarios específicos
El usuario hablando con el agente
El sistema de reservas de escritorios, interactivo y fácil de usar, ayuda a gestores y empresas a adaptarse a la nueva rutina laboral. El sistema inteligente optimiza espacios y horarios según necesidades reales.
Autenticación del autor del agente
Para acceso implícito o de bajo riesgo
Para acceso implícito o de bajo riesgo
Fabricante
En la práctica, también aparece un tercer artefacto de identidad: el principal de servicio del agente (un Entra ID identidad de la aplicación) utilizada para ciertas llamadas a la API. Esto significa que un solo agente puede generar entradas de auditoría bajo tres identidades diferentes, dependiendo de la función que esté desempeñando.
Ejemplo de flujo: El usuario le pide al agente que “Resumir nuestro embudo de ventas y notificarme”:
- El agente realiza consultas al CRM utilizando la conexión del autor del agente.
- Publica un resumen en Teams utilizando la entidad principal del servicio del agente.
- Envía correos electrónicos utilizando los permisos delegados del usuario.
Tres acciones, tres identidades, una conversación.
Qué significa esto para usuarios:
- Los registros de auditoría se fragmentan en distintos contextos de identidad, por lo que correlacionar quién decidió, quién ejecutó y quién se vio afectado no es tarea fácil.
- Los usuarios con privilegios limitados pueden acceder a recursos con privilegios elevados mediante credenciales de creador.
Pregunta clave a responder:
¿Qué modo de autenticación utiliza cada conector?
Riesgo clave para la identidad:
Escalada de privilegios mediante credenciales de autor del agente.
Si el creador (quien haya configurado el conector) tiene permisos elevados, todos los usuarios de ese agente heredan esos permisos para las acciones que utilicen dicho conector.
Microsoft recomienda la autenticación de usuario cuando el acceso debe restringirse a usuarios específicos; la autenticación de agente autor se utiliza en escenarios de acceso implícito o de bajo riesgo. El uso de credenciales de creador puede conllevar el intercambio excesivo de datos o capacidades.
Impacto en caso de compromiso:
Ya sea mediante robo de credenciales, compromiso de la cuenta del creador o manipulación instantánea:
El radio de impacto depende del modo de identidad utilizado y de las herramientas/ámbito de acceso configurados para el agente. En el peor de los casos, el creador tiene derechos de administrador, por lo que todos los usuarios heredan esos derechos para ese conector. La investigación requiere correlacionar tres ubicaciones de auditoría distintas.
Lista de verificación de gestión de identidad
- Mapa que indica el modo de identidad que utiliza cada conector.
- Permisos de audita del creador (considere la posibilidad de crear cuentas de servicio dedicadas).
- Tenga en cuenta que un agente puede generar tres ubicaciones de registro de auditoría.
- Cree cuentas dedicadas para la propiedad de los conectores (no cuentas personales).
- Planificar el ciclo de vida del propietario del conector (¿qué ocurre cuando se marcha?)
También en Azure: Microsoft Foundry (anteriormente AI Foundry)
El comportamiento de la identidad aún está en desarrollo, por lo que conviene tratarlo como algo distinto de Copilot Studio.
Microsoft Foundry es la plataforma de Azure basada en código para crear agentes de IA, distinta del enfoque sin código de Copilot Studio. Existe en dos formas:
- Clásico de Foundry: el lanzamiento original
- Fundición (nueva): La iteración actual con semántica de identidad actualizada
El comportamiento en materia de identidad difiere entre lo clásico y lo nuevo. En la nueva Foundry, los agentes pueden usar un método explícito. ID de agente para identificación. Sin embargo, si no se publica un agente, la identidad puede ser alcance del proyecto en lugar de ser específico del agente.
La semántica de identidad aún está en evolución. No todas las rutas de ejecución se han investigado por completo; el comportamiento puede variar según el estado de implementación, la configuración y la versión de Foundry.
TL; DR
GCP: Simplicidad gestionada, visibilidad limitada
Evita caer en la trampa de la cuenta de servicio predeterminada. Acepta que no puedes ver el interior de la infraestructura de Google.
Lista de verificación de gestión de identidad
- Verifique que los agentes no utilicen el agente de servicio predeterminado de Reasoning Engine.
- Comprobar el patrón: service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re... (predeterminado)
- Prefiera las cuentas de servicio personalizadas para cargas de trabajo de producción.
- Acepte la visibilidad limitada de la infraestructura y diseñe en consecuencia.
- Documentar el modelo de cuenta de servicio para el cumplimiento
GCP: Infraestructura gestionada, identidad configurable
La filosofía de GCP
GCP prioriza la simplicidad: Google gestiona la infraestructura, tú configuras la identidad..
El entorno de ejecución es gestionado y opaco: no se puede inspeccionar el entorno de ejecución subyacente, aunque IAM esté configurado a través del proyecto. Esto reduce la carga operativa, pero limita la visibilidad.
En GCP, la identidad se basa en las cuentas de servicio. Usted elige si desea usar una cuenta de servicio personalizada o confiar en el agente de servicio predeterminado de Google, y esa elección determina su nivel de aislamiento.
Cómo se aplica esto al motor de agentes de IA de Vertex (motor de razonamiento)
Cuando se implementa un agente, la identidad funciona en dos capas:
Capa 1: Agente de servicio administrado por Google
Google crea automáticamente un agente de servicio de Reasoning Engine para tu proyecto. Esto es necesario para que los agentes implementados funcionen. Está limitado al ámbito del proyecto y gestionado por Google; no puedes evitarlo.
Capa 2: Su elección de cuenta de servicio
Para el acceso real a los recursos de su agente, usted elige:
Opción
Lo que es
Nivel de aislamiento
Cuenta de servicio al cliente
Usted crea una SA específica para el agente.
Óptimo (recomendado para producción)
Agente de servicio predeterminado
Utilice el proyecto S administrado por Google
Pobre (compartido entre todos los agentes del proyecto)
Critical
Si no configura explícitamente una cuenta de servicio personalizada, su agente utilizará el agente de servicio predeterminado, que se comparte entre todos los agentes de su proyecto. Un agente comprometido implica que todos los agentes quedarán expuestos.
Qué significa esto para usuarios:
- La elección de la identidad se realiza durante el despliegue, por lo que conviene configurar las SA personalizadas desde el principio.
- Agente de servicio predeterminado = todos los agentes de un proyecto comparten una identidad = aislamiento deficiente
- Cuentas de servicio personalizadas = cada agente tiene su propia identidad = buen aislamiento
- Visibilidad limitada de la infraestructura administrada por Google (solo se ven los registros, no el tiempo de ejecución).
Pregunta clave a responder:
¿Este agente está utilizando una cuenta de servicio personalizada o el agente de servicio predeterminado?
Riesgo clave para la identidad:
El SA predeterminado tiene acceso amplio a BigQuery/Storage por defecto. Si varios agentes lo comparten, si uno se ve comprometido, todos se ven comprometidos.
El SA predeterminado tiene acceso amplio a BigQuery/Storage por defecto. Si varios agentes lo comparten, si uno se ve comprometido, todos se ven comprometidos.
Impacto en caso de compromiso:
Ya sea mediante robo de credenciales, compromiso de la cuenta del creador o manipulación instantánea:
El radio de impacto depende del modo de identidad utilizado y de las herramientas/ámbito de acceso configurados para el agente. En el peor de los casos, el creador tiene derechos de administrador, por lo que todos los usuarios heredan esos derechos para ese conector. La investigación requiere correlacionar tres ubicaciones de auditoría distintas.
Lista de verificación de gestión de identidad
- Verifique que los agentes no utilicen el agente de servicio predeterminado de Reasoning Engine.
- Comprobar el patrón: service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re... (predeterminado)
- Prefiera las cuentas de servicio personalizadas para cargas de trabajo de producción.
- Acepte la visibilidad limitada de la infraestructura y diseñe en consecuencia.
- Documentar el modelo de cuenta de servicio para el cumplimiento
Cómo identificar el agente de servicio predeterminado
Busque este patrón en la configuración de su cuenta de servicio:
servicio-{NÚMERO_DE_PROYECTO}@gcp-sa-aiplatform-re.iam.gserviceaccount.com
El -re El sufijo indica el agente de servicio de Reasoning Engine. Este agente es administrado por Google y tiene un alcance de proyecto, lo que significa que se comparte entre todos los agentes de su proyecto a menos que configure cuentas de servicio personalizadas.
Los protocolos y la orquestación multiplican el riesgo de identidad.
Más allá de los modelos de identidad específicos de cada plataforma que se han tratado anteriormente, varios mecanismos transversales añaden complejidad:
- MCP (Protocolo de Contexto Modelo) — Estandariza la forma en que los agentes se conectan a las herramientas.
- Comunicación de agente a agente (A2A) — Agentes que invocan a otros agentes
- Orquestación del flujo de trabajo — Cadenas de acciones de agentes coordinadas por sistemas externos
Punto crítico: Estos mecanismos abstraen el acceso a las herramientas pero no No define la identidad, la autorización o la semántica de delegación. El protocolo maneja como conectar, no quién está autorizado.
Cuando los agentes llaman a otros agentes, o cuando los flujos de trabajo encadenan múltiples acciones de agentes, la atribución de identidad se convierte en transitivoUn usuario activa al Agente A, que llama al Agente B, el cual accede a una base de datos. El registro de auditoría se fragmenta. ¿De quién es la identidad que accede a la base de datos: del Agente A, del Agente B o del usuario original?
Esto agrava los desafíos de gobernanza descritos para cada plataforma. Los protocolos son la infraestructura; no resuelven el problema de la identidad.
Hacia dónde va esto
Los agentes de hoy utilizan herramientas. Los agentes del mañana crearán agentes.
Cuando un agente puede generar subagentes —cada uno con su propia identidad— la proliferación de identidades se vuelve recursiva. Una sola solicitud de usuario podría activar un agente que crea tres subagentes, cada uno accediendo a sistemas diferentes con identidades distintas, algunos de los cuales podrían crear sus propios subagentes.
Esto no es ciencia ficción. La orquestación multiagente ya se utiliza en organizaciones líderes. Los desafíos de gestión de identidades que hemos descrito en esta guía se agravarán.
Por ahora, concéntrese en los modelos de identidad de agente único mencionados anteriormente. La gobernanza multiagente es la próxima frontera, pero no se puede llegar a ella sin antes resolver el problema de la identidad de agente único.
TL; DR
Un resumen del manual de estrategias
Aquí les presentamos un resumen de las mejores prácticas que analizaremos con más detalle a la izquierda.
Descubrimiento e inventario
- Agentes de catálogo por plataforma
- Cuentas/roles de servicio de mapas por agente
- Titularidad del documento
- Clasificar por nivel de riesgo
Gestión de credenciales y permisos
- Utilice fichas de corta duración.
- Habilitar la rotación automática
- Priorizar el principio de mínimo privilegio
- Almacenar de forma segura
Monitoreo y respuesta
- Utilice el registro centralizado
- Habilitar alertas específicas para cada agente
Sección 4
Manual de mejores prácticas de identidad
Las siguientes listas de verificación resumen las directrices específicas de la plataforma mencionadas anteriormente en pasos prácticos. Úselas como punto de partida para su programa de identidad de agentes.
Descubrimiento e inventario
Antes de poder contratar agentes, necesitas saber con qué cuentas.
Agentes de catálogo por plataforma
Incluir desarrollo/pruebas/preproducción, no solo producción.
- Enumera todos los agentes de AWS Bedrock (consulta la consola de Bedrock o CloudFormation).
- Listar todos los agentes de Azure Copilot Studio (Centro de administración de Power Platform)
- Lista todos los agentes de GCP Vertex AI (consola de Vertex AI)
Cuentas/roles de servicio de mapas por agente
Agente
Plataforma
Identidad primaria
Identidades secundarias
Ejemplo
AWS
ARN del rol de ejecución del agente
ARN de roles relacionados con herramientas (Lambda, API Gateway, etc.)
Ejemplo
Azure
Director de servicio
Credenciales del creador, delegación de usuario
Ejemplo
GCP
Correo electrónico de la cuenta de servicio
N/A
- Para AWS: Rol de ejecución de documentos + todos los roles relacionados con herramientas (Lambda, API Gateway, etc.)
- Para Azure: Entidad de servicio de documentos + todos los modos de identidad del conector
- Para GCP: Documentar el modelo de cuenta de servicio (personalizado/automático/predeterminado)
Titularidad del documento
- Documentar el creador, el propietario de la identidad y quién puede modificar los permisos para cada agente.
- Verifique que la propiedad corresponda a cuentas funcionales, no a cuentas personales.
Clasificar por nivel de riesgo
Nivel de riesgo
Criterios
Frecuencia de revisión
Alto
Accede a información personal identificable, datos financieros y sistemas administrativos.
Noticias
Media
Accede a datos empresariales y sistemas internos.
Mensual
Bajo
Datos públicos de solo lectura, entorno aislado
Trimestral
- Asigne un nivel de riesgo a cada agente y programe las revisiones correspondientes.
Gestión de credenciales y permisos
Tokens de corta duración
- Utilice tokens con una duración inferior a 1 hora para operaciones sensibles.
- Prefiera OAuth/OIDC a las claves API estáticas.
- Evite las claves de cuenta de servicio de larga duración.
Rotación automática
- Habilitar la rotación automática de credenciales donde sea compatible
- Para AWS: utilice roles de IAM (rotación automática integrada).
- Para Azure: Configurar la rotación del certificado de la entidad de servicio
- Para GCP: utilice la federación de identidades de carga de trabajo siempre que sea posible.
Permisos de mínimo privilegio
- Comience con cero permisos y agregue solo lo que sea necesario.
- Documenta POR QUÉ existe cada permiso.
- Utilice límites de permisos (AWS) o acceso condicional (Azure) para limitar los permisos.
- Revisión con IAM Access Analyzer (AWS), permisos de Entra (Azure)
Almacenamiento seguro
- Nunca introduzca credenciales en las solicitudes ni las codifique directamente en la configuración del agente.
- Utilice administradores de secretos (AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager).
- Auditar el acceso a las credenciales
Monitoreo y respuesta
Registro centralizado
Importante: Los registros capturan la ejecución, no la intención. Verás lo que hizo el agente, no por qué decidió hacerlo. Esto limita la profundidad de la investigación en incidentes específicos de IA.
Plataforma
Fuente de registro principal
Qué capturar (si está habilitado)
AWS
CloudWatch, CloudTrail
Invocaciones de agentes, suposiciones de roles de IAM, llamadas a la API (cuando estén configuradas)
Azure
Monitor de Azure, Entra ID los registros
Los 3 contextos de identidad, actividad del conector (según la configuración de telemetría)
GCP
Registro en la nube
Uso de la cuenta de servicio, ejecución del agente (visibilidad limitada a lo que muestra Google)
- Exportar registros a SIEM
- Establecer la retención según los requisitos de cumplimiento
- Crear flujos/grupos de registros específicos para cada agente.
- Verifique que el registro esté realmente habilitado; no asuma que las configuraciones predeterminadas capturan la actividad del agente.
Alertas específicas para cada agente
Crear alertas para:
- Intentos con permiso denegado
- Nuevo acceso a recursos (es decir, el agente interactúa con nuevos sistemas)
- Volumen de actividad inusual
- Ejecución fuera del horario laboral (si los agentes tienen horarios previstos)
- Intentos de escalada de privilegios
Guía de referencia rápida para la respuesta a incidentes
Nota: Estos registros muestran las acciones del agente si el registro estaba habilitado. CloudTrail y Azure Monitor no muestran automáticamente las invocaciones específicas del agente; es necesario correlacionar la actividad de IAM/Entra con la identidad del agente.
Plataforma
Primera respuesta
Registros a revisar (si están configurados)
Escalada
AWS
Revocar el rol de ejecución del agente
CloudWatch, CloudTrail (correlacionar con el ARN del rol del agente)
Soporte de AWS
Azure
Deshabilitar el agente en Power Platform
Los tres registros de auditoría: agente, fabricante y usuarios (cada uno puede requerir consultas separadas).
Microsoft Support
GCP
Revocar permisos de SA
Registro en la nube (limitado a lo que Google muestra; sin inspección en tiempo de ejecución)
asistencia de Google
- Documentar los procedimientos de respuesta a incidentes por plataforma.
- Ten en cuenta que Azure requiere comprobar 3 ubicaciones de auditoría.
- Aceptar los límites de visibilidad de la infraestructura de GCP en la planificación de IR
- Comprueba que tu sistema de registro capture la actividad del agente antes de necesitarlo para IR.
Sección 5
Referencia rápida
Matriz de decisión de la plataforma
Factor
Base de AWS
Azure Copilot Studio
GCP Vertex AI
Modelo de identidad
Individual (rol IAM)
Múltiple (2 modos + artefactos)
Cuenta de servicio individual
Complejidad:
Media
Alto
Bajo
Visibilidad
Pleno
fragmentada
Limitada
Control
Pleno
Parcial
Limitada
Carga operativa
Alto
Media
Bajo
Uso recomendado
Industrias reguladas, necesidad de control total
Integraciones empresariales, ecosistema de Microsoft
Despliegue rápido, preferencia gestionada
Qué esperar de cada plataforma
Las empresas suelen elegir las plataformas de agentes en función de su funcionalidad, compatibilidad con el ecosistema y facilidad de uso, y posteriormente gestionan la seguridad de la identidad. A continuación, se muestra cómo se ve la gestión de identidades según la plataforma elegida:
Si utilizas AWS Bedrock:
- Espere visibilidad completa de la infraestructura
- Planificar la gestión de roles de IAM a gran escala.
- Aprovechar los patrones de seguridad de AWS existentes
- Presupuesto de tiempo para gastos generales operativos
Si utilizas Azure Copilot Studio:
- Se prevé gestionar tres contextos de identidad por agente.
- Plan para registros de auditoría fragmentados
- Revise cuidadosamente los permisos del fabricante.
- Diseñar la estrategia de propiedad del conector desde el principio
Si utilizas GCP Vertex AI:
- Se prevé una visibilidad limitada de la infraestructura.
- Planifica en función de los componentes gestionados por Google.
- Evite las cuentas de servicio predeterminadas desde el primer día.
- Acepte las compensaciones de visibilidad en su planificación de relaciones con los inversores.
Guía rápida de respuesta a incidentes
Nota: El "mal comportamiento del agente" constituye una categoría de incidente única. A diferencia de las cuentas de servicio, que fallan de forma predecible, los agentes pueden comportarse de manera inesperada debido a manipulación inmediata, desviaciones del modelo o comportamientos emergentes, no solo a fallos de seguridad. Su proceso de respuesta a incidentes debe tener en cuenta esta ambigüedad.
AWS: El agente está funcionando mal.
- Inmediatamente: Revocar el rol de ejecución del agente (aws iam delete-role-policy)
- Investigar: Registros de CloudWatch para el agente, CloudTrail para la actividad de IAM
- Contiene: Desactive cualquier integración de herramientas (funciones Lambda, puntos finales de API u otros servicios a los que llame el agente).
- Remediar: Revisar permisos, volver a implementar con privilegios mínimos.
Azure: El agente está funcionando incorrectamente.
- Inmediatamente: Desactivar agente en Copilot Studio
- Investigar: Verifique los TRES registros de auditoría:
- Registros principales del servicio del agente
- Registros de auditoría de la cuenta del creador
- Registros de delegación de usuario (para cada usuario que la invocó)
- Contiene: Desactive los conectores y revoque las credenciales del fabricante si es necesario.
- Remediar: Revise los modos de identidad del conector y considere las cuentas de servicio dedicadas.
GCP: El agente se comporta de forma anómala.
- Inmediatamente: Revocar los permisos de la cuenta de servicio
- Investigar: Registro en la nube (nota: visibilidad limitada de la infraestructura)
- Contiene: Si es SA predeterminado, afecta a TODOS los agentes que lo usan, desactive todos
- Remediar: Cambiar a SA personalizado, uno por agente.
Modos de fallo específicos de la identidad
Más allá de los riesgos específicos de la plataforma mencionados anteriormente, existen varios modos de fallo exclusivos de la identidad del agente:
Cadenas de delegación que sobreviven a los usuarios: Un usuario otorga permiso a un agente para actuar en su nombre. El usuario abandona la organización. La delegación puede mantenerse y el agente continúa actuando bajo la autoridad del usuario que se ha marchado.
Agentes de flujo de trabajo que omiten los controles de la interfaz de usuario: Los agentes activados mediante la automatización de flujos de trabajo pueden omitir los procesos de aprobación que ven los humanos. Si la interfaz de usuario aplica comprobaciones de autorización que la API no aplica, los agentes activados por flujos de trabajo operan bajo reglas diferentes.
Herencia de privilegios entre agentes: El agente A tiene acceso al sistema X. El agente A puede invocar al agente B. ¿Tiene ahora el agente B acceso al sistema X? La respuesta depende de la propagación de identidades, que varía según la plataforma y la configuración.
Variación de versión/alias (AWS Bedrock): El tráfico dirigido a una versión anterior del agente mediante un alias puede tener permisos diferentes a los de la versión actual. La seguridad puede deteriorarse silenciosamente.
No se trata de riesgos genéricos de la IA: son deficiencias de gobernanza específicas de cada identidad que requieren controles específicos para cada identidad.
Sección 6
Glosario
Grupo de Acción
(AWS) Configuración que define qué herramientas/acciones puede usar un agente de Bedrock
Autenticación del agente autor
(Azure) Término de Microsoft para referirse al uso de las credenciales del creador del conector.
Función de ejecución del agente
(AWS) El rol de IAM que asume un agente de Bedrock cuando se ejecuta
Radio de la explosión
El alcance de los recursos afectados si se compromete una identidad
Agente principal de servicios
(Azure) El propio agente Entra ID identidad de la aplicación: aparece como un tercer artefacto de identidad
Conector
(Azure) Integración preconfigurada que permite a los agentes interactuar con servicios externos.
Cuenta de servicio al cliente
(GCP) Cuenta de servicio creada por el usuario y específica del agente: recomendada para producción.
Modo de identidad
El contexto bajo el cual se autentica una acción (usuario, creador o agente).
INE
Identidad no humana: cuentas de servicio, claves API e identidades de máquina similares.
Inyección rápida
Ataque que manipula el comportamiento del agente mediante entradas diseñadas.
Agente de servicio del motor de razonamiento
(GCP) Cuenta de servicio administrada por Google para agentes de IA de Vertex, con alcance de proyecto.
Autenticacion de usuario
(Azure) Término que utiliza Microsoft para referirse al uso de los permisos delegados del usuario que realiza la invocación.
Resumen
AWS: Tu cuenta, tu identidad.
El control total implica la responsabilidad total: defina los roles de IAM, aplique el principio de mínimo privilegio y asuma la responsabilidad de sus errores.
Azure: Múltiples identidades, un solo agente.
El modelo de autenticación flexible permite integraciones empresariales, pero fragmenta la responsabilidad. Es importante saber qué modo de autenticación utiliza cada conector.
GCP: Simplicidad gestionada, visibilidad limitada
Evita caer en la trampa de la cuenta de servicio predeterminada. Acepta que no puedes ver el interior de la infraestructura de Google.
El denominador común: los agentes de IA no son cuentas de servicio. Son adaptables, impredecibles y valiosos precisamente porque no siguen guiones preestablecidos. Los controles tradicionales del Sistema Nacional de Salud (NHI, por sus siglas en inglés) partían de la base de un comportamiento predecible. Esa suposición ya no es válida.
Lo que esta guía no resuelve
Esta guía explica cómo funciona la identidad del agente. Sin embargo, no resuelve el problema más complejo: aplicar controles de identidad en tiempo de ejecución, antes de que se produzcan las acciones, no después.
Los proveedores de servicios en la nube priorizan la corrección de la plataforma, no la responsabilidad empresarial. Si esperas a que resuelvan la identidad de los agentes de forma integral, heredarás sus puntos débiles.
El siguiente paso es la aplicación de la normativa en tiempo real: verificación de identidad en el momento preciso, en todas las plataformas, con el contexto necesario para tomar decisiones inteligentes de autorización o denegación. La mayoría de las organizaciones no están diseñadas para esto actualmente.
Ese es el trabajo que tenemos por delante.
Esta guía refleja las capacidades de la plataforma a partir de enero de 2026. Los proveedores de servicios en la nube actualizan sus servicios periódicamente; consulte la documentación vigente para obtener detalles sobre la implementación.