Microsoft identificó 7 formas en que pueden hackear tus agentes de IA. Una ya está ocurriendo en producción.
En Microsoft Build 2026, el equipo de investigación en seguridad amplió su taxonomía de amenazas para agentes de IA existente con siete nuevas categorías que reflejan lo que los adversarios están haciendo —y lo que los defensores están pasando por alto— en sistemas agenticos implementados. El nombre importa: «los agentes de IA son riesgosos» es solo una postura; siete vectores de ataque específicos y distintos con mitigaciones propias constituyen un marco operativo.
Compromiso de la cadena de suministro agentica. A diferencia de los ataques tradicionales a la cadena de suministro que dependen de código malicioso, este vector opera a través del lenguaje natural. El comportamiento de un agente puede ser influenciado por contenido adversario incrustado en prompts, documentos recuperados o instrucciones de agentes ascendentes —sin necesidad de inyección de código.
Secuestro de objetivos. Un adversario inserta instrucciones que parecen coherentes con la tarea legítima del agente mientras redirige silenciosamente su objetivo final. Es especialmente peligroso en flujos de trabajo agenticos de varios pasos donde el agente toma decisiones de forma autónoma.
Escalada de confianza entre agentes. En arquitecturas de múltiples agentes, un agente comprometido puede afirmar una identidad falsa o permisos inflados ante un agente orquestador. El orquestador, al carecer de verificación criptográfica, acepta la afirmación y otorga accesos indebidos.
Ataque visual a agentes de uso de computadoras. Los agentes que operan mediante interfaces gráficas pueden ser manipulados por contenido adversario mostrado en pantalla —instrucciones ocultas en documentos, páginas web o elementos de la interfaz que redirigen las acciones del agente a través del canal visual.
Contaminación del contexto de sesión. Un adversario introduce datos que sesgan el razonamiento del agente en pasos posteriores sin activar controles de seguridad en ninguna decisión individual. La contaminación se acumula a lo largo de la sesión, produciendo una conclusión comprometida a partir de entradas aparentemente inocuas.
Abuso de MCP/Plugin. La categoría a la que pertenece el incidente de Asana. El Protocolo de Contexto de Modelo (MCP) crea un canal estructurado para que los agentes interactúen con herramientas externas y fuentes de datos. Vulnerabilidades en ese canal —fallos de lógica, permisos mal configurados o herramientas maliciosas— pueden exponer datos a los que el agente no debería acceder, habilitar exfiltración o permitir movimientos laterales entre organizaciones.
Divulgación de capacidades/arquitectura. Un agente que revela detalles internos de implementación —contenido del prompt del sistema, capacidades de herramientas, integraciones disponibles— proporciona la información de reconocimiento necesaria para diseñar ataques más dirigidos contra él.
5 conclusiones clave
1. El abuso de MCP/Plugin ya es un riesgo en producción, no solo teórico.
La brecha en el servidor MCP de Asana en 2025 expuso a aproximadamente 1,000 organizaciones cuando un fallo de lógica cruzó los límites de tenencia —datos de tareas, metadatos de proyectos, comentarios y archivos subidos eran visibles entre organizaciones. Microsoft ahora ha nombrado formalmente esta categoría en su taxonomía actualizada de amenazas para agentes de IA. El Secure MCP Server de Kiteworks la aborda aplicando políticas en la capa de protocolo antes de que los datos lleguen al agente —la capa de gobernanza que el incidente de Asana demostró que es necesaria.
2. La respuesta de Microsoft en Build 2026 ofrece infraestructura de aplicación, no solo orientación de políticas.
El Execution Container, las Especificaciones de Control de Agentes y el conjunto de herramientas ASSERT crean una capa de gobernanza en tiempo de ejecución que los equipos de seguridad pueden implementar frente a escenarios de amenazas concretos. El Execution Container aplica límites explícitos en tiempo de ejecución en lugar de confiar en que los agentes se autolimiten. Las Especificaciones de Control de Agentes son definiciones de políticas portátiles y auditables que pueden versionarse de forma independiente al agente. ASSERT operacionaliza los siete modos de fallo mediante andamiaje de pruebas adversarias. Esto ya es una disciplina de ingeniería —con vectores nombrados y contramedidas publicadas.
3. Los siete modos de fallo ofrecen a los equipos rojos una lista de verificación concreta.
Compromiso de la cadena de suministro agentica, secuestro de objetivos, escalada de confianza entre agentes, ataque visual a agentes de uso de computadoras, contaminación del contexto de sesión, abuso de MCP/Plugin y divulgación de capacidades/arquitectura son ahora superficies de ataque documentadas que requieren cobertura de pruebas específica. Microsoft recomienda inventariar las cadenas de suministro de agentes, verificar la identidad de los agentes criptográficamente en vez de por simple afirmación, y añadir los siete modos a las matrices de cobertura de los equipos rojos.
4. Los controles tradicionales de IAM y DLP no cubren el comportamiento agentico.
Los agentes de IA operan de forma asíncrona, encadenan llamadas a herramientas y actúan en nombre de usuarios de maneras que los controles de perímetro e identidad existentes no fueron diseñados para gobernar. Las herramientas DLP inspeccionan canales conocidos; los agentes invocan APIs externas y procesan contenido de fuentes fuera de esos canales. Se requiere una capa dedicada de gobernanza de contenido de IA —que controle qué contenido sensible pueden recuperar, procesar y transmitir los agentes—.
5. Las industrias reguladas enfrentan una exposición agravada.
Los agentes de IA que acceden a CUI, PHI o datos controlados por ITAR a través de integraciones MCP mal configuradas generan tanto un incidente de seguridad como una violación de cumplimiento. CMMC, HIPAA y GDPR no se detienen porque el actor sea un agente de IA —el acceso debe estar autorizado, registrado y protegido bajo los mismos marcos que rigen el acceso humano a contenido regulado.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Lee ahora
Abuso de MCP/Plugin: de la taxonomía a la brecha en producción
Asana lanzó la integración del servidor MCP con capacidades LLM el 1 de mayo de 2025. Un fallo de lógica en la implementación permitió a usuarios de una organización ver datos de la instancia de Asana de otra organización —información a nivel de tarea, metadatos de proyectos, detalles de equipos, comentarios, discusiones y archivos subidos. La exposición estaba limitada por el alcance de acceso de cada usuario, pero era visibilidad de datos entre tenencias cruzadas desde una integración de IA en la que las organizaciones confiaban plenamente.
Asana descubrió el fallo en junio de 2025, aproximadamente un mes después de que la función MCP se activara. Aproximadamente 1,000 clientes se vieron afectados. La lección no es que MCP sea inherentemente inseguro —el protocolo es solo una capa de comunicación. La lección es que el protocolo requiere una capa de gobernanza encima: políticas explícitas que definan qué puede acceder cada agente, bajo qué condiciones y con qué alcance. Sin esa capa, la integración MCP hereda los permisos que expone el servicio subyacente —lo que en entornos SaaS multi-tenant genera exactamente el tipo de exposición entre organizaciones que experimentó Asana.
Microsoft ahora ha nombrado formalmente esta categoría de fallo y la ha colocado junto a otros seis vectores en una taxonomía que los equipos de seguridad deberían usar para estructurar sus programas de red team de IA. Los fallos de gobernanza de datos de IA en implementaciones MCP no son casos exóticos. Son el resultado previsible de implementar integraciones potentes sin suficiente aplicación de políticas entre tenencias.
Respuesta en tiempo de ejecución de Microsoft: Execution Container, ASSERT y Especificaciones de Control de Agentes
Tres componentes de Build 2026 trabajan juntos como el marco de seguridad para agentes de IA de nivel empresarial más completo publicado por un proveedor importante.
El Microsoft Execution Container aplica límites explícitos en tiempo de ejecución en vez de confiar en que los agentes se autolimiten. La salida del agente, las llamadas a plugins y la invocación de herramientas se tratan como rutas de ejecución no confiables que requieren evaluación de políticas antes de continuar —cambiando el modelo de seguridad de «configura bien el agente y espera» a «aplica límites en la capa de ejecución sin importar el comportamiento del agente».
Especificaciones de Control de Agentes son definiciones de políticas portátiles que describen qué puede hacer un agente, qué herramientas puede invocar y a qué endpoints externos puede acceder. Las especificaciones están separadas de la implementación del agente —auditables, versionables y actualizables sin modificar el propio agente. Esto trata la gobernanza de agentes como un problema de gestión de configuración y no de código embebido.
ASSERT (Adversarial Stress and Security Evaluation for Resilient Thinking) operacionaliza los siete modos de fallo mediante andamiaje de pruebas adversarias que los equipos de seguridad pueden ejecutar contra agentes implementados para identificar vulnerabilidades específicas antes de que lo hagan los adversarios.
Por qué los controles de seguridad tradicionales no son suficientes
Un usuario que inicia sesión en una plataforma SaaS presenta credenciales, pasa MFA y opera dentro de una sesión definida. Los registros de auditoría documentan qué archivos se accedieron. Un agente de IA no hace nada de esto de forma limpia. Opera de manera asíncrona, ejecutando cientos de llamadas a herramientas sin intervención humana en cada paso. Encadena solicitudes, recuperando datos de una fuente para informar una consulta a otra. Actúa en nombre de un usuario cuya sesión puede haber terminado horas antes.
La arquitectura de confianza cero proporciona el marco conceptual correcto —nunca confíes, siempre verifica— pero los mecanismos de verificación diseñados para humanos no se adaptan fácilmente a agentes asíncronos que requieren autorización continua a lo largo de cadenas de herramientas de varios pasos. El Execution Container y las Especificaciones de Control de Agentes de Microsoft abordan la capa de ejecución. La capa de datos —gobernando qué contenido sensible puede recuperar, procesar y transmitir el agente— requiere un marco de gobernanza de contenido diseñado específicamente que vaya más allá del confinamiento en tiempo de ejecución.
El impacto de cumplimiento en industrias reguladas
Los siete modos de fallo nombrados por Microsoft no son solo amenazas de seguridad —también son posibles violaciones de cumplimiento bajo marcos que regulan cómo se maneja cada categoría de contenido sensible.
Para contratistas de defensa bajo CMMC 2.0, un agente de IA que recupera CUI de un sistema de gestión de proyectos y lo transmite mediante una integración MCP a una herramienta externa sin los controles adecuados constituye un evento de cumplimiento CMMC. Lo mismo aplica para HIPAA: la PHI que pasa por el contexto de un agente de IA está sujeta a requisitos de control de acceso y auditoría, sin importar si el actor es humano o IA. GDPR añade minimización de datos: un agente que recupera más datos de los necesarios para la tarea puede violar el requisito de minimización de GDPR simplemente por cómo opera.
Las empresas en sectores regulados no pueden tratar la gobernanza de agentes de IA como un programa separado de sus obligaciones de cumplimiento existentes. Deben extender la misma clasificación de datos, controles de acceso, registros de auditoría y seguridad de transmisión que rigen el acceso humano a contenido regulado para cubrir también el acceso de agentes de IA.
Construyendo una capa de gobernanza de contenido de confianza cero para agentes de IA
El Secure MCP Server de Kiteworks envuelve el acceso de agentes de IA a contenido gobernado por Kiteworks en un punto de aplicación de políticas. En vez de permitir que los agentes extraigan contenido directamente de donde puedan, el Secure MCP Server evalúa cada solicitud frente a políticas de acceso explícitas antes de que los datos lleguen al agente —aplicación en la capa de protocolo, no en la implementación del agente.
La puerta de enlace de datos IA de Kiteworks amplía esto a flujos de trabajo de IA empresariales en general, proporcionando un canal controlado para consultas de IA sobre repositorios de contenido sensible con reglas de acceso sensibles a la clasificación. CUI, PHI y otros contenidos regulados solo son accesibles para agentes de IA explícitamente autorizados para procesarlos. Cada interacción se registra en un log de auditoría inviolable que alimenta directamente el SIEM —la documentación que los evaluadores de CMMC, auditores de HIPAA y autoridades supervisoras de GDPR buscarán al examinar el acceso de IA a contenido sensible.
La Red de Datos Privados de Kiteworks extiende esta gobernanza a correo electrónico, uso compartido de archivos, MFT, SFTP, formularios web y APIs bajo un solo motor de políticas y un log de auditoría consolidado. Microsoft ha nombrado las amenazas y proporcionado las herramientas de aplicación en la capa de ejecución. La pregunta pendiente para cada empresa es si la capa de gobernanza de contenido es lo suficientemente madura para igualar el riesgo.
Para saber más sobre cómo proteger tu contenido sensible de agentes de IA comprometidos, agenda una demo personalizada hoy mismo.
Preguntas frecuentes
La taxonomía de Microsoft añade Compromiso de la cadena de suministro agentica, secuestro de objetivos, escalada de confianza entre agentes, ataque visual a agentes de uso de computadoras, contaminación del contexto de sesión, abuso de MCP/Plugin y divulgación de capacidades/arquitectura. Microsoft recomienda incluir los siete en las matrices de cobertura de equipos rojos, inventariar las cadenas de suministro de agentes y verificar la identidad de los agentes criptográficamente. El Secure MCP Server de Kiteworks aborda específicamente el abuso de MCP/Plugin aplicando políticas en la capa de protocolo antes de que los datos lleguen al agente.
En mayo de 2025, la integración del servidor MCP de Asana permitió a usuarios de una organización ver datos de tareas, metadatos de proyectos y archivos de otras organizaciones —una filtración de datos entre tenencias originada en la propia integración MCP, no por un atacante externo. Alrededor de 1,000 clientes se vieron afectados antes de que el servidor fuera desconectado en junio de 2025. Microsoft ha nombrado formalmente este modo de fallo (abuso de MCP/Plugin) como un vector de ataque prioritario, convirtiéndolo en la evidencia más clara de que la gobernanza de datos de IA para implementaciones MCP es una preocupación operativa, no solo teórica.
El Execution Container aplica límites explícitos sobre el acceso al sistema de archivos, conexiones de red, acceso a credenciales e invocación de herramientas en tiempo de ejecución —sin importar cómo esté configurado o instruido el agente. Las Especificaciones de Control de Agentes proporcionan definiciones de políticas portátiles y auditables que describen el comportamiento permitido, separadas de la implementación del agente. Juntos abordan la capa de ejecución. La gobernanza en la capa de contenido —políticas que controlan qué datos sensibles pueden recuperar y procesar los agentes— requiere controles adicionales como el Secure MCP Server y la puerta de enlace de datos IA.
Los requisitos de controles de acceso de CMMC nivel 2, registros de auditoría y seguridad de transmisión para CUI no hacen excepciones para agentes de IA. Un agente que recupera CUI a través de una integración MCP y lo transmite a una herramienta externa debe estar autorizado, registrado y protegido bajo los controles NIST 800-171 aplicables. Lo mismo aplica para HIPAA: la PHI procesada por un agente de IA sigue siendo PHI y el acceso debe estar documentado. Las organizaciones deben ampliar sus programas de gobernanza de contenido existentes para cubrir explícitamente el acceso de agentes de IA.
El Secure MCP Server aplica políticas de acceso en la capa de protocolo antes de que los datos lleguen al agente solicitante. La puerta de enlace de datos IA proporciona un canal controlado para consultas de IA sobre repositorios de contenido sensible con aplicación consciente de la clasificación. Los logs de auditoría inviolables capturan cada interacción del agente con contenido regulado para requisitos de auditoría de CMMC, HIPAA y GDPR —haciendo que la protección de datos de confianza cero para flujos de trabajo de IA sea una realidad operativa y no solo aspiracional.
Recursos adicionales
- Artículo del Blog
Estrategias de confianza cero para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones están fallando en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juegan a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.