Los agentes de IA son cada vez más inteligentes y su superficie de ataque sigue creciendo

En el momento en que los agentes de inteligencia artificial comenzaron a programar reuniones, ejecutar código y navegar por la web en su nombre, la conversación sobre ciberseguridad cambió. No de forma gradual, sino de la noche a la mañana.

Lo que solía ser un sistema de software acotado y predecible se convirtió en algo que razona, planea y toma acciones a través de herramientas y API cuya existencia apenas conocía un año antes.

Eso es genuinamente emocionante, y también es genuinamente aterrador, porque la superficie de ataque que viene con esa autonomía es enorme, y la mayoría de las organizaciones apenas comienzan a entender qué significa dejar que los agentes entren en su infraestructura.

De chatbots a operadores

La promesa original de la inteligencia artificial era simple: hacer una pregunta, obtener una respuesta. Eso sigue siendo cierto para la mayoría de las interacciones de los consumidores, pero no es lo que está sucediendo en las implementaciones empresariales. Hoy en día, los agentes están recibiendo credenciales, claves de API y la capacidad de eliminar, crear y anotar datos, así como realizar acciones reales dentro de sistemas que tienen consecuencias reales.

El cambio sucedió rápidamente. En menos de dos años, los agentes de inteligencia artificial pasaron de ser generadores de texto a permitirnos ejecutar sistemas multiagentes que funcionan con fluidez. Están leyendo correos electrónicos, activando flujos de trabajo, consultando bases de datos y, en algunos casos, gestionando a agentes subordinados. Ese nivel de acceso solía requerir un proceso de adquisición largo y la participación de una persona en el proceso. Ahora es un archivo de configuración y algunas llamadas a API.

Más acceso significa más exposición

Los ataques de software tradicionales tienen un perfil más o menos predecible. Hay un punto de entrada conocido, una vulnerabilidad conocida, un parche conocido. Los agentes de inteligencia artificial rompen ese modelo porque son dinámicos por diseño. No siguen una ruta de código estática. Razonan sobre qué hacer a continuación, lo que significa que su comportamiento es más difícil de predecir y mucho más difícil de auditar a posteriori.

Esta imprevisibilidad es útil para realizar trabajo. También es una ventaja para cualquiera que intente explotar el sistema. Cuando un agente puede decidir, en medio de una tarea, llamar a una API externa o incorporar una herramienta de terceros, no hay un perímetro bien definido que defender.

Los equipos de seguridad están acostumbrados a proteger superficies conocidas y monitorear los costos de Kubernetes. Los agentes siguen descubriendo nuevas superficies de ataque y métodos para explotar vulnerabilidades, y nadie los está mapeando en tiempo real. Antes de que te des cuenta, alguien puede apoderarse de las credenciales y obtener el control sobre todo el “organismo” de inteligencia artificial con un solo movimiento.

La inyección de prompts es la nueva inyección SQL

Si hay un vector de ataque que los investigadores de seguridad siguen volviendo a mencionar, es la inyección de prompts. La idea es sencilla: en lugar de explotar una vulnerabilidad de código, un atacante manipula las instrucciones que un agente recibe a través de sus entradas. Una instrucción maliciosa incrustada en una página web, un documento o incluso un correo electrónico puede redirigir lo que el agente hace a continuación.

Lo que hace que esto sea especialmente peligroso es que los agentes a menudo están haciendo exactamente lo que se les dice. Están procesando contenido de la web, de mensajes de usuario, de herramientas de terceros. Cualquiera de esos contenidos puede ser una superficie potencial de inyección. Un agente que lee un documento comprometido y luego realiza llamadas a API basadas en su contenido ha sido secuestrado, y probablemente no registrará nada que haga que la cadena de causalidad sea obvia.

Las defensas aquí son reales pero incompletas. El aislamiento de las acciones de los agentes en entornos restringidos, la restricción de las herramientas que un agente puede llamar en ciertos contextos y la creación de puntos de control humanos en flujos de trabajo de alto riesgo reducen el riesgo. No lo eliminan. Y la mayoría de las organizaciones aún no han implementado ni las medidas básicas.

El problema de confianza en los sistemas multiagentes

Los sistemas multiagentes introducen una capa de complejidad que es fácil de subestimar. Cuando un agente está orquestando a varios otros, hay una jerarquía de confianza en juego. El orquestador pasa instrucciones hacia abajo, y los subagentes las siguen. Si ese orquestador se ve comprometido, cada agente subordinado también queda comprometido en la práctica, y el alcance del impacto aumenta con mucha rapidez.

Hay también el problema de la concesión excesiva de permisos. Los agentes a menudo reciben más acceso del que necesitan porque es más fácil dar permisos amplios de antemano que refinarlos iterativamente. Un agente de investigación no necesita acceso de escritura a una base de datos de producción.

Un agente que programa reuniones no necesita acceso a registros financieros. Claro, es reconfortante tener todo interconectado, pero el riesgo es sencillamente demasiado alto para que los beneficios se mantengan sin disminuir. Pero las líneas se vuelven borrosas en la práctica, y los principios de permisos mínimos que funcionan bien en teoría se abandonan silenciosamente en la prisa por lanzar el producto.

Cómo es una seguridad razonable en este contexto

No hay una solución única que haga que las implementaciones de agentes sean seguras. Es un problema en capas y necesita una respuesta en capas. Las organizaciones que lo hacen bien tienden a comenzar con controles de acceso: dar a cada agente un alcance definido y estrecho, y incorporar pasos de revisión a cualquier acción que afecte a sistemas sensibles o servicios externos.

La observabilidad es tan importante como la prevención. Si un agente hace algo inesperado, los equipos necesitan una traza completa de qué instrucciones recibió, qué herramientas llamó, y qué devolvió. La mayoría de las configuraciones de registro no están diseñadas con ese nivel de granularidad en mente, y añadir esa capacidad a posteriori es laborioso. Merece la pena afrontar las dificultades de incorporarla desde el principio.

La prueba adversaria también está subutilizada. Hacer pruebas de ataque a los agentes, intentando específicamente inyectar instrucciones maliciosas y viendo qué sucede, revela vulnerabilidades que la revisión de código estático nunca capturará. Es incómodo pensar en ello, pero las personas que eventualmente intentarán explotar estos sistemas ya están realizando esas pruebas. Adelantarse a ellas es la única medida sensata.

Reflexiones finales

Los agentes de inteligencia artificial se convertirán en una parte más grande de cómo operan las organizaciones, y ese cambio ya está muy avanzado. La conversación sobre seguridad necesita ponerse al día, y rápido. Los riesgos son reales, los vectores de ataque son novedosos, y la ventana para adelantarse a ellos se está cerrando.

Entender el panorama de amenazas para los sistemas de inteligencia artificial autónomos ya no es opcional. Es una de las cosas más importantes que los equipos de seguridad y ingeniería pueden estar haciendo en este momento, y el reloj para hacerlo bien ya ha comenzado.