Configure la seguridad de la identidad del agente con la Evaluación Confianza cero

Los agentes de inteligencia artificial adquieren tokens de acceso para los recursos de la organización en cada interacción, incluidos el correo, los archivos, las API de línea de negocio y los agentes de nivel inferior. A diferencia de los usuarios interactivos, los agentes normalmente no presentan las mismas señales de inicio de sesión, como MFA de usuario, estado de dispositivo administrado o contexto de ubicación. Por lo tanto, proteger el plano de control de IA es esencial para su recorrido de Confianza cero.

Los problemas del agente suelen aparecer en tres áreas:

  • Error de coincidencia de directivas y autenticación: las directivas diseñadas para los usuarios pueden omitir patrones de token específicos del agente y modelos de ejecución.
  • Acceso con permisos excesivos: Los agentes suelen acumular permisos amplios en Microsoft Graph y API personalizadas, lo que aumenta el alcance del impacto.
  • Brechas de ciclo de vida y responsabilidad: las identidades de agentes huérfanos, los propietarios o patrocinadores que faltan y las credenciales obsoletas crean un riesgo persistente.

Las recomendaciones y las comprobaciones de Confianza cero que forman parte de este pilar ayudan a reducir el riesgo de acceso no autorizado a la IA. Entre los temas se incluyen exigir la autenticación de Entra en los puntos de conexión de los agentes, aplicar directivas de acceso condicional a las identidades de los agentes, asignar controles de gobernanza del ciclo de vida y garantizar que los roles administrativos de IA tengan principales responsables.

Confianza cero recomendaciones de seguridad para la inteligencia artificial

Requerir Microsoft Entra ID autenticación para interactuar con agentes

Un punto de conexión del agente que no requiere autenticación de usuario de Microsoft Entra es un punto expuesto accesible, aunque no autenticado, dentro del entorno de IA del inquilino. Un atacante podría encontrar este punto de conexión al descubrir URL públicas de agentes, usar enlaces filtrados de Copilot Studio o enumerar los puntos de conexión de proyectos de Foundry. Después, el actor puede interactuar con el agente sin identificarse y usar los permisos ya concedidos al agente para acceder a los datos de contexto, las herramientas conectadas y las API posteriores.

Las llamadas que no llegan a Microsoft Entra no se pueden evaluar mediante directivas de acceso condicional, no tienen ningún riesgo de inicio de sesión para calcular y no pueden vincular registros de auditoría a un usuario específico. La falta de esta información dificulta la investigación y corrección. El comportamiento en tiempo de ejecución que aplica Microsoft Entra autenticación de usuario reside dentro del host de cada agente (Copilot Studio, Microsoft 365 Copilot, Microsoft Foundry, código personalizado o plataformas que no son de Microsoft) y, por lo tanto, no es observable directamente desde el directorio. Lo que se puede observar es el rastro que queda en los registros de inicio de sesión de Microsoft Entra cada vez que un agente y quienes lo llaman pasan a través de Microsoft Entra.

Esta comprobación inspecciona los últimos 30 días de actividad de inicio de sesión para cada identidad del agente y clasifica al agente por la evidencia más fuerte encontrada: un inicio de sesión de agente no interactivo donde el sujeto es un usuario real es la señal positiva más fuerte. Que un usuario inicie sesión de forma interactiva en el diseño del agente también constituye un indicio positivo de que los usuarios acceden al agente a través de Microsoft Entra. La ausencia de alguna de las dos señales durante el período de observación significa que la plataforma no puede confirmar que el agente exige la autenticación de usuarios de Microsoft Entra, y un responsable designado debe verificar directamente la configuración del host del agente.

Acción de corrección

Las directivas de acceso condicional abarcan tanto las identidades de agente como las cuentas de usuario de los agentes.

Cuando una organización implementa agentes de IA, esos agentes adquieren tokens de acceso para acceder a los recursos de la organización en cada interacción, pero sin una sesión interactiva de usuario y dispositivo, ubicación o señales de MFA que usa el acceso condicional clásico para tomar decisiones de confianza para los usuarios humanos. Agente de Microsoft Entra ID presenta dos tipos de identidad distintos:

  • Una identidad de agente: una cuenta de identidad dentro de Microsoft Entra ID que proporciona capacidades únicas de identificación y autenticación para agentes de IA.
  • Cuenta de usuario de un agente: una cuenta opcional que empareja 1:1 con una identidad de agente cuando el agente debe acceder a sistemas que requieren un objeto de usuario.

El acceso condicional trata ambos objetos de identidad del agente como tipos de entidad de seguridad independientes. Por lo tanto, una directiva destinada a identidades de agente no puede tener como destino la cuenta de usuario de un agente y viceversa. Un inquilino que habilita cargas de trabajo de agentes sin al menos una directiva de acceso condicional que imponga un bloqueo salvo aprobación no tiene ningún límite de control sobre el acceso autónomo de la IA. Todas las solicitudes de token de la identidad de un agente o de la cuenta de usuario de un agente están permitidas de forma predeterminada. Los actores de amenazas buscan explotar este tipo de modo de fallo cuando comprometen la identidad de un único agente o la cuenta de usuario del agente subyacente que la respalda, y desplazarse lateralmente a través de los recursos a los que esa identidad puede acceder.

Acción de corrección

El acceso condicional basado en riesgos bloquea las identidades de agente de riesgo

Cuando una organización habilita los agentes de IA en Microsoft Entra, agent identities puede acceder a tokens para acceder a recursos de la organización sin una sesión interactiva de usuario y dispositivo, ubicación o señales de MFA que usa el acceso condicional clásico para tomar decisiones de confianza para los usuarios humanos. Protección de Microsoft Entra ID para los agentes evalúa continuamente el comportamiento de cada agente y emite un nivel de riesgo controlado por señales como:

  • Acceso a recursos desconocido (el agente llega fuera de sus patrones establecidos)
  • Picos de inicios de sesión (reutilización de tokens o abuso de automatización)
  • Sondeo de intentos de acceso fallidos (un atacante que enumera recursos con las credenciales del agente)
  • Inicios de sesión por usuarios de riesgo durante la autenticación delegada (un atacante que aprovecha una cuenta de usuario en peligro)
  • Compromiso confirmado por el administrador (un administrador de seguridad marca manualmente el agente como en peligro)

Sin una directiva de acceso condicional que consume el nivel de riesgo y bloquea la emisión de tokens, la plataforma solo puede registrar que un agente es de alto riesgo mientras continúa mintiendo los tokens que necesita el adversario. Los registros indican "comprometido", mientras que el recurso sigue indicando "sí". Se requiere una directiva de Acceso condicional basada en el riesgo que bloquee las identidades de agente de alto riesgo para cerrar esta brecha entre la detección y la aplicación.

Acción de corrección

Los atributos de seguridad personalizados para las identidades de agente están presentes

Los atributos de seguridad personalizados son el mecanismo principal para que el acceso condicional distinga entre las identidades de agente a escala. Sin ellas, las directivas de acceso condicional solo pueden tener como destino todas las identidades del agente, agentes individuales por identificador de objeto o agentes agrupados por plano técnico. A medida que crece tu flota de agentes, estos mecanismos no son escalables. Los atributos de seguridad personalizados desbloquean la capacidad de filtrar agentes por departamento, estado de aprobación, nivel de confidencialidad o cualquier clasificación definida por la organización. Por ejemplo, un conjunto de atributos denominado AgentAttributes con un AgentApprovalStatus atributo (valores como New, In_Review, HR_Approved, , Finance_Approved) IT_Approvedhabilita las directivas de acceso condicional basadas en atributos que coinciden con los agentes con los recursos en función de su clasificación.

Cuando las identidades de agente carecen de atributos de seguridad personalizados, la organización no puede aplicar directivas de acceso condicional basadas en atributos de forma confiable. Una identidad de agente recién aprovisionada o no clasificada recibe los mismos controles de acceso que una identidad de agente totalmente comprobada porque no hay metadatos para diferenciarlos. Un actor de amenazas que pone en peligro o registra una identidad de agente no autorizado obtiene acceso sin estar sujeto a la aplicación de directivas basada en clasificación. La asignación de atributos de seguridad personalizados cierra esta brecha asegurándose de que cada identidad del agente incluye metadatos de clasificación legibles por máquina que pueden consumir las consultas de acceso condicional y auditoría.

Las directivas que tienen como destino todas las identidades de agente sin filtros de atributo pueden seguir proporcionando protección de línea base, pero no pueden distinguir entre agentes aprobados y no aprobados. La implementación de controles basados en atributos requiere:

  • Definición de una taxonomía de atributo
  • Coordinación con propietarios de aplicaciones
  • Establecimiento de un proceso operativo para etiquetar nuevos agentes a medida que se aprovisionan

Acción de corrección

La gobernanza de identidades para los patrocinadores de identidades del agente está configurada

Agente de Microsoft Entra ID requiere que cada agent identity y agent identity blueprint tenga al menos un patrocinador. Un responsable es un usuario humano o un grupo autorizado que asume la responsabilidad empresarial del ciclo de vida del agente, por ejemplo, decidir cuándo el agente deja de ser necesario, aprobar extensiones cuando caduque el acceso y autorizar su suspensión durante incidentes. Un patrocinador es diferente de un propietario, que designa a los usuarios humanos responsables de las operaciones técnicas y la respuesta a incidentes.

El patrocinio es el punto de entrada para la gobernanza de identidades:

  • Los flujos de trabajo del ciclo de vida pueden dirigir las notificaciones de salida del patrocinador a los responsables
  • Las escalaciones por vencimiento del paquete de acceso se envían al patrocinador
  • Los aprobadores de la gestión de derechos dependen de la relación con el patrocinador para validar la continuidad del acceso.

Sin un patrocinador asignado, las identidades del agente no se pueden regular correctamente. Una identidad de agente que existe sin un patrocinador es invisible para la gobernanza. Sin un paquete de acceso dirigido a las identidades de los agentes, todos los permisos que reciba un agente deben concederse directamente, mediante appRoleAssignment, oauth2PermissionGrant, la pertenencia a grupos o la asignación de roles de directorio, lo cual queda fuera del circuito de control de la administración de derechos. Las concesiones directas no tienen expiración integrada, ningún bucle aprobador ni programaciones de revisión de acceso. Sin un flujo de trabajo del ciclo de vida que contenga tareas de patrocinio de agentes, la relación de patrocinio es un registro estático en el directorio, sin automatización cuando un patrocinador cambia de puesto o abandona la organización. Un actor de amenazas que compromete a un agente sin supervisión —mediante el robo de credenciales, el compromiso del plano o una solicitud malintencionada de paquete de acceso que ninguna canalización de gobernanza existente podía interceptar— actúa contra una identidad cuyos permisos nunca fueron revisados. Esta comprobación también comprueba que al menos una directiva de asignación de paquetes de acceso tiene como destino todas las identidades del agente de directorio.

Acción de corrección

Las identidades de los agentes y las entidades de seguridad de blueprint tienen propietarios técnicos asignados y no quedan agentes deshabilitados en el directorio

Agente de Microsoft Entra ID introdujo dos tipos de identidad: agent identities y agent identity blueprint principals. Estos objetos de identidad derivan de entidades de servicio y, por tanto, tienen los mismos requisitos y procedimientos recomendados en cuanto a titularidad, administración del ciclo de vida y eliminación que cualquier entidad de servicio. Las entidades principales de Blueprint son el punto de aprovisionamiento a partir del cual se crean las identidades de los agentes y pueden contener permisos que se propagan a los agentes hijos. Tener un propietario designado para estos objetos ayuda en dos áreas importantes de administración de identidades del agente:

  • Los riesgos están contenidos e investigados por una parte responsable
  • Los objetos deshabilitados no presentan privilegios inactivos

La relación de propietarios en cada objeto de identidad del agente designa a los usuarios humanos responsables de las operaciones técnicas y la respuesta a incidentes, distintas de la relación de patrocinadores que conlleva responsabilidad empresarial para las decisiones de ciclo de vida y acceso. Por lo tanto, cuando la protección de identificadores marca una identidad de agente como riesgo o surgen patrones anómalos de acceso a recursos, el equipo de operaciones de seguridad puede enrutar a una entidad responsable para la contención y la investigación. Si no hay ningún propietario designado, un actor de amenazas que pone en peligro un agente sin propietario o una entidad de plano técnico (a través del robo de credenciales, la explotación del plano técnico o el consentimiento delegado malintencionado) funciona con una entidad de seguridad sin ningún humano designado para la contención inmediata. Este problema puede extender el tiempo de permanencia desde minutos hasta el siguiente ciclo de auditoría de directorio manual.

Cuando se deshabilita una identidad de agente o una plantilla de identidad de agente, no puede adquirir nuevos tokens, por lo que no puede acceder a recursos. El objeto todavía existe en el directorio, por lo que las asignaciones de roles de aplicación, las pertenencias a grupos y las concesiones de permisos de OAuth2 persisten. Si un error administrativo o un agente malicioso con acceso de escritura en el directorio vuelve a habilitar el objeto, todos los permisos se restablecen sin necesidad de una nueva aprobación. Si un principal de plano deshabilitado se vuelve a habilitar, también restaura la capacidad de aprovisionamiento de todas las identidades de agente secundarias. La combinación de objetos sin propietario y objetos deshabilitados obsoletos crea un patrón de acumulación de privilegios permanentes que la propiedad y la limpieza adecuadas están diseñadas para evitar.

Acción de corrección

Los roles administrativos de IA tienen entidades de seguridad asignadas

El ámbito del plano de control de IA incluye Microsoft 365, Microsoft Power Platform, Microsoft SharePoint y todas las capas del conjunto de soluciones de seguridad de Microsoft. Microsoft Entra ID es el plano de control de identidades de todo este entorno, y sus ámbitos administrativos gestionan las identidades de los agentes, la configuración de administración de Microsoft 365 Copilot, el Acceso condicional para la IA, los entornos de Copilot Studio, las fuentes de fundamentación para la IA, las señales sobre el estado de seguridad de la IA y la detección y respuesta de la IA. Si no hay ningún usuario asignado a un rol administrativo que administre estas funcionalidades de IA, no hay ningún operador responsable para ese segmento de la superficie de IA. Esta brecha podría significar lo siguiente:

  • Las identidades del agente no se supervisan ni revisan
  • Desfase de configuración de administración
  • Las detecciones específicas de la IA no tienen responsable que las investigue o ajuste
  • Las políticas de control de red para la IA no se adaptan a medida que evoluciona el entorno de IA
  • Las escalaciones relacionadas con la inteligencia artificial no tienen ningún respondedor designado

Los agentes maliciosos aprovechan esta brecha al dirigirse directamente al plano de control de IA. Se basan en la brecha entre un rol existente en el directorio y alguien que realmente lo supervisa. Confirmar que cada rol de administrador de IA tiene asignada al menos una entidad es la medida organizativa mínima para la administración de IA. Esta comprobación solo evalúa las asignaciones de roles de directorio de Microsoft Entra. Un rol que aparece como no asignado significa que no hay ninguna identidad de Microsoft Entra asignada al rol de directorio correspondiente, por lo que es posible que sigan existiendo administradores nativos de la carga de trabajo fuera de Microsoft Entra y que queden fuera de esta evaluación. La administración en otras plataformas, como los grupos de roles de Microsoft Purview o los roles personalizados de Microsoft Defender, debe revisarse por separado.

Acción de corrección

  • Last updated on