Lecciones de ciberinmunidad para agentes de IA

Los sistemas de IA son mucho más difíciles de proteger que los sistemas informáticos tradicionales, ya sea por errores de los operadores, interferencias maliciosas o simplemente por un comportamiento inestable. Esto se debe a dos motivos principales. En primer lugar, los resultados de la IA son probabilísticos, por lo que una misma instrucción puede generar respuestas distintas cada vez que se ejecuta. En segundo lugar, los LLM actuales no pueden distinguir de forma fiable entre órdenes y datos. A pesar de los problemas de seguridad demostrados de los sistemas de IA de los que hemos hablado tantas veces, resulta imposible ignorar los posibles beneficios económicos que supone su adopción. Por eso, muchas empresas están pasando de los simples asistentes de IA a los agentes de IA. Estos agentes realizan tareas por su cuenta y tienen acceso directo a las mismas herramientas que las personas, desde consultar bases de datos hasta modificar la configuración de los procesos de producción. Nuestros expertos, en su nuevo estudio, analizan cómo definir claramente y minimizar los riesgos derivados para reducir al mínimo los posibles problemas. Este enfoque toma prestados y adapta los principios de “ciberinmunidad” y “seguridad desde el diseño” (Secure by Design).

Los principios básicos de la seguridad desde el diseño

Todos los principios de esta disciplina son de aplicación universal al diseño de cualquier sistema informático, incluidos los agentes de IA. Lo que difiere es el grado de adaptación y revisión que requiere cada principio para los escenarios de IA.

1. La seguridad es un factor independiente e importante desde la propia fase de diseño. Los objetivos y supuestos de seguridad se establecen desde el primer día y se respetan a lo largo de todas las fases del desarrollo. En el caso de los agentes de IA, estos supuestos deben incluir tres puntos clave: (i) el modelo de lenguaje se considera no fiable, (ii) los datos externos de cualquier tipo se consideran potencialmente maliciosos y (iii) no se pueden realizar acciones irreversibles de forma autónoma sin la aprobación obligatoria de un ser humano.
2. El sistema se diseña partiendo del supuesto de que sufrirá ataques.
3. La base informática de confianza y la superficie de ataque se reducen al mínimo. Los agentes solo disponen de las herramientas que realmente necesitan, permisos limitados y la menor cantidad de contexto posible. La aplicación de la política de seguridad se gestiona íntegramente mediante componentes determinísticos: el supervisor de políticas, el arnés del agente y los mecanismos de aislamiento (entornos aislados).
4. Se aplica el principio de privilegio mínimo. Cada agente tiene su propio conjunto de credenciales y privilegios de acceso (identidad), limitados al mínimo imprescindible para realizar su trabajo. Si un agente necesita temporalmente privilegios elevados, solo los obtiene tras recibir una autorización externa, y estos duran exactamente lo que dura la tarea que los requiere.
5. Los componentes están aislados. En los sistemas basados en agentes, este es uno de los problemas de arquitectura más complejos y con múltiples capas. El entorno de ejecución del agente debe funcionar en un entorno con aislamiento (entorno aislado o máquina virtual), y los agentes deben mantenerse lo más aislados posible entre sí. El procesamiento de datos en contextos de confianza y no fiables también se mantiene separado. Por ejemplo, un agente lee una solicitud de incorporación de cambios y escribe un borrador del código, mientras que otro revisa ese trabajo sin llegar a ver el texto potencialmente malicioso de la solicitud.
6. La regla predeterminada es la denegación. Las políticas de seguridad siguen la regla: todo lo que no esté explícitamente permitido está prohibido. Esto incluye las llamadas a herramientas, las interacciones entre agentes y el tráfico de red.
7. Se aplica la defensa en profundidad. Las diferentes medidas deben funcionar al mismo tiempo y reforzarse entre sí. Las defensas probabilísticas, como los mecanismos de protección de la IA (un “firewall” para los modelos de lenguaje) o la alineación (el criterio del propio modelo sobre lo que es aceptable y lo que no), no pueden ofrecer garantías formales de seguridad. No obstante, hacen que el sistema sea más seguro en su conjunto y constituyen una valiosa fuente de telemetría.
8. La cadena de suministro está protegida. Algunos agentes pueden instalar habilidades, bibliotecas y otros componentes de software por su cuenta, por lo que estas capacidades deben regirse por normas estrictas. O bien se bloquean por completo, o bien se limitan a una lista cerrada y preaprobada de versiones específicas de componentes concretos. Los sistemas basados en modelos de lenguaje grandes (LLM) en la nube se enfrentan a un riesgo adicional: las actualizaciones de los modelos. Un día, la misma solicitud de API podría ser respondida por un modelo de lenguaje diferente con propiedades de seguridad distintas.

Las trampas de la seguridad de la IA

Los principios generales de la seguridad desde el diseño son bien conocidos y parecen sencillos en teoría. Sin embargo, aplicarlos a los sistemas de IA es complicado porque los agentes son increíblemente flexibles. Por ejemplo, un equipo de seguridad podría creer que un agente en el ordenador de un desarrollador se ejecuta en un entorno aislado y no puede modificar nada fuera de él. Pero un atacante, o incluso el propio agente, puede idear decenas de formas de eludir esta protección aparentemente sólida: desde ejecutar comandos a través de un servidor MCP local que no está sujeto a las restricciones del entorno aislado hasta reconfigurar otro agente de IA instalado en el sistema. Para complicar aún más las cosas, la variedad de vectores de ataque es enorme: desde campos arbitrarios en la configuración del agente hasta cadenas de texto aparentemente inofensivas en un archivo de habilidades.

Un problema grave que los diseñadores suelen subestimar es la fatiga del usuario. Un agente muy activo puede generar docenas de solicitudes cada minuto, pidiendo al usuario que confirme acciones potencialmente peligrosas. En menos de una hora, la persona está haciendo clic en Aprobar de forma automática sin leer lo que está aprobando. Por eso es importante ajustar cuidadosamente tanto la frecuencia con la que aparecen estas solicitudes como la forma en que están redactadas. Nadie leerá una descripción de la solicitud que sea demasiado larga. Y una demasiado corta puede ocultar los detalles clave que el usuario necesita para tomar la decisión correcta.

Las vulnerabilidades en los agentes y las herramientas relacionadas son un problema preocupante, y se ve agravado por la rapidez con la que estas categorías de software evolucionan y reciben actualizaciones. En plataformas y aplicaciones de uso habitual en el sector, como LangGraph, MS Semantic Kernel y Claude Code, se han corregido vulnerabilidades críticas en más de una ocasión. Los arquitectos siempre deberían plantearse sustituir un marco de trabajo grande y polivalente por un sistema compacto y simplificado que cuente únicamente con las funciones que un agente específico realmente necesita.

Además, la implementación cuidadosa de medidas de seguridad estándar y consolidadas en las herramientas disponibles reduce en gran medida el daño si un agente sufre un ataque o se comporta de forma inesperada. Un ejemplo es una lista de dominios permitidos estricta que la herramienta de recuperación web puede abrir cuando el agente lo solicite. Sin embargo, los diseñadores rara vez tienen en cuenta los problemas ocultos y la sobrecarga asociados al mantenimiento de dicha lista. Como resultado, la lista queda obsoleta poco a poco y deja brechas para los atacantes. El ejemplo más llamativo es el ataque EchoLeak. Microsoft 365 Copilot contaba con una lista de sitios permitidos correctamente implementada y bastante eficaz para acceder a sitios externos, pero los atacantes la eludieron a través de una función de una herramienta secundaria y del dominio de MS Teams.

Consejos prácticos para arquitectos y equipos de seguridad

Los arquitectos de sistemas de IA y los responsables de los equipos de ingeniería y seguridad deben integrar la seguridad de los agentes desde la fase de diseño. Deben basarse principalmente en mecanismos verificables y deterministas: aislar componentes, controlar las interacciones y reducir al mínimo la base informática de confianza.

Entre las decisiones arquitectónicas clave se incluyen definir el nivel de autonomía aceptable para los agentes, limitar el acceso a datos confidenciales y a combinaciones peligrosas de capacidades, y utilizar entornos aislados, roles separados para los distintos modelos y puertas de enlace de control de acceso. Las restricciones añadidas posteriormente reducen los riesgos, pero no sustituyen a una arquitectura segura.

A nivel organizativo y operativo, las empresas deben llevar un inventario de sus agentes, coordinar los esfuerzos de los equipos de seguridad y de implementación, proteger los entornos de contenedores, gestionar la cadena de suministro (AIBOM) e integrar una defensa multicapa.

La observabilidad requiere especial atención. En el caso de los sistemas de IA, esto debería incluir el registro de las solicitudes, respuestas y razonamientos del LLM, así como telemetría detallada de los hosts y los entornos en la nube donde se ejecuta el agente.

La parte más difícil del diseño de agentes es encontrar el equilibrio entre seguridad, rendimiento y utilidad. Para saber cómo lograr ese equilibrio mediante el modelado de amenazas y unos objetivos de seguridad claramente definidos, lee la versión completa del estudio.