A principios de este mes, hablé en la Cumbre de Gestión de Riesgos y Seguridad de Gartner sobre un punto ciego que la mayoría de los programas de seguridad aún no han considerado: 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 está ocurriendo más rápido de lo que los programas de seguridad pueden tomar en cuenta. Aproximadamente el 71% de las organizaciones están poniendo a prueba agentes de IA en sus aplicaciones empresariales y el 31% ya ha trasladado agentes de IA a flujos de trabajo de producción.
Como resultado, las organizaciones están dedicando legítimamente recursos a 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. Pero este enfoque pasa por alto todo lo que se encuentra debajo de la capa de IA. Esto se debe a que los servidores sin parches, los permisos de Active Directory mal configurados o las credenciales almacenadas en caché en las máquinas de los desarrolladores ponen a los atacantes en riesgo de brindarles una ruta directa a todo de lo que dependen los agentes de IA, incluidas las bases de conocimiento, el almacenamiento en la nube, las funciones Lambda, las integraciones de SaaS y las credenciales que los conectan.
Esto significa que los actores de amenazas no necesitan atacar la IA de frente, solo necesitan llegar al lugar donde se conecta. Este artículo explica cómo la infraestructura heredada proporciona vectores de ataque en entornos de agentes de IA y qué pueden hacer los equipos de seguridad para bloquear esos vectores.
Los agentes de IA usan herencia
A pesar de su novedad y poder, los agentes de IA se comportan en cierto modo como otros activos del entorno. Se autentican a través de su proveedor de identidad existente, almacenan datos en sus depósitos de nube existentes, ejecutan tareas a través de sus funciones Lambda existentes y heredan permisos de sus roles de IAM existentes. Cada una de estas dependencias lleva consigo cualquier deuda de seguridad que la organización tuviera antes de que comenzara la implementación de la IA.
Además, la mayoría de las organizaciones, sin saberlo, aumentan su deuda. Según la revista Infosecurity, el 70% de las organizaciones otorgan a los sistemas de inteligencia artificial un acceso más privilegiado que a los humanos en el mismo rol. Naturalmente, esto tiene un precio elevado. Las organizaciones que implementaron IA con privilegios excesivos tuvieron una tasa de incidentes del 76 %, en comparación con solo el 17 % de las organizaciones que impusieron privilegios mínimos.
Todas estas conexiones (proveedores de identidad, depósitos en la nube, funciones Lambda, roles de IAM) se realizan a través de la infraestructura que el equipo ha administrado durante años (Active Directory, IAM en la nube, cuentas de servicio, credenciales almacenadas). Sin embargo, ninguno de ellos fue diseñado teniendo en cuenta a los agentes de IA y la mayoría se aprovisionaron mucho antes de que el primer agente entrara en producción. Como resultado, un atacante que penetre cualquiera de estas capas no necesita tocar la IA. La propia autoridad del agente actúa en nombre del agente.
Cómo los CVE en 2025 pueden secuestrar agentes de IA en 2026
El siguiente diagrama muestra la arquitectura de un agente de IA empresarial típico. El equipo de éxito del cliente utiliza Co-Pilot con tecnología de IA alojado en AWS Bedrock para consultar los datos de los clientes exportados desde Salesforce a los depósitos de S3. Co-Pilot ejecuta tareas y se integra con aplicaciones comerciales a través de funciones Lambda. El desarrollador John crea y mantiene agentes. Los usuarios de su organización interactúan con él todos los días.
Esto es lo que sucede cuando un atacante encuentra una manera de entrar. El siguiente diagrama muestra la ruta de ataque que mi equipo modeló en un entorno empresarial real. Ninguno de estos peligros es único. Hoy en día, existen en alguna combinación en la mayoría de las redes corporativas. Lo que los hace peligrosos es cómo están conectados. Muestra cómo evolucionó el ataque paso a paso.
Etapa 1: su depósito S3 se convierte en un activo fundamental. Para alimentar a CSM Co-Pilot, el equipo exportó datos de Salesforce a un depósito de S3. Esta exportación convirtió el depósito en un objetivo de alto valor que contiene registros confidenciales de clientes. Varios usuarios de su cuenta de AWS recibieron amplio acceso de lectura a su depósito S3 de producción. Esto incluye al desarrollador copiloto John, que no necesitaba acceso a los datos de producción. Esto en sí mismo es una simple configuración incorrecta de permisos. Etapa 2: servidores sin parches en el perímetro. El servidor externo ejecuta Apache Tomcat. Este servidor está expuesto a CVE-2025-24813. CVE-2025-24813 es una falla de ejecución remota de código que se reveló en marzo de 2025 y se agregó al catálogo de vulnerabilidades explotadas conocidas de CISA el mismo mes. El parche nunca se aplicó. Debido a que el servidor se encuentra en un entorno empresarial y está unido a Active Directory, un atacante que aprovechara esta vulnerabilidad podría volcar las credenciales almacenadas en caché de la memoria del servidor y comprometer las cuentas de usuario de AD. Por sí sola, se trata de una vulnerabilidad conocida en un único servidor que es grave pero no mortal.
Etapa 3: la mala configuración de Active Directory permite el movimiento lateral. Una cuenta de AD comprometida podría aprovechar una mala configuración de la delegación restringida basada en recursos para hacerse pasar por John y obtener acceso a su estación de trabajo. John utiliza la CLI de AWS para administrar los recursos de la nube del copiloto y, entre bastidores, la CLI almacena las claves de acceso de AWS en su máquina. El atacante recoge esas claves. Por sí solo, este es un problema de permisos de AD, uno de los miles de problemas que ocurren en la mayoría de los entornos.
A continuación, conecte las tres etapas. Un atacante explota CVE-2025-24813 en el perímetro, volca credenciales, se mueve lateralmente a través de AD hasta la estación de trabajo de John, recopila claves de acceso de AWS y lee todos los registros en el depósito S3 de producción (el mismo depósito que alimenta la base de conocimientos del copiloto). El agente copiloto estaba en peligro. El atacante controla lo que se lee, lo que se confía y lo que se devuelve al usuario. Ninguna parte de la pila de IA fue atacada directamente. Tres hallazgos moderados (claves de nube con privilegios excesivos, servidores web sin parches y configuraciones incorrectas de AD) se convirtieron en un vector de ataque importante.
que hacer al respecto
La ruta de ataque que acabamos de describir abarca cuatro capas: red, identidad, nube e inteligencia artificial. La mayoría de los programas de seguridad evalúan cada una de estas capas por separado, por lo que es posible que ya sepas qué tan peligrosa es cada capa. La herramienta EASM marca el servidor Tomcat. Las herramientas de seguridad de AD detectan configuraciones erróneas de delegación. La herramienta CSPM obtiene acceso S3 con privilegios excesivos. Cada uno informa un hallazgo moderado y es posible que no se solucione debido a su baja prioridad, pero cuando se combinan se convierten en un problema importante. La vulnerabilidad de Tomcat en el perímetro conduce a las credenciales de la nube del desarrollador a través de AD y termina en la base de conocimientos del agente de IA.
Cerrar estas vías 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 por derecho propio. A partir de ahí, mapee hacia atrás qué relaciones de identidad, permisos e infraestructura están conectados a esos activos, y cuáles de esas conexiones corren el riesgo de ser explotables en el contexto de su entorno. Los cuellos de botella aparecen cuando trazas el camino completo. Aquí es donde una única solución bloquea múltiples rutas hacia un activo de IA.
Si una plataforma de gestión de exposición puede rastrear su ruta completa (desde los servidores heredados hasta la infraestructura de nube y AD hasta la base de conocimientos del agente de IA), puede remediar las exposiciones antes de que los atacantes puedan encadenarlas. Si no puedes hacer eso, ninguna cantidad de barreras que coloques en tu capa de IA la cerrará.
conclusión
La adopción de agentes de IA se está acelerando en todos los departamentos de la empresa. Y cada nuevo agente que implemente se conecta a su infraestructura ya expuesta. Esto significa que la superficie de ataque crece con cada implementación.
La pregunta para los líderes de seguridad no es si la capa de IA está protegida. La pregunta clave es si el entorno en el que operan estos agentes, incluida la infraestructura heredada subyacente, proporciona una vía para que los atacantes los secuestren.
Porque los atacantes no necesitan nuevas técnicas para comprometer a los agentes de IA. Todo lo que necesitan es lo viejo y un entorno donde puedan utilizar lo viejo para aprovechar lo nuevo.
Nota: Este artículo fue escrito cuidadosamente y contribuido a nuestros lectores por Zur Ulianitzky, vicepresidente senior de investigación de productos y seguridad de XM Cyber.
Source link
