Semion Vasilevitzky y Jonathan Elkabas

Nota del editor: Bienvenido al capítulo 6 de «Comprender y prevenir los ataques a la identidad de los agentes de Entra ID: una guía completa». Esta guía técnica, dividida en varias partes, te ayuda a comprender el enfoque de Microsoft respecto a las identidades de los agentes y cómo puedes protegerlas frente a los autores de amenazas. Para repasar los capítulos anteriores y las lecciones prácticas, empieza aquí.

La plataforma Agent ID introduce nuevos tipos de identidad y patrones operativos, y dado que esta funcionalidad apenas está empezando a desarrollarse, las configuraciones erróneas y las vías de ataque en el mundo real apenas están empezando a salir a la luz. En esta sección, no pretenderemos abarcar todos los riesgos o vulnerabilidades posibles. En su lugar, destacaremos un pequeño conjunto de configuraciones erróneas sencillas pero importantes que probablemente se volverán habituales a medida que las organizaciones empiecen a adoptar Agent ID a gran escala.


¿Quién es el titular de este agente? Identificadores de agente sin titular ni patrocinador

Las identidades de agentes no gestionadas (aquellas que carecen de propietario y patrocinador) generan una brecha en la gobernanza de identidades. Cuando no se ha asignado ninguna persona o equipo responsable, es más probable que estas identidades de cargas de trabajo pasen desapercibidas durante las auditorías y no se detecten durante la respuesta a incidentes.

En la página de resumen de Entra Agent ID, podemos ver el número de identidades de agentes no gestionadas.

Figura 1. Visualización de las identidades de los agentes no gestionados en la vista general de Microsoft Agent ID

Aunque al crear la identidad de un agente es obligatorio especificar al menos un patrocinador, es posible que, con el tiempo, algunas identidades queden sin gestionar. Por ejemplo, esta situación podría darse si se eliminara a un usuario que había actuado como patrocinador, por ejemplo, tras abandonar la organización.

Otra situación similar, aunque que no aparece en la página de resumen, se da cuando se desactiva la cuenta del patrocinador o del propietario. En estos casos, la identidad del agente parece tener un propietario o patrocinador asignado, pero la cuenta asignada ya no está activa en la organización. Esto hace que la identidad quede, en la práctica, «huérfana» y que los administradores puedan pasarla por alto fácilmente.

Lo ideal es que las identidades de los agentes cuenten siempre con una persona real que se haga cargo de ellas y sea consciente de su finalidad. Garantizar una responsabilidad continua es una parte esencial de la gestión de identidades.

En Semperis Lightning Intelligence y Directory Services Protector DSP)—dos soluciones que forman parte de la Identity Resilience Platform—ya señalamos esas dos situaciones. En un panel de control claro, se puede ver no solo el número de identidades de agentes no gestionadas, sino también la lista exacta.

Figura 2. Visualización de las identidades de los agentes no gestionados en la plataforma Semperis

También puedes ver las identidades de agentes huérfanos de las que se ha hablado y qué patrocinadores o propietarios concretos están desactivados, lo que hace que, en la práctica, esas identidades de agentes queden huérfanas.

Figura 3. Identificación de los patrocinadores y propietarios de los agentes desactivados

¿Quién conoce mi secreto? Planes que utilizan secretos de los clientes

Como ya se ha descrito anteriormente en el punto de verificación práctico 1 de esta guía, un secreto de cliente es uno de los tipos de credenciales que se pueden asignar a un modelo de identidad de agente. Este tipo de credencial se considera débil porque a menudo se almacena en archivos de configuración, scripts, pipelines de CI/CD o repositorios de código fuente, donde puede revelarse de forma involuntaria. Si un atacante obtiene un secreto de cliente, puede autenticarse como ese modelo de identidad de agente o como las identidades de agente asociadas a él sin necesidad de un inicio de sesión interactivo ni de autenticación multifactorial (MFA).

Microsoft advierte expresamente que:

Los secretos de cliente no deben utilizarse como credenciales de cliente en entornos de producción para los plantillas de identidad de agentes debido a los riesgos de seguridad que ello conlleva.

En su lugar, Microsoft recomienda utilizar credenciales de identidad federada (FIC) con identidades gestionadas o certificados para la autenticación.

Los indicadores de Semperis te permiten realizar un seguimiento de todos los plantillas de identidad de los agentes que contienen datos confidenciales en un único lugar centralizado y ver exactamente cuáles son las credenciales mal configuradas de cada plantilla.

Figura 4. Visibilidad de las credenciales mal configuradas del modelo de identidad del agente

Demasiado poder: identidades de agentes con grandes privilegios

Hasta ahora, hemos hablado de cómo los agentes obtienen permisos exclusivos de la aplicación o delegados, y de cómo se lleva a cabo la asignación de roles en este modelo. Aunque Microsoft limita los permisos y roles que se pueden asignar a las identidades de los agentes, sigue siendo fundamental aplicar el principio del privilegio mínimo.

Los permisos con privilegios elevados en una identidad de agente aumentan el riesgo incluso cuando no hay ningún atacante presente. Las identidades de agente pueden ejecutarse automáticamente y realizar acciones a gran escala. Si un agente está mal configurado, se comporta de forma inesperada o se integra incorrectamente en un flujo de trabajo, los privilegios elevados pueden convertir un simple error en un incidente que afecte a todo el inquilino. Desde el punto de vista de la seguridad, las identidades de agente con privilegios excesivos aumentan la superficie de ataque y se convertirían en un objetivo para los atacantes.

Los administradores de la organización deben revisar periódicamente los permisos asignados a las identidades de los agentes y reducirlos al mínimo necesario para que el agente pueda funcionar.

Los indicadores de Semperis te muestran, en un solo lugar, las identidades de los agentes con privilegios elevados y sus funciones concretas con privilegios excesivos.

Figura 5. Identificación de roles con privilegios excesivos

Conclusiones

Las identidades de agente no son simplemente otra casilla de selección más en el centro de administración de Microsoft Entra. Son el intento de Microsoft de dotar a los agentes de IA de una identidad formal dentro del directorio. No se trata de un objeto de automatización difuso. Tampoco es simplemente una entidad de servicio con un nuevo nombre. Se trata de un nuevo modelo de identidad que pretende representar a los agentes como algo que la plataforma pueda reconocer, gestionar, autorizar y auditar.

Y eso es importante porque, en el momento en que un agente necesita cruzar el límite de un sistema, llamar a una API, leer datos de la organización, actualizar un estado, enviar un mensaje, acceder a un buzón o actuar en nombre de algo más grande que él mismo, deja de ser solo «lógica de IA». Se convierte en un participante del sistema de identidades. Necesita un sujeto. Necesita permisos. Necesita un token. Necesita un lugar en el directorio.

Agent ID es la respuesta de Microsoft a esa necesidad.

En el centro de este modelo se encuentra el «Agent Identity Blueprint», la plantilla a partir de la cual se crean las identidades de los agentes y a través de la cual pueden transmitirse los permisos heredados. A su alrededor, Microsoft ha introducido varios objetos relacionados: identidades de agente, usuarios de agente, entidades principales del modelo y agentes heredados respaldados por entidades de servicio. Juntos, forman una nueva capa operativa para los agentes de IA dentro de Entra ID.

Pero, como hemos visto a lo largo de esta guía, el ID de agente no surge de la nada. Se basa en los elementos básicos existentes de Entra ID, y esos elementos ya vienen acompañados de una estructura, unos permisos, una serie de supuestos y un bagaje histórico.

Las identidades de los agentes se heredan de los sujetos de servicio. Los usuarios de los agentes se heredan de los usuarios. Los «blueprints» se heredan de las aplicaciones. Los permisos se gestionan a través de los mecanismos habituales de OAuth y de asignación de roles de aplicación. La aplicación de los roles sigue dependiendo de las acciones RBAC, las comprobaciones de la API y el comportamiento en tiempo de ejecución. Los nombres son nuevos, pero el plano de control subyacente resulta muy familiar.

Y, para ser sinceros, ahí radica tanto el punto fuerte (operativo) como el riesgo (de seguridad) del modelo.

Esto significa que Agent ID puede integrarse de forma natural en Entra ID, Microsoft Graph, los registros de auditoría, los permisos de las aplicaciones y los flujos de administración existentes. Pero también significa que cada capacidad heredada, cada suposición oculta y cada antiguo problema de ámbito vuelven a cobrar relevancia en un nuevo contexto.

Las identidades de agente introducen una nueva superficie de ataque, y cabe esperar que surjan nuevas vías de ataque a medida que las organizaciones empiecen a adoptarlas. Es probable que algunas se deban a plantillas con permisos excesivos. Otras, de límites de roles poco claros. Otras, de permisos heredados que los responsables de la seguridad aún no han identificado correctamente. Otras, de usuarios de agentes que interactúan con interfaces diseñadas originalmente para usuarios humanos. Otras, del acceso condicional y del comportamiento de los tokens, que aún requieren pruebas prácticas más exhaustivas. Y otras, como siempre, de esos lugares aburridos que nadie miró porque el portal y la documentación los hacían parecer inofensivos.

Lo importante es no considerar a los agentes como algo mágico o ajeno a lo que ya conocemos, porque son identidades.

Y las identidades se autentican, obtienen autorización, realizan acciones y dejan rastros. El mismo ciclo AAA de siempre lleva ahora una máscara con forma de IA.

Así que, si hay una conclusión práctica que se puede extraer de este análisis, es esta.

No te limites a la etiqueta del portal ni a la tabla de documentación. Sigue el modelo de objetos. Sigue la herencia. Sigue el token. Sigue los permisos. Sigue las acciones de los roles. Sigue los registros de auditoría y de inicio de sesión. El comportamiento real de la plataforma suele revelarse en algún punto entre lo que describe el esquema, lo que promete la documentación y lo que realmente permite el entorno de ejecución.

A medida que Agent ID siga evolucionando, las cuestiones más espinosas no serán solo de carácter técnico. Serán cuestiones de confianza: hasta qué punto estamos dispuestos a conceder acceso a estas identidades, con qué claridad podemos ver lo que hacen y en qué medida la plataforma es capaz de establecer límites en torno a ellas una vez que empiecen a funcionar a gran escala.

Porque los agentes no son simplemente código que se ejecuta silenciosamente en segundo plano. Son código dotado de capacidad de acción, envuelto en una identidad, que cuenta con permisos, toma decisiones y traspasa límites en nombre de alguien o algo más.

Y una vez que el código tiene capacidad de acción, identidad y confianza, se convierte en algo más que «automatización».

Se convierte en una voluntad delegada dentro del sistema, que refleja nuestros permisos, nuestras suposiciones y, en última instancia, nuestras consecuencias.


No te lo imagines: escanea. ¿Cómo puede ayudarte Semperis?

Las herramientas de Semperis ya permiten identificar deficiencias en la gobernanza, señalar posibles puntos de exposición y ayudar a detectar ese tipo de errores de configuración y riesgos. Este ámbito sigue evolucionando y, en Semperis, ya estamos trabajando en indicadores adicionales de exposición y en capacidades de detección más exhaustivas que se irán introduciendo progresivamente.

A medida que amplíes el uso de identidades de agente en tus sistemas de identidad, sin duda te surgirán nuevas dudas en cada paso. No dudes en ponerte en contacto con nosotros en cualquier momento; estamos aquí para ayudarte.


Para saber más


Explora la guía