A principios de este mes, hablé en el Cumbre de seguridad y gestión de riesgos de Gartner sobre un punto ciego que la mayoría de los programas de seguridad aún no tienen en cuenta: cómo los atacantes están eludiendo los programas de seguridad de IA utilizando infraestructura heredada para secuestrar agentes de IA.

La adopción de la IA avanza más rápido de lo que los programas de seguridad pueden dar cuenta. Aproximadamente el 71 % de las organizaciones están probando agentes de IA en sus aplicaciones empresariales y el 31 % ya los ha trasladado a flujos de trabajo de producción.

Por esta razón, las organizaciones están invirtiendo recursos legítimamente en proteger las cargas de trabajo de IA contra el envenenamiento de modelos, la inyección rápida, la fuga de datos y otras amenazas emergentes. Sin embargo, este enfoque lo pierde todo. debajo la capa de IA. Porque un servidor sin parches, un permiso de Active Directory mal configurado o una credencial almacenada en caché en la máquina de un desarrollador son exposiciones que brindan a los atacantes una ruta directa a todo de lo que dependen sus agentes de IA: bases de conocimiento, almacenamiento en la nube, funciones Lambda, integraciones SaaS y las credenciales que los conectan.

Esto significa que los actores de amenazas realmente no necesitan atacar su IA de frente. sólo necesitan alcanzar aquello a lo que se conecta. En este artículo, explicaré cómo la infraestructura heredada se convierte en la ruta de ataque hacia los entornos de agentes de IA y qué pueden hacer los equipos de seguridad para bloquear esas rutas.

Los agentes de IA usan lo que heredan

A pesar de su novedad y poder, en cierto modo los agentes de IA operan como otros activos en su entorno. Se autentican a través de proveedores de identidad existentes, almacenan datos en depósitos de nube existentes, ejecutan tareas a través de funciones Lambda existentes y heredan permisos de roles de IAM existentes. Cada una de esas dependencias conlleva cualquier deuda de seguridad que tuviera la organización antes de que comenzara el despliegue de la IA.

Es más, la mayoría de las organizaciones, sin darse cuenta, compuesto esa deuda. De acuerdo a Revista Infoseguridadel 70% de las organizaciones otorgan sus sistemas de IA más acceso privilegiado que un humano en el mismo rol. No es sorprendente que esto tenga un precio doloroso. Las organizaciones con IA con privilegios excesivos informaron una tasa de incidentes del 76%, en comparación con solo el 17% de aquellas que imponen privilegios mínimos.

Todas esas conexiones (proveedores de identidad, depósitos en la nube, funciones Lambda, roles de IAM) se ejecutan a través de la infraestructura que sus equipos han administrado durante años: Active Directory, IAM en la nube, cuentas de servicio, credenciales almacenadas. Sin embargo, nada de esto fue diseñado teniendo en mente a los agentes de IA, y la mayor parte se aprovisionó mucho antes de que el primer agente entrara en producción. El resultado es que un atacante que encuentre su camino a través de cualquiera de esas capas no necesita tocar la IA. Los propios permisos del agente hacen el trabajo por él.

Cómo un CVE de 2025 secuestra a un agente de IA en 2026

El siguiente diagrama muestra una arquitectura típica de agente de IA empresarial. Un equipo de éxito del cliente utiliza un Co-Pilot impulsado por IA, alojado en AWS Bedrock, para consultar los datos de los clientes exportados desde Salesforce a un depósito de S3. Co-Pilot ejecuta tareas a través de funciones Lambda y se integra con aplicaciones comerciales. John, un desarrollador, construye y mantiene el agente. Los usuarios de toda la organización interactúan con él a diario.

Ahora bien, esto es lo que sucede cuando un atacante encuentra una manera de entrar. El siguiente diagrama muestra una ruta de ataque que mi equipo modeló en un entorno empresarial real. Ninguna de estas exposiciones es exótica: existen, en alguna combinación, en la mayoría de las redes empresariales en este momento. Lo que los hace peligrosos es cómo se conectan. Así es como se desarrolló el ataque, etapa por etapa.

• Etapa 1: un depósito S3 se convierte en un activo crítico. Para alimentar al CSM Co-Pilot, el equipo exportó datos de Salesforce a un depósito de S3. Esa exportación convirtió el cubo en un objetivo de alto valor que contiene registros confidenciales de clientes. Varios usuarios de la cuenta de AWS recibieron un acceso de lectura demasiado amplio a los depósitos de producción S3, incluido John, el desarrollador de Co-Pilot, que nunca necesitó acceso a los datos de producción. Por sí solo, esto es una simple mala configuración de permisos.
• Etapa 2: un servidor sin parches en el perímetro. Un servidor externo ejecuta Apache Tomcat. Ese servidor está expuesto a CVE-2025-24813 – una falla de ejecución remota de código revelada en marzo de 2025 y agregada al catálogo de vulnerabilidades explotadas conocidas de CISA el mismo mes. Nunca fue parcheado. Debido a que el servidor se encuentra en el entorno empresarial y está unido a Active Directory, un atacante que aproveche la vulnerabilidad puede volcar las credenciales almacenadas en caché de la memoria del servidor y comprometer una cuenta de usuario de AD. De forma aislada, se trata de una vulnerabilidad conocida en un único servidor: grave, pero no crítica.
  
• Etapa 3: la mala configuración de Active Directory permite el movimiento lateral. Esa cuenta de AD comprometida puede abusar de una mala configuración de la delegación restringida basada en recursos para hacerse pasar por John y acceder a su estación de trabajo. John utiliza AWS CLI para administrar los recursos de la nube de Co-Pilot y, detrás de escena, CLI almacena las claves de acceso de AWS en su máquina. El atacante recolecta esas claves. De forma aislada, este es un problema de permisos de AD, uno de los miles que tienen la mayoría de los entornos.
  
• Ahora conecta las tres etapas. El atacante explota CVE-2025-24813 en el perímetro, descarta las credenciales, se mueve lateralmente a través de AD hasta la estación de trabajo de John, recopila sus claves de acceso a AWS y lee cada registro en el depósito de producción S3, el mismo depósito que alimenta la base de conocimientos del Co-Pilot. El agente Co-Pilot ahora está comprometido. El atacante controla lo que lee, en qué confía y lo que devuelve a los usuarios. Ninguna parte de la pila de IA fue atacada directamente. Tres hallazgos moderados (una clave de nube con privilegios excesivos, un servidor web sin parches y una mala configuración de AD) se convirtieron en una ruta de ataque crítica.
  

Qué hacer al respecto

La ruta de ataque que acabo de describir cruza cuatro capas: red, identidad, nube e inteligencia artificial. La mayoría de los programas de seguridad evalúan cada una de esas capas de forma independiente y es posible que ya se conozcan las exposiciones en cada una de ellas. Una herramienta EASM marca el servidor Tomcat. Una herramienta de seguridad de AD detecta la configuración incorrecta de la delegación. Una herramienta CSPM obtiene el acceso S3 con privilegios excesivos. Cada uno informa un hallazgo moderado que puede no remediarse debido a una menor prioridad, pero que en combinación se convierte en un problema crítico: una vulnerabilidad de Tomcat en el perímetro se encadena a través de AD hasta las credenciales de la nube de un desarrollador y termina en la base de conocimientos de un agente de IA.

Cerrar estos caminos comienza con un enfoque de gestión de la exposición que trate las dependencias de los agentes de IA (bases de conocimiento, depósitos de almacenamiento, funciones Lambda, etc.) como activos críticos en sí mismos. A partir de ahí, mapee hacia atrás: ¿qué relaciones de identidad, permisos e infraestructura se conectan a esos activos, y cuáles de esas conexiones conllevan exposiciones explotables en el contexto de su entorno? Cuando trazas el camino completo, surgen puntos de estrangulamiento: lugares donde una única solución bloqueará múltiples rutas hacia tus activos de IA.

Si su plataforma de gestión de exposición puede rastrear esa ruta completa (desde el servidor heredado, pasando por AD y la infraestructura de la nube hasta la base de conocimientos de un agente de IA), puede solucionar la exposición antes de que un atacante la encadene. Si no puede, ninguna barrera de seguridad en la capa de IA lo cerrará.

La conclusión

La adopción de agentes de IA se está acelerando en todos los departamentos empresariales. Y cada nuevo agente que implemente se conecta a una infraestructura que ya está expuesta. Eso significa que la superficie de ataque se agrava con cada despliegue.

La pregunta para los líderes de seguridad no es si su capa de IA está protegida. Se trata de si el entorno en el que operan esos agentes, incluida su infraestructura heredada básica, está brindando a los atacantes el camino para secuestrarlos.

Porque los atacantes no necesitan nuevas técnicas para comprometer a los agentes de IA. Sólo necesitan los viejos y un entorno que les permita utilizar los viejos para explotar lo nuevo.

Nota: Este artículo fue escrito cuidadosamente y contribuido para nuestra audiencia. por Zur UliánitzkyVicepresidente senior de investigación de productos y seguridad, XM Cyber.