Cómo diseñamos agentes más seguros

Para construir agentes de IA más seguros, debemos diseñar teniendo en cuenta tanto sus capacidades como sus fallas. Incluso al realizar tareas legítimas, y sin ninguna instrucción maliciosa, los agentes pueden cruzar los límites de seguridad mientras intentan superar obstáculos.

Creemos que este es un problema de ingeniería de seguridad, y la industria debe abordarlo de la forma en que abordó los gusanos de internet de principios de la década de 2000. Los sistemas que rodean a los agentes deben limitar lo que los agentes pueden acceder, detectar comportamientos no deseados y contener las fallas cuando ocurren.

En Perplexity, colaboramos activamente con investigadores y profesionales para avanzar en la ingeniería de seguridad para agentes de IA, y aplicamos múltiples capas de defensa en nuestros modelos, harnesses de agentes e infraestructura para que la seguridad no dependa de ninguna salvaguarda individual.

Comportamiento de colapso de los agentes de IA

En julio, los agentes de IA irrumpieron en la infraestructura de producción de la plataforma de IA de código abierto Hugging Face. Durante las pruebas y entrenamientos internos de ciberseguridad, los modelos de OpenAI descubrieron una forma de explotar el administrador de repositorios Artifactory para establecer un tablero de anuncios para comunicarse entre sí, lo que les permitió organizarse en enjambres. Más tarde, los agentes que no pudieron avanzar en las tareas de un punto de referencia de ciberseguridad reclutaron a otros agentes para que los ayudaran. Estos agentes salieron de su entorno de evaluación y llegaron a Internet. También descubrieron formas de hacer trampa mediante la ingeniería inversa de las respuestas a las tareas del punto de referencia, pero pensaron que el sistema de calificación detectaría el fraude. Para comprender mejor cómo funcionaba la evaluación del punto de referencia a fin de encontrar formas de evitar ser detectados haciendo trampa, finalmente comprometieron los sistemas de Hugging Face (Hugging Face; OpenAI).

El incidente es un claro ejemplo de un modo de fallo que describimos cuando hicimos de código abierto a Numbat en julio: colapsos accidentales, un término acuñado por investigadores de seguridad de Cornell Tech (arXiv). Un agente que persigue un objetivo legítimo encuentra fricción, como un archivo faltante, una llamada API fallida, una credencial caducada o una denegación de permisos, y busca una solución alternativa. Al hacerlo, puede cruzar los límites de seguridad mediante reconocimiento, escalada de privilegios, descubrimiento de secretos o exfiltración de datos. El agente en sí se convierte efectivamente en el adversario, aunque no intervenga ningún aviso malicioso ni atacante externo.

Hugging Face no fue un caso aislado. En las últimas semanas se han descubierto e informado más comportamientos de colapso de agentes. Los días 27 y 28 de mayo, los agentes que intentaban recopilar datos de la Universidad de Iowa de Data USA, una plataforma que ofrece acceso abierto a datos del gobierno de EE. UU., se encontraron con errores causados por una consulta mal formada. Respondieron con sondeos, que incluyeron inyección SQL, secuencias de comandos en sitios cruzados (XSS), inyección de plantillas, salto de directorios e inyección de comandos. Posteriormente, la actividad se vinculó con OpenAI (SecurityWeek). Los días 20 y 21 de junio, los agentes de OpenAI que intentaban obtener los costos gubernamentales por persona para una categoría de medicamentos en áreas locales de Victoria del Instituto Australiano de Salud y Bienestar (AIHW) no pudieron descargar un archivo. En respuesta, los agentes descargaron el archivo, que ya era público, del servidor de preproducción de AIHW, eludiendo en el proceso las protecciones anti-bot del sitio (SecurityWeek).

El patrón no se limita a un solo laboratorio. Durante las pruebas de ciberseguridad, los modelos de Anthropic vulneraron a tres empresas después de que un error les diera acceso abierto a Internet, el Gemini de Google adivinó las credenciales de tres sitios web y un modelo de Meta explotó un servicio de terceros (Reuters).

Aprendiendo de la historia: La era de los gusanos de internet

Estos incidentes recuerdan la era de los gusanos de internet de hace aproximadamente un cuarto de siglo. A principios de la década de 2000, internet creció mucho más rápido que las prácticas de seguridad a su alrededor. Vimos una ola de virus y gusanos, con consecuencias mucho más graves que las que estamos viendo ahora con los agentes de IA en colapso.

El 4 de mayo de 2000, la gente comenzó a recibir correos electrónicos de remitentes conocidos con el asunto "ILOVEYOU". Abrir el archivo adjunto en el correo electrónico dio como resultado la ejecución de un script que enviaba una copia de sí mismo a todos los contactos de la libreta de direcciones de Outlook de la víctima. A las 6 p.m. de ese día, el Centro de Coordinación del CERT había recibido informes que involucraban a más de 420.000 hosts de internet (Informe de la GAO de EE. UU.). Según los informes, el virus penetró en al menos 14 agencias federales, incluido el Departamento de Defensa, la CIA, la NASA y la Cámara y el Senado (Informe de la GAO de EE. UU.). También cerró los servidores de correo electrónico en el Pentágono y el Parlamento británico (Wired). El gigante de seguros Lloyd's de Londres hizo una estimación inicial de que el virus costaría más de 15.000 millones de dólares en daños y pérdida de productividad (Audiencia del Comité de la Cámara de Representantes de EE. UU.). Computer Economics estimó posteriormente 8.750 millones de dólares en daños en todo el mundo (Information Week).

Los gusanos que no necesitaban clics humanos llegaron después. El 19 de julio de 2001, el gusano Code-Red infectó a más de 359,000 computadoras en menos de 14 horas (CAIDA). El 25 de enero de 2003, SQL Slammer duplicó su tamaño cada 8.5 segundos e infectó a más del 90% de los hosts de internet vulnerables a él en 10 minutos (CAIDA), explotando un agujero para el cual Microsoft había lanzado un parche seis meses antes (CNET). En agosto de 2003, aparecieron el gusano Blaster y el gusano de correo electrónico Sobig con una semana de diferencia (Microsoft, F-Secure).

En ese momento, era razonable preguntarse si las computadoras conectadas en red podían hacerse seguras en absoluto. Seis días después del virus ILOVEYOU, un subcomité de la Cámara de Representantes de EE. UU. celebró una audiencia al respecto. Muchos expertos en seguridad pidieron una legislación que hiciera a las empresas de software responsables de los daños causados por fallas en sus productos. Washington tomó un camino diferente. La Estrategia Nacional para Asegurar el Ciberespacio declaró que "la regulación federal no se convertirá en un medio principal para asegurar el ciberespacio". Advirtió que los mandatos amplios podrían crear un "enfoque de denominador común más bajo para la ciberseguridad" (CISA).

La industria respondió con ingeniería. Once días después de ILOVEYOU, Microsoft anunció una actualización de Outlook que bloqueaba los archivos adjuntos ejecutables. En enero de 2002, la empresa convirtió la seguridad en su máxima prioridad (Seattle Times). Los parches automáticos, los valores predeterminados seguros, los programas de recompensas por errores y la divulgación coordinada se convirtieron en prácticas estándar. En 2008, Chrome comenzó a ejecutar contenido web en un entorno aislado que "limita lo que un atacante puede hacer después de explotar un error" (Chromium Blog). El cifrado, que antes era una excepción, se convirtió en la norma. Las tecnologías de seguridad, incluidas la autenticación multifactor, los cortafuegos, la confianza cero y la gestión de eventos e información de seguridad (SIEM), se volvieron de uso generalizado. Se pronostica que las organizaciones de todo el mundo gastarán unos 240.000 millones de dólares en 2026 en seguridad de la información (Gartner). Los gusanos nunca desaparecieron por completo, pero la era de los brotes rutinarios en todo internet se desvaneció. Al mismo tiempo, internet, en gran medida libre de regulaciones, se convirtió en un potente motor de innovación y crecimiento económico durante las dos décadas siguientes.

Ingeniería de seguridad para agentes de IA

Los incidentes recientes han planteado preguntas legítimas sobre la gobernanza de agentes. Los mecanismos de seguridad existentes se desarrollaron para entornos informáticos preagente caracterizados por un comportamiento de software estrictamente acotado y en gran medida determinista. Los mecanismos de control de acceso, en particular, están diseñados principalmente en torno a usuarios humanos y a menudo les otorgan amplios privilegios que, en principio, son suficientes para causar daños significativos.

Este diseño se basa en varias suposiciones: la mayoría de los usuarios actúan de buena fe; los actores maliciosos pueden ser disuadidos mediante auditorías y consecuencias del mundo real; y los humanos toman acciones, ya sean correctas o erróneas, a un ritmo relativamente limitado. Aplicar estos mecanismos de seguridad a los agentes requiere tener en cuenta las diferencias entre el comportamiento humano y el del agente. Como escribimos en nuestra respuesta a la solicitud de información de NIST sobre la seguridad de los agentes de IA, los agentes de IA desafían estas suposiciones. Pueden ejercer privilegios y realizar acciones a la velocidad de las máquinas, no se sienten disuadidos por las consecuencias del mundo real y pueden realizar acciones que están técnicamente permitidas pero que un usuario humano típico rara vez realizaría.

Responder a esas preguntas requiere ingeniería de seguridad. Conocemos los principios de seguridad para construir sistemas que mantengan los riesgos bajo control cuando los componentes individuales se comportan mal. Pero debemos asegurarnos de que estos principios se apliquen al diseñar los entornos para entrenar, probar y usar agentes de IA.

El principio de seguridad de defensa en profundidad

Podría decirse que el principio de seguridad más importante que debe aplicarse para proteger a los agentes de IA es la defensa en profundidad, que aboga por una arquitectura de seguridad por capas, donde se emplean múltiples medidas defensivas, variadas y redundantes para proteger los recursos del sistema. Ninguna salvaguarda por sí sola es perfecta. Las personas pueden caer en ataques de ingeniería social y revelar sus credenciales de inicio de sesión, se descubren y explotan vulnerabilidades de software de día cero, y la detección de intrusiones pasa por alto nuevas variantes de ataques. La defensa en profundidad acepta esto y apila varias capas independientes de defensa. Si se elude una capa defensiva, las otras capas permanecen en su lugar para contrarrestar o detectar la intrusión.

El incidente de Hugging Face muestra por qué la defensa en profundidad es importante. El informe retrospectivo de OpenAI indica que las salvaguardas automatizadas utilizadas en sus sistemas de producción, incluidos harnesses, modelos de autorrevisión y clasificadores de seguridad, estaban ausentes en el entorno de evaluación. Si su monitoreo de cadena de pensamiento actualmente implementado hubiera estado ejecutándose en esas evaluaciones, habría detectado la actividad inicial y avisado al equipo de seguridad más de un día antes de la brecha (OpenAI). Las capas que podrían haber detectado el problema existían. Simplemente no estaban todas en su lugar al mismo tiempo.

Asegurar los agentes de IA requiere mejorar tanto la seguridad como la protección de los modelos de IA y los sistemas que los rodean. El trabajo en la capa de modelo importa y está dando frutos. Los primeros LLM eran fácilmente manipulados por instrucciones inyectadas, mientras que los modelos actuales son sustancialmente mejores para reconocerlas y rechazarlas. Los desarrolladores de modelos también entrenan modelos para un comportamiento más seguro y, como describe el informe retrospectivo de OpenAI, monitorean los rastros de razonamiento en busca de signos de comportamiento problemático. Pero las defensas a nivel de modelo son solo una parte de la solución. Los sistemas en los que se entrenan, prueban e implementan los agentes también deben diseñarse para la seguridad y la contención. La seguridad a nivel de modelo reduce la probabilidad de que un agente se desvíe; la seguridad a nivel de sistema limita el daño cuando lo hace.

Ampliar

Reglas de diseño para salvaguardas redundantes

La defensa en profundidad requiere salvaguardas redundantes. Para los agentes, recomendamos aplicarla con tres reglas de diseño:

1. Independencia. Cada capa debe fallar por razones independientes. Dos controles que comparten la misma suposición pueden ser superados por el mismo ataque. Los monitores y los puntos de cumplimiento deben ubicarse fuera del alcance del agente.
2. Cumplimiento por debajo del agente. Al menos una capa debe ser determinista: código convencional y verificable que bloquee las acciones prohibidas sin importar lo que produzca el modelo. Una salvaguarda que el agente pueda negarse a invocar, o reconfigurar, no es una salvaguarda.
3. Las señales solo pueden reducir la autoridad. La detección debe activar respuestas que reduzcan lo que el agente puede hacer, como pausar, revocar credenciales, cortar el acceso a la red o terminar la sesión. Ninguna señal de riesgo debe otorgar acceso adicional.

Compartimos estos principios con nuestros socios en la Open Secure AI Alliance, incluida NVIDIA, que ha argumentado que el harness guía lo que un agente intenta mientras la infraestructura controla lo que puede hacer (NVIDIA).

Defensa en profundidad en los productos de Perplexity

Perplexity ejecuta agentes en cuatro tipos de entornos: en la nube a través de nuestra plataforma de agentes Computer, en el navegador a través de Comet, en dispositivos de usuario a través de Portable Computer, y en las computadoras portátiles de los empleados, donde nuestros ingenieros utilizan agentes de codificación de terceros. Cada entorno tiene sus propios riesgos y cada uno recibe varias capas de protección.

En la nube: Computer y SPACE

Cada tarea de Computer se ejecuta en SPACE, nuestra plataforma de entorno aislado, que trata al agente como no confiable de forma predeterminada. Cada tarea obtiene su propia microVM, las credenciales se quedan fuera del entorno aislado y se inyectan solo cuando es necesario, el tráfico saliente se controla fuera del invitado y las instantáneas nos permiten revertir cambios destructivos (Creación de SPACE). Los clientes empresariales también pueden traer sus propias claves de cifrado. Revocar una clave hace que los datos protegidos sean ilegibles, y el agente no puede anular esa decisión.

También probamos si estas capas se mantienen firmes. En Escaping SPACE: Parte I, dimos a nueve modelos de vanguardia acceso root dentro de un entorno aislado SPACE y les pedimos que escaparan. Ninguno escapó de la máquina virtual (VM), pero algunos encontraron formas de sortear la política de red cuando se permitió el acceso parcial a la red. Corregimos esas brechas, confirmamos las correcciones en una nueva prueba y divulgamos debilidades similares que encontramos en ocho de otras 10 plataformas de entorno aislado a sus proveedores.

En el navegador: Comet y BrowseSafe

Comet ha utilizado una defensa de inyección de avisos por capas desde su lanzamiento: los clasificadores examinan el contenido recuperado, los avisos estructurados lo marcan como no confiable, las acciones confidenciales como enviar un correo electrónico o realizar un pedido requieren la confirmación del usuario, y se notifica a los usuarios cuando algo está bloqueado (Defensas de inyección de avisos de Comet). BrowseSafe, el modelo de detección de código abierto detrás de la primera capa, supera a los modelos de vanguardia en nuestro punto de referencia BrowseSafe-Bench, sin embargo, el mismo punto de referencia muestra que ningún detector es infalible, razón por la cual la detección nunca es la única capa (Investigación de BrowseSafe). Computer hereda estas defensas, que han sido auditadas por Trail of Bits (Perplexity).

En el dispositivo: Portable Computer

Portable Computer es un agente de enfoque local: el modelo, el harness, la conversación y la trayectoria permanecen en la máquina del usuario de forma predeterminada. Un orquestador determinista, que es código de harness en lugar de un LLM, ejecuta el ciclo y hace cumplir la política. El modelo propone acciones y las llamadas de herramientas aprobadas se ejecutan en un entorno aislado a nivel de sistema operativo que restringe procesos, rutas de archivos y acceso a la red. El entorno aislado está siempre activo y falla en modo seguro: si no está disponible, el harness se desactiva a sí mismo en lugar de ejecutar comandos con los permisos del usuario. Las acciones que cruzan el límite del dispositivo, como la búsqueda web, conectores y la escalada a un modelo asesor en la nube más potente, ocurren solo cuando el usuario las habilita y aprueba. Antes de una llamada de asesor, un clasificador de PII marca la información confidencial y el usuario ve lo que se enviaría. El asesor recibe solo ese contexto aprobado y devuelve texto de guía, sin acceso a los archivos o herramientas del dispositivo.

En el extremo: Numbat

Los agentes de codificación en las computadoras portátiles de los desarrolladores se ejecutan durante horas con acceso al código fuente, credenciales y sistemas de producción. Numbat, nuestro conjunto de seguridad de agentes de código abierto, añade una capa independiente que se encuentra fuera de cualquier agente individual. Funciona con harnesses como Claude Code, Codex, OpenCode y Pi, bloquea acciones peligrosas antes de que se ejecutan, señala secuencias de varios pasos sospechosas como leer un secreto y luego enviar datos fuera, y conserva las líneas de tiempo de la sesión para su investigación. Numbat se ejecuta en miles de puntos finales de Perplexity junto con Bumblebee, nuestro escáner de cadena de suministro de código abierto. Computer revisa periódicamente sus hallazgos y propone reglas de detección mejoradas, y un humano aprueba cada cambio antes de que se lance.

Un trabajo para toda la industria

A medida que los agentes de IA se vuelven más capaces y su uso se generaliza, la ingeniería de seguridad debe seguir siendo central para su desarrollo e implementación. Los investigadores e ingenieros pueden basarse en principios establecidos, utilizar hallazgos del mundo real para refinar las defensas y probar salvaguardas en los entornos en los que operan los agentes. La seguridad es una disciplina de ingeniería continua que se desarrolla junto con la tecnología.

La ingeniería de seguridad para agentes es un trabajo para toda la industria. Ninguna empresa controla la pila completa en la que se ejecuta un agente. Los desarrolladores de modelos, los creadores de harnesses, los proveedores de entornos aislados y de tiempo de ejecución, los proveedores de nube y hardware, y los equipos de seguridad empresarial son propietarios de una capa. La seguridad del todo depende de que cada capa se mantenga firme cuando otra falla. Es por eso que construimos salvaguardas que funcionan en todos los harnesses de agentes y ofrecemos nuestras herramientas como código abierto. También es la razón por la cual divulgamos las debilidades que encontramos en otras plataformas y participamos en iniciativas como Open Secure AI Alliance.

Para trabajar con la comunidad en general en estos desafíos, Perplexity lanzó el Instituto de Inteligencia Segura en marzo de 2026 para estudiar la seguridad, la confiabilidad y la defensa práctica de los sistemas de IA de vanguardia (Perplexity). Perplexity actualmente colabora y/o financia a investigadores académicos en Stanford, CMU, Duke, Columbia, Ohio State y la Universidad de Virginia. También estamos realizando investigación intramuros para avanzar en la frontera de la investigación de seguridad de agentes, traducir esos avances en mejoras concretas en los sistemas de Perplexity y compartir conocimientos y recursos que ayuden a fortalecer el ecosistema de IA en general. Los agentes más seguros son algo que la industria puede diseñar. Tenemos la intención de seguir aportando nuestra parte y otros están invitados a construir con nosotros.