Los agentes de IA son la nueva superficie de ataque
Investigadores de seguridad acaban de demostrar que tu asistente de codificación con IA puede convertirse en una herramienta de exfiltración, y tus controles de detección actuales no lo van a detectar. No es una preocupación teórica. Es una técnica documentada y reproducible, publicada por el equipo 0Din de Mozilla en una prueba de concepto detallada el 29 de junio de 2026.
Esa revelación se produjo en la misma semana que una CVE de alta gravedad en Amazon Q Developer, un análisis formal de la nueva especificación empresarial MCP, una campaña documentada de ingeniería social dirigida a equipos de ciberseguridad mediante espacios de trabajo de IA falsos, y un análisis que sostiene que la gobernanza de identidades tradicional es estructuralmente incapaz de contener agentes de IA. Cinco líneas de investigación distintas, publicadas en un lapso de cuatro días, que apuntan a la misma falla estructural: los agentes de IA que operan sin una capa de contenido gobernada se convierten en vías de exfiltración.
El problema no es incremental. Las empresas llevan dos décadas construyendo controles de seguridad alrededor de un modelo relativamente estable de lo que es una identidad y cómo se comporta. Un agente no encaja en ese modelo. Se autentica una vez, hereda permisos de la identidad humana para la que opera, y luego recorre múltiples sistemas empresariales en una sola sesión, accediendo a recursos que ningún humano autorizó explícitamente, dejando registros fragmentados que ninguna herramienta de seguridad existente ensambla en una imagen coherente. La investigación de esta semana concreta ese problema estructural y, en un caso, lo acota en el tiempo: la fecha de publicación del 28 de julio para MCP 2026-07-28 crea una ventana definida para que las organizaciones solucionen una brecha de gobernanza antes de que la nueva superficie de ataque del protocolo entre en vigor.
El intercambio seguro de datos de Kiteworks está diseñado precisamente para este problema. Cuando los agentes de IA acceden a contenido empresarial a través de la capa de API gobernada de Kiteworks, cada interacción está sujeta a políticas, cada acceso a datos queda registrado, y ningún agente —legítimo o comprometido— puede acceder a contenido fuera de su alcance autorizado explícitamente. Lo que la investigación de esta semana describe colectivamente es un entorno donde esa capa de gobernanza no existe. En todos los vectores de ataque documentados, el resultado es el mismo: datos sensibles de la empresa llegan a partes no autorizadas a través de un sistema de IA sin un límite de acceso aplicado.
Aspectos clave
1. Los agentes de codificación con IA pueden convertirse en herramientas de exfiltración mediante inyección indirecta de prompts.
El equipo 0Din de Mozilla demostró que Claude Code puede ser secuestrado mediante un registro DNS TXT manipulado vinculado a un repositorio de GitHub aparentemente normal, generando una reverse shell que exfiltra silenciosamente claves API, tokens y secretos de entorno sin activar ninguna de las capas de seguridad integradas del agente.
2. Amazon Q Developer tenía una vulnerabilidad grave que entregaba credenciales de la nube a los atacantes.
CVE-2026-12957 (CVSS 8.5), revelada por Wiz, permitía que archivos de configuración MCP maliciosos incrustados en un repositorio de código se ejecutaran automáticamente al abrirlo un desarrollador, otorgando a servidores controlados por atacantes acceso a credenciales de la nube, archivos locales y ejecución de shell sin ningún aviso visible ni interacción del usuario.
3. La nueva especificación MCP 2026-07-28 traslada toda la responsabilidad de seguridad a los desarrolladores.
El cambio del protocolo hacia un diseño sin estado delega los controles de acceso entre tenants, la gestión de secretos y las comprobaciones de escalamiento de privilegios completamente a los implementadores individuales, sin aplicación en la capa de protocolo. La especificación se publica el 28 de julio, iniciando una ventana de 12 meses para la depreciación de la versión anterior.
4. Los atacantes están creando espacios de trabajo de IA falsos muy convincentes para recolectar datos empresariales.
Push Security documentó la campaña «Poisoned Tenant», en la que actores de amenazas crean organizaciones fraudulentas de OpenAI dirigidas a empleados de ciberseguridad por nombre, enviando invitaciones desde la dirección legítima de notificaciones de OpenAI que superan todas las verificaciones de autenticación de correo electrónico.
5. La gobernanza de identidades tradicional no fue diseñada para agentes que operan a velocidad de máquina.
El análisis del modelo emergente de «agente guardián» demuestra que la infraestructura IAM construida en torno a eventos de autenticación humana no puede contener agentes autónomos que heredan credenciales sobreprivilegiadas, recorren múltiples sistemas empresariales en una sola sesión y no dejan un rastro de auditoría coherente.
Confías en que tu organización está segura. Pero ¿puedes verificarlo?
Lee ahora
El ataque a Claude Code: tres pasos de indirección, una reverse shell
El ataque 0Din de Mozilla funciona porque distribuye sus componentes en tres sistemas que nunca se examinan juntos. El repositorio no contiene instrucciones ni código malicioso. Cuando un desarrollador lo clona, Claude Code sigue los pasos de instalación legítimos. El ataque se activa durante la configuración inicial, cuando se le indica a Claude Code que use un paquete de Python que lanza un error si se llama antes de inicializarse.
El mensaje de error dice: «Run: python3 -m axiom init.» Claude Code lee el error y ejecuta el comando de recuperación. Al ejecutar init, se llama a un script de shell que extrae un valor de configuración de un registro DNS TXT y lo ejecuta como comando. Ese valor está codificado en base64, por lo que nunca aparece una firma de reverse shell en texto claro ni en disco ni en tránsito. El shell interactivo se inicia en la máquina del desarrollador. El atacante obtiene acceso a todas las credenciales, claves API, tokens y secretos de entorno cargados allí, y puede instalar una puerta trasera para acceso persistente después de cerrar el shell.
Como explican los investigadores de Mozilla: «La reverse shell está a tres pasos de indirección de cualquier cosa que Claude Code realmente evaluó: un mensaje de error en el que confió, un script que obtuvo un valor y un registro DNS que nunca vio.» El análisis estático ve una consulta DNS. El monitoreo de red ve la resolución de nombres. El agente ve un paso de configuración preautorizado. Ninguno de los tres parece malicioso por sí solo. El atacante puede actualizar la carga útil en cualquier momento cambiando el registro DNS TXT, sin necesidad de modificar el repositorio, y cualquier desarrollador que abra el repositorio con Claude Code queda expuesto.
Esto elude las tres capas de seguridad integradas de Claude Code. No es una crítica específica a Claude Code; es una característica estructural de cualquier agente de codificación con IA que trate los mensajes de error como instrucciones legítimas. El mecanismo de entrega de la carga útil —los registros DNS TXT— está completamente fuera del modelo de amenazas del agente. Cualquier desarrollador que use un agente de codificación con IA para configurar un repositorio desconocido opera con una superficie de ataque significativamente ampliada, una que ningún control de endpoint o red existente cubre de forma fiable. Una protección de datos de IA sólida requiere modelar cómo los agentes interactúan con los datos del entorno, no solo con el contenido que se les pide procesar explícitamente.
Amazon Q y el problema de la autoejecución
La vulnerabilidad de Amazon Q Developer revelada por Wiz el 26 de junio de 2026 (CVE-2026-12957, CVSS 8.5) describe la misma falla estructural desde otro ángulo. La causa raíz: la extensión actuaba automáticamente sobre archivos de configuración MCP incrustados en un espacio de trabajo sin pedir permiso al usuario. Un desarrollador abría un repositorio. El repositorio contenía un archivo de configuración MCP malicioso. La extensión lo ejecutaba en silencio, otorgando a un servidor MCP controlado por el atacante acceso a archivos locales, credenciales de la nube y ejecución de shell, sin aviso, sin advertencia, sin ninguna indicación visible de que algo inusual hubiera ocurrido.
AWS fue notificado el 20 de abril, lanzó un parche el 12 de mayo y publicó un aviso esta semana. Hay soluciones disponibles para VS Code, JetBrains, Eclipse, Visual Studio y el servidor de lenguaje de Amazon Q. Wiz señala que el patrón subyacente de autoejecución no es exclusivo de Amazon Q; se han identificado comportamientos similares en otras herramientas de codificación con IA, incluyendo Claude y Cursor. Los vectores de ataque específicos que identifica Wiz: pruebas de codificación falsas (una técnica asociada a actores de amenazas norcoreanos que apuntan a desarrolladores), paquetes open source con nombres similares y pull requests maliciosos a proyectos open source populares.
El desarrollador no tiene que cometer un error. Solo tiene que hacer lo que haría normalmente con cualquier repositorio. Cuando un archivo de configuración se ejecuta automáticamente porque un agente lo abrió, no hay evaluación de políticas en la capa de contenido, solo ejecución. El concepto de motor de políticas de datos —evaluar el contenido según la política antes de que un agente actúe sobre él— es precisamente lo que explota la ausencia de este ataque. «La combinación de autoejecución, generación de shell y herencia de entorno creó una vulnerabilidad grave en una herramienta de desarrollo ampliamente utilizada», escribió Wiz. «Un solo repositorio malicioso podría comprometer no solo la máquina local del desarrollador, sino también su infraestructura en la nube».
La brecha de la especificación MCP 2026-07-28
El 28 de julio de 2026, se publicará oficialmente MCP 2026-07-28, iniciando una ventana de 12 meses para la depreciación de la versión actual. El cambio principal es que MCP ahora es sin estado en la capa de protocolo. Ese cambio permite implementaciones empresariales a escala y nativas de la nube. También significa algo específico para los equipos de seguridad: las garantías de seguridad en la capa de sesión que proporciona el protocolo actual desaparecen en la nueva versión.
El análisis de Akamai sobre el candidato a lanzamiento identifica varias nuevas superficies de ataque introducidas por el diseño sin estado. El secuestro de flujos de trabajo y el acceso entre tenants se vuelven viables si los identificadores de seguimiento son predecibles. Los nuevos encabezados HTTP específicos de MCP (MCP-Method y MCP-Name) crean vectores de fuga de datos: si los desarrolladores asignan por error datos sensibles como claves API, tokens o información personal identificable a esos encabezados, esos secretos se vuelven visibles para cada balanceador de carga, proxy y sistema de registro a lo largo del camino de la solicitud. Las aplicaciones MCP como extensión de protocolo de primera clase introducen riesgos de XSS almacenado. Las tareas asíncronas de larga duración crean un vector de denegación de servicio donde la creación de tareas es barata para el atacante pero costosa en recursos para el servidor.
La conclusión de Akamai es directa: «Los cambios no son simplemente mejoras incrementales. Redefinen fundamentalmente dónde residen las responsabilidades de seguridad». Las decisiones que el protocolo actual aplica en la capa de sesión, en la nueva versión se delegan completamente a los desarrolladores individuales y a los operadores de la plataforma. Maxim Zavodchik, director sénior de investigación de amenazas en Akamai, dijo a SecurityWeek: «Como el protocolo está pasando a un modelo sin estado e introduce aplicaciones de interfaz ricas y tareas asíncronas, los límites críticos de seguridad ahora dependen totalmente de cómo los desarrolladores los implementen».
Para las organizaciones que ejecutan agentes de IA sobre contenido empresarial, esta es la brecha de gobernanza más relevante en este momento. El nuevo protocolo no va a aplicar gobernanza de datos, clasificación de datos ni controles de acceso. No registrará qué contenido recuperó un agente. Cada una de esas propiedades de seguridad debe implementarse en la capa de aplicación, por el desarrollador o el operador de la plataforma. La fecha límite del 28 de julio es un punto de inflexión con un plazo definido: las organizaciones tienen una ventana limitada para implementar una capa de contenido gobernada antes de que la nueva superficie de ataque del protocolo entre en funcionamiento. El Secure MCP Server de Kiteworks proporciona esa capa de gobernanza en el punto de integración de IA: la aplicación de políticas que MCP 2026-07-28 deliberadamente no incluye en el protocolo.
Poisoned Tenant: ingeniería social en la era de la IA
La campaña «Poisoned Tenant» documentada por Push Security adopta un enfoque diferente para el mismo objetivo. En lugar de comprometer un agente de IA mediante una explotación técnica, crea un espacio de trabajo de IA falso —una organización fraudulenta de OpenAI que suplanta a una empresa legítima— e invita a empleados objetivo a unirse. Los correos de invitación provienen de noreply@tm.openai.com, la dirección real de notificaciones de OpenAI. Superan todas las verificaciones de autenticación de correo electrónico. Desde el punto de vista técnico, son invitaciones genuinas de OpenAI. El único elemento fraudulento es la organización a la que se invita al usuario.
Push Security descubrió la campaña después de que varios empleados recibieran invitaciones para unirse a una organización de OpenAI llamada «Push Security Inc.», creada por un atacante usando cuentas de Gmail, no por Push Security. Tras aceptar una invitación para estudiar el ataque, Luke Jennings, VP de Investigación y Desarrollo en Push Security, se encontró añadido a la organización fraudulenta, que contenía una sola cuenta controlada por el atacante que se hacía pasar por el CEO de la empresa. A los empleados invitados se les asignaron privilegios de propietario. Se adjuntó una tarjeta de crédito Visa a la cuenta de facturación para dar legitimidad. El proyecto no contenía chats previos, solo infraestructura para recolectar cualquier contenido sensible que los empleados enviaran.
El análisis de Push Security sobre el objetivo de la campaña es claro: «Un atacante que solo quiere enviar contenido fraudulento por un canal de correo electrónico confiable no nombra la organización como su objetivo, investiga empleados individuales ni adjunta una tarjeta de crédito. Esa inversión solo rinde si los empleados realmente se unen a la organización y empiezan a usarla. Y en una plataforma de IA, los datos que la gente introduce en los prompts pueden ser extraordinariamente sensibles: código fuente, documentos internos, datos de clientes, investigaciones de seguridad, planes estratégicos». El phishing ahora incluye plataformas de IA como infraestructura de recolección. Los atacantes no solo buscan credenciales. Están construyendo entornos donde los objetivos entregan voluntariamente el contenido más sensible con el que trabajan. La exposición de propiedad intelectual aquí es grave: el código fuente y los planes estratégicos enviados a un espacio de trabajo fraudulento representan una pérdida directa de propiedad intelectual sin un camino claro de remediación una vez que los datos salen del control de la organización.
La formación en concienciación de seguridad es necesaria pero no suficiente aquí. La pregunta de gobernanza es si el acceso empresarial a la IA se canaliza a través de un entorno controlado donde lo que entra y lo que sale es visible para el equipo de seguridad, y donde la propia plataforma está bajo control organizacional, no prestada de un proveedor externo sin supervisión.
Agentes guardianes y la brecha de gobernanza de identidades
Un análisis de Hacker News publicado el 26 de junio describe el modelo de «agente guardián»: sistemas de IA desplegados para auditar, gobernar y terminar otros agentes de IA. El argumento es estructural: la gestión de identidades y accesos (IAM) tradicional se construyó en torno a eventos de autenticación. Una persona presenta credenciales, se concede o deniega el acceso y la sesión queda registrada. Los agentes no siguen esa secuencia.
Un agente se autentica una vez, normalmente mediante un token de larga duración o credencial API, y luego opera de forma continua a través de sesiones, sistemas y contextos sin un punto de control de gobernanza intermedio. Cuando un agente actúa en nombre de un director de ventas, lleva los tokens OAuth de esa persona, sus permisos delegados y cualquier acceso sobreprivilegiado acumulado tras años de cambios de rol. El agente no distingue entre lo que la persona haría y lo que se le ha ordenado hacer. Ejecuta con toda la autoridad heredada en cada aplicación a la que esa identidad puede acceder: sistemas CRM, repositorios de código, almacenes de documentos, APIs internas, todo en una sola sesión, todo mediante credenciales originalmente pensadas para un usuario humano en un contexto completamente distinto.
Esto genera, en entornos sin gobernanza dedicada de agentes, lo que el análisis llama «materia oscura de identidad»: actividad de identidad que existe y representa un riesgo real dentro de un entorno, pero permanece invisible para las herramientas encargadas de gobernarla. Los agentes no pasan por flujos de solicitud de acceso. No se incorporan a los sistemas de gobernanza de identidades. Heredan credenciales de identidades existentes y empiezan a ejecutar. El resultado es una población creciente de identidades autónomas que operan sin registro formal de gobernanza, sin mapeo de propiedad y sin línea base de comportamiento. La arquitectura de confianza cero exige verificación continua de cada entidad, pero la verificación requiere visibilidad, y la mayoría de las organizaciones no tienen visibilidad sobre lo que hacen sus agentes de IA tras autenticarse. El control de acceso basado en atributos (ABAC) es el mecanismo técnico que hace operativa la verificación continua: las decisiones de acceso evalúan la identidad del agente, la sensibilidad del contenido y el contexto de ejecución en cada solicitud, en vez de depender de un solo evento de autenticación para autorizar toda una sesión.
Los agentes guardianes resuelven esto operando en la capa de ejecución, no en el límite de autenticación. Mantienen un inventario continuo de identidades, líneas base de comportamiento y aplicación de privilegios mínimos en tiempo de ejecución: la capa de gobernanza que las herramientas IAM convencionales no fueron diseñadas para ofrecer. La analogía con el intercambio de contenido gobernado es directa: trasladar el punto de aplicación de seguridad al lugar donde realmente se ejercen los permisos, de modo que los controles de acceso se apliquen según lo que el agente está haciendo en ese momento, no lo que se le asignó meses atrás.
El hilo común: sin límite de contenido aplicado
Cinco revelaciones, cuatro días, una falla estructural. El ataque a Claude Code, la vulnerabilidad de Amazon Q, la brecha de la especificación MCP, la campaña Poisoned Tenant y el análisis de agentes guardianes apuntan a empresas que han implementado agentes de IA con capacidades significativas y sin una capa de gobernanza de contenido aplicada.
El Informe anual de previsión de riesgos de seguridad y cumplimiento de datos 2026 de Kiteworks documentó cómo los riesgos relacionados con IA se estaban convirtiendo en la preocupación principal en los programas de seguridad empresarial, con una brecha persistente entre la velocidad de adopción de IA y la infraestructura de gobernanza que se construye alrededor de ella. La investigación de esta semana muestra cómo se ve esa brecha desde la perspectiva de un atacante. Ya sea por un registro DNS manipulado, un archivo de configuración MCP malicioso, una invitación fraudulenta a un espacio de trabajo de IA o un agente sin gobernanza operando con credenciales sobreprivilegiadas heredadas, el resultado es el mismo: datos sensibles de la empresa llegan a partes no autorizadas a través de un sistema de IA sin límite de acceso aplicado. Cualquiera de estos incidentes, si hubiera involucrado datos regulados, constituiría una brecha de datos notificable bajo HIPAA, GDPR u otros marcos comparables; la exposición de cumplimiento se suma a la exposición de seguridad.
Kiteworks Compliant AI soluciona esa brecha en la capa de datos. Cuando la IA empresarial opera a través del entorno gobernado de Kiteworks, cada interacción de agente está sujeta a aplicación de políticas, cada acceso a datos queda registrado con una traza de auditoría completa, y ningún agente —sin importar las credenciales que lleve o las instrucciones que reciba— puede acceder a contenido fuera de su alcance autorizado explícitamente. Las capacidades de DLP y clasificación de datos se aplican en la capa de API, no después. La fecha límite de la especificación MCP del 28 de julio hace que esto sea más urgente que una simple buena práctica: el nuevo protocolo delega explícitamente la gobernanza de contenido a la capa de aplicación, y las organizaciones que no tengan esa capa antes del 28 de julio estarán ejecutando agentes en un entorno que el protocolo no protegerá.
El CISO Dashboard da a los responsables de seguridad la visibilidad para entender qué accede la IA empresarial, cuándo y quién. En el entorno que describe la investigación de esta semana, esa visibilidad no es opcional. Es el requisito previo para cualquier gobernanza significativa del comportamiento de los agentes de IA. Las organizaciones que realicen una evaluación formal de riesgos de sus implementaciones de agentes de IA deben tratar la ausencia de una capa de contenido gobernada como el hallazgo de máxima prioridad: todos los demás controles asumen que esa capa existe.
Para saber más sobre cómo gobernar el acceso a datos de agentes de IA en entornos regulados, solicita una demo personalizada hoy mismo.
Preguntas frecuentes
El ataque 0Din de Mozilla demuestra que los controles de seguridad integrados pueden ser eludidos cuando un ataque se divide cuidadosamente entre sistemas que el agente nunca examina en conjunto. En la técnica documentada, la carga maliciosa reside en un registro DNS TXT, no en el repositorio ni en ningún archivo que el agente lea directamente. El agente sigue un mensaje de error legítimo que apunta a un comando de recuperación legítimo. Ese comando llama a un script que realiza una consulta DNS. El agente nunca ve la carga útil; ve una secuencia de pasos que parecen autorizados. Como el ataque explota la confianza del agente en los mensajes de error como instrucciones, y no una vulnerabilidad de contenido, los controles estándar que escanean el contenido del repositorio lo pasan por alto por completo. Las organizaciones que buscan entender esta amenaza deben revisar cómo las políticas de protección de datos de IA se aplican a las herramientas de codificación con IA que usan los desarrolladores, no solo al contenido que se les pide procesar. El principio de generative AI de confianza cero de no confiar nunca en entradas del entorno sin verificación aplica directamente aquí. Un plan de respuesta a incidentes documentado que cubra explícitamente escenarios de compromiso de agentes de codificación con IA da a los equipos de seguridad una vía de escalamiento definida cuando se detecta esta clase de ataque.
El parche soluciona específicamente la CVE-2026-12957, pero Wiz señala que el patrón subyacente de autoejecución —archivos de configuración MCP que se ejecutan sin permiso del usuario al abrir un espacio de trabajo— no es exclusivo de Amazon Q. Se han identificado comportamientos similares en otras herramientas de codificación con IA. Cualquier organización que use asistentes de codificación con IA debe auditar si esas herramientas presentan comportamientos de autoejecución similares. En un sentido más amplio, el incidente ilustra que la administración de riesgos de terceros ahora se extiende a las herramientas de IA que usan los desarrolladores, no solo al software que construyen. Un repositorio compartido entre equipos o de origen externo implica una nueva clase de riesgo cuando hay agentes de codificación con IA activos en el entorno de desarrollo. Los programas de administración de riesgos de proveedores deben incluir la capa de herramientas de IA como una categoría de riesgo distinta, no solo el código de terceros que esas herramientas ayudan a producir. Extender las prácticas de gestión de riesgos de la cadena de suministro para cubrir las herramientas de desarrollo de IA cierra una brecha que las revisiones tradicionales de dependencias y paquetes suelen pasar por alto.
Empieza con un inventario: cada implementación de agente de IA que use conexiones MCP, qué contenido pueden acceder esos agentes y bajo qué autoridad. El diseño sin estado de la nueva especificación significa que los controles de acceso entre tenants, la gestión de secretos y las protecciones contra escalamiento de privilegios no se aplican en la capa de protocolo. Deben ser implementados por quien construya y opere el servidor MCP. Las políticas de gobernanza de datos que especifiquen a qué contenido puede acceder un agente, bajo qué condiciones y con qué registro, deben estar listas antes del 28 de julio, no después. Para organizaciones que ya hayan implementado agentes de IA sobre datos regulados —información de salud protegida, registros financieros, información relacionada con defensa— el cambio de especificación es un evento de cumplimiento, no solo de seguridad. El Secure MCP Server de Kiteworks aplica límites de gobernanza en la capa de integración de IA sin importar lo que provea el protocolo, por lo que es una solución práctica para organizaciones que no pueden esperar a que el ecosistema de desarrolladores evolucione. Alimentar los registros de acceso de agentes a una plataforma SIEM desde el primer día da a los equipos de seguridad la capacidad de detección de anomalías en tiempo real que el nuevo protocolo sin estado no proporciona de forma nativa.
El phishing convencional engaña a los usuarios para que hagan clic en un enlace malicioso o entreguen credenciales a un sitio falso. La campaña Poisoned Tenant utiliza la infraestructura legítima de la plataforma: la invitación es real, el correo proviene de la dirección real de notificaciones de OpenAI, supera todas las verificaciones de autenticación y la plataforma es un servicio genuino de OpenAI. Lo fraudulento es solo la organización a la que se invita al usuario. Los controles de seguridad de correo que buscan enlaces maliciosos o remitentes falsificados no lo detectarán porque no hay nada técnicamente malicioso que señalar. Push Security recomienda formar a los empleados para que verifiquen invitaciones inesperadas a organizaciones y monitorizar las membresías en organizaciones SaaS, pero esto también apunta a una necesidad arquitectónica más amplia. El acceso empresarial a la IA debe fluir a través de entornos controlados donde el equipo de seguridad pueda ver lo que los empleados envían. Las plataformas de colaboración segura con aplicación de políticas y registros de auditoría brindan una visibilidad que un espacio de trabajo estándar de ChatGPT no ofrece, y esa visibilidad es la diferencia entre saber que ocurrió una exfiltración y enterarse por el atacante. Aplicar MFA en cada acción de membresía en organizaciones SaaS, no solo en los inicios de sesión principales, habría detectado la asignación de privilegios de propietario en esta campaña antes de que se enviara contenido sensible.
Un agente guardián es una capa de control que gobierna la identidad y el comportamiento de los agentes de IA que operan en un entorno empresarial. Mientras las herramientas IAM convencionales gobiernan el acceso en el límite de autenticación, un agente guardián opera en la capa de ejecución: mantiene un inventario continuo de cada identidad autónoma, construye líneas base de comportamiento y aplica políticas de privilegio mínimo en tiempo de ejecución según lo que los agentes realmente hacen en llamadas a herramientas, accesos a datos y movimientos entre sistemas. El concepto está ganando adopción en producción. Su requisito práctico es el pensamiento de intercambio de datos de confianza cero aplicado a identidades de agentes: cada interacción de agente debe ser verificada, no solo autenticada. El análisis del 26 de junio señala que esto requiere un plano de control diseñado para la capa de ejecución: las herramientas IAM, PAM y CIEM existentes no fueron creadas para seguir a un agente a través de una sesión multisistema y aplicar políticas en cada paso. Los programas de gobernanza de datos de IA que tratan a los agentes de IA como identidades gobernadas con límites de acceso a contenido definidos son el requisito organizacional para que los controles de agentes guardianes sean efectivos en la práctica. La minimización de datos aplicada al alcance de credenciales de los agentes —garantizando que un agente herede solo el acceso necesario para su tarea específica, y no el conjunto completo de permisos de la identidad humana para la que opera— es la forma más directa de limitar el alcance del daño antes de que maduren más las herramientas de agentes guardianes.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juega 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.