Microsoft ha presentado un marco de seguridad que trata a los agentes de IA como un tipo de riesgo interno (insider). Según la compañía, las organizaciones deben controlar sus identidades, permisos y comportamiento en tiempo de ejecución de forma independiente de los propios modelos.
La guía de seguridad de Microsoft publicada el 19 de octubre de 2026 no es un informe de incidente ni de vulnerabilidad. Aborda el riesgo operativo que surge cuando los agentes reciben acceso a datos, herramientas e infraestructura corporativos y pueden actuar a velocidad de máquina.
Microsoft no describe a los agentes como hostiles por naturaleza. Su preocupación es que la salida de un modelo puede variar, que el contexto de una tarea puede cambiar y que un contenido externo puede manipular a un agente que, por lo demás, es legítimo. Por tanto, un sistema que empieza una tarea correctamente puede desviarse más adelante por un error, un compromiso o una inyección de prompts.
La empresa llama a esto «agentic insider»: un software que actúa con autoridad organizativa delegada, pero sin un comportamiento totalmente determinista.
Los controles deben permanecer fuera del modelo
El principio central de Microsoft es «rodear la inteligencia no determinista con controles deterministas, evidencia independiente y límites de contención».
Con este modelo, un agente no debería decidir los límites de su propia autoridad. Los mecanismos de identidad, acceso y aplicación de políticas deben funcionar fuera del modelo, fuera de su capacidad para eludirlos o modificarlos.
Satya Nadella, presidente y consejero delegado de Microsoft, resumió el enfoque al afirmar que la arquitectura de agentes más confiable es la que está diseñada para «confiar lo menos posible en el modelo». La distinción práctica está entre confiar en que un modelo se comporte correctamente y construir un sistema que limite el daño cuando no lo hace.
Microsoft organiza el marco en cuatro responsabilidades continuas:
- Conocer: mantener un inventario de agentes, sus propietarios, su finalidad prevista y su actividad observada.
- Contener: restringir datos, sistemas y acciones antes de que un agente empiece a operar.
- Proteger: asegurar cada componente del recorrido del agente, incluidas las herramientas, los entornos de ejecución y los recursos corporativos.
- Adaptar: revisar las protecciones cuando cambien el comportamiento, el contexto o el riesgo evaluado.
No se presentan como fases de implementación secuenciales. Microsoft describe un bucle de retroalimentación en el que las nuevas evidencias modifican el riesgo, el riesgo modifica la política y la política modifica lo que puede hacer un agente.
Cuando el riesgo aumenta, el marco puede mantener el acceso de lectura y bloquear la escritura, reducir los recursos disponibles para el agente, exigir la aprobación humana verificada de acciones de consecuencias importantes, o aislar y detener al agente.
Cada agente recibe una identidad separada
Una consecuencia inmediata para los equipos de seguridad es que un agente no debería operar simplemente como una extensión de la cuenta de un empleado.
Microsoft afirma que cada agente necesita su propia identidad de primera clase, distinta de la persona que lo patrocina. Esto permite que los sistemas de auditoría y acceso distingan las acciones directas de un empleado de las operaciones que realiza un agente en nombre de ese empleado.
La compañía indica que añade soporte de descubrimiento para 35 tipos adicionales de agentes locales, con lo que el total compatible asciende a 60. Entre los ejemplos figuran Claude Code, OpenAI Codex y GitHub Copilot. El descubrimiento pretende cubrir agentes creados por Microsoft, plataformas y SDK de socios, así como agentes introducidos localmente.
Microsoft también afirma que está ampliando Microsoft Entra Agent ID con tipos de identidad para patrones de agentes adicionales, entre ellos los agentes locales y los agentes desconocidos previamente detectados por los sensores de seguridad. Según la empresa, Project Perception y Microsoft Agent 365 comparten señales y utilizan un registro unificado.
Para los administradores, el modelo propuesto convierte el descubrimiento de agentes en un problema de gestión de activos: una organización no puede aplicar controles de acceso eficaces si no puede identificar qué agentes existen, quién es responsable de ellos y qué están haciendo.
Sandboxing y acceso mediado a herramientas
Microsoft recomienda ejecutar los modelos y los arneses que los rodean en entornos controlados, en lugar de permitirles heredar todos los privilegios de un dispositivo.
Cita Microsoft Execution Container (MXC) como ejemplo de sandbox diseñado para aplicar un acceso a recursos controlado por políticas. El límite de aplicación pretende situarse fuera del agente, en lugar de depender de instrucciones dentro del modelo.
El marco también rechaza el descubrimiento de herramientas sin restricciones. Un agente no debería poder invocar automáticamente cada API, servidor MCP, recurso de red, herramienta local u otro agente que encuentre. Los controles locales, de red y de datos deberían mediar en esas conexiones.
La inspección del contenido es otra parte del diseño. Los sistemas de seguridad deberían evaluar la sensibilidad y el origen de la información que entra o sale de un agente, incluido si material no confiable podría estar influyendo en sus decisiones.
Microsoft ilustra el riesgo con un agente de aprobación de gastos. Ese agente puede necesitar legítimamente leer las reclamaciones, compararlas con la política y autorizar reembolsos rutinarios. No necesita todos los permisos que tiene quien lo patrocina. Si un documento externo contiene una inyección de prompts, es posible que la configuración del agente siga sin cambios, aunque su comportamiento, y por tanto su riesgo, se haya desplazado.
Permisos que caducan con la tarea
Microsoft presenta Dynamic Permissions como una forma de que un agente no tenga acceso permanente por defecto. El agente recibiría solo la autoridad necesaria para una tarea aprobada y únicamente durante la duración de esa tarea.
Una política de toda la organización definiría el límite máximo. En particular, un agente no podría obtener autoridad que no esté disponible para el usuario que lo patrocina. Los permisos podrían limitarse a una tarea, caducar tras un periodo determinado o reducirse a medida que avanza la tarea. Las operaciones de mayor impacto podrían exigir la aprobación humana verificada.
El empleado conservaría su propio acceso, mientras que el agente tendría una identidad separada y sus propios permisos específicos para la tarea. Esta separación está pensada para que la atribución de acciones y la revocación sean más precisas que si un agente reutilizara las credenciales y los privilegios de una persona.
Microsoft también describe Dynamic Agent Risk como una puntuación actualizada de forma continua, construida a partir de señales de identidad, endpoint, datos, nube, red, tiempo de ejecución y actividad del agente. La evaluación tiene en cuenta la configuración de seguridad del agente, los recursos a los que puede acceder, el impacto probable de un fallo y las señales de que sus acciones se apartan de la intención del usuario o de la organización.
Un diagrama que acompaña al anuncio muestra que Microsoft Sentinel, Entra, Intune, Purview, Global Secure Access y Defender aportan señales para el análisis de contexto y la puntuación de riesgo en tiempo real. Microsoft vincula esa evaluación con Dynamic Conditional Access, según el cual la política puede cambiar lo que un agente puede leer, modificar, invocar o aprobar en un momento determinado.
Estas son descripciones de Microsoft sobre sus capacidades y su arquitectura prevista, no pruebas de una implementación demostrada de forma independiente.
La automatización también supervisará a los agentes
Microsoft sostiene que la revisión manual no escalará cuando las organizaciones desplieguen «miles o cientos de miles» de agentes. Su propuesta incluye los Guardian Agents: sistemas de IA que ayudan a supervisar otros agentes y que siguen sujetos a límites definidos por personas.
Un informe de Security Affairs publicado el 20 de octubre de 2026 indica que los Guardian Agents pueden seguir playbooks creados por los operadores, investigar cambios de riesgo, recomendar o aplicar respuestas y utilizar los resultados para refinar la política. Las personas seguirían fijando los objetivos y aprobando las decisiones importantes.
Este enfoque deja un reto central de diseño: la aplicación de controles no puede depender únicamente de otro modelo cuyo comportamiento también puede variar. La respuesta que Microsoft declara es mantener los controles decisivos fuera de los modelos, donde los agentes no puedan alterarlos.
Para las organizaciones que adoptan agentes ahora mismo, el marco se traduce en prioridades concretas: descubrir los agentes locales y los desplegados de forma centralizada, asignar a cada uno una identidad separada, eliminar los privilegios heredados del usuario, limitar su entorno de ejecución y sus rutas de herramientas, inspeccionar las entradas no confiables y exigir aprobación humana o aislamiento cuando un cambio de riesgo haga que una acción sea insegura.
