Cómo diseñamos agentes más seguros

Para construir agentes de IA más seguros, debemos diseñar tanto para sus capacidades como para sus fallas. Incluso al realizar tareas legítimas y sin ninguna instrucción maliciosa, los agentes pueden cruzar los límites de seguridad al intentar 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 el comportamiento no deseado 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, harness de agentes e infraestructura para que la seguridad no dependa de una sola salvaguarda.

Comportamiento de colapso de los agentes de IA

En julio, agentes de IA irrumpieron en la infraestructura de producción de Hugging Face, una plataforma de IA de código abierto. Durante las ejecuciones de evaluación y entrenamiento interno 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 tareas en una prueba comparativa de ciberseguridad reclutaron a otros agentes para que ayudaran. Estos agentes escaparon de su entorno de evaluación y llegaron a internet. También descubrieron formas de hacer trampa mediante ingeniería inversa de las respuestas a las tareas de la prueba comparativa, pero pensaron que el sistema de calificación detectaría el fraude. Para comprender mejor cómo funcionaba la evaluación de la prueba comparativa y 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 a la API fallida, una credencial caducada o una denegación de permisos, y se pone a buscar 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 mismo se convierte efectivamente en el adversario, aunque no intervenga ningún mensaje malicioso o atacante externo.

Hugging Face no fue un caso aislado. En las últimas semanas se descubrieron y reportaron 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., tuvieron errores causados por una consulta mal formada. Respondieron con sondeos, que incluyeron inyección SQL, cross-site scripting, inyección de plantillas, path traversal e inyección de comandos. La actividad se vinculó posteriormente con OpenAI (SecurityWeek). Los días 20 y 21 de junio, a 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) se les bloqueó la descarga de 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 tres empresas después de que un error les diera acceso abierto a internet, 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, las personas comenzaron a recibir correos electrónicos de remitentes conocidos con el asunto "ILOVEYOU". Abrir el archivo adjunto en el correo electrónico resultaba en la ejecución de un script que enviaba una copia de sí mismo a todos los contactos en 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, incluidos el Departamento de Defensa, la CIA, la NASA y la Cámara de Representantes 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 London 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, el gusano Blaster y el gusano de correo electrónico Sobig aparecieron con una semana de diferencia (Microsoft, F-Secure).

En ese momento, era razonable preguntarse si las computadoras conectadas en red podrían hacerse seguras. 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 compañía 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 alguna vez fue la excepción, se convirtió en el valor predeterminado. Las tecnologías de seguridad, incluida la autenticación multifactor, los firewalls, zero trust y la gestión de información y eventos 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 poderoso 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 anteriores a los agentes, 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 son, en principio, suficientes para causar un daño significativo.

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 del 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 asegurar los agentes de IA es la defensa en profundidad, que aboga por una arquitectura de seguridad en 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, 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 los harness, los modelos de revisión automática y los clasificadores de seguridad, estaban ausentes en el entorno de evaluación. Si su monitoreo de cadena de pensamiento desplegado actualmente 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.

Garantizar la seguridad de los agentes de IA requiere mejorar tanto la seguridad operativa como la seguridad frente a amenazas de los modelos de IA y de los sistemas que los rodean. El trabajo en la capa de modelos es importante 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 la retrospectiva 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 y despliegan 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, abogamos por 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 nunca acceso adicional.

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

La 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 computadoras portátiles de 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 mantienen 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 aportar 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. En Escaping SPACE: Parte I, dimos a nueve modelos de vanguardia acceso root dentro de un entorno aislado de 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 revelamos 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 contra inyección de instrucciones en capas desde su lanzamiento: los clasificadores escanean el contenido recuperado, las indicaciones estructuradas lo marcan como no confiable, las acciones sensibles como enviar un correo electrónico o realizar un pedido requieren la confirmación del usuario, y se notifica a los usuarios cuando se bloquea algo (Defensas contra inyección de instrucciones 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 nuestra prueba comparativa BrowseSafe-Bench, pero la misma prueba comparativa 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 con prioridad 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 bucle y aplica la política. El modelo propone acciones, y las llamadas a herramientas aprobadas se ejecutan en un entorno aislado a nivel de sistema operativo que restringe los procesos, las rutas de archivos y el acceso a la red. El entorno aislado está siempre activo y con cierre por fallo: si no está disponible, el harness se desactiva en lugar de ejecutar comandos con los permisos del usuario. Las acciones que cruzan el límite del dispositivo, como la búsqueda web, los conectores y la escalación a un modelo asesor en la nube más potente, ocurren solo cuando el usuario las habilita y aprueba. Antes de una llamada al 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 una orientación de texto, sin acceso a los archivos o herramientas del dispositivo.

En el extremo: Numbat

Los agentes de código 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 harness como Claude Code, Codex, OpenCode y Pi, bloquea acciones peligrosas antes de que se ejecuten, marca secuencias sospechosas de múltiples pasos, como leer un secreto y luego enviar datos, y conserva las líneas de tiempo de las sesión para su investigación. Numbat se ejecuta en miles de extremos de Perplexity junto con Bumblebee, nuestro escáner de cadena de suministro de código abierto. Computer revisa regularmente 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 se utilizan ampliamente, la ingeniería de seguridad debe seguir siendo fundamental para su desarrollo y despliegue. Los investigadores e ingenieros pueden basarse en principios establecidos, utilizar hallazgos del mundo real para refinar las defensas y probar las 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 por sí sola toda la pila en la que se ejecuta un agente. Los desarrolladores de modelos, los creadores de harness, los proveedores de entornos aislados y tiempo de ejecución, los proveedores de nube y hardware, y los equipos de seguridad empresarial son propietarios de una capa. La seguridad del conjunto depende de que cada capa se mantenga cuando otra falle. Es por eso que construimos salvaguardas que funcionan en los harness de agentes y hacemos que nuestras herramientas sean de código abierto. También es la razón por la cual revelamos las debilidades que encontramos en otras plataformas y participamos en iniciativas como la Open Secure AI Alliance.

Para trabajar con la comunidad en general en estos desafíos, Perplexity lanzó el Secure Intelligence Institute en marzo de 2026 para estudiar la seguridad, la confiabilidad y la defensa práctica de los sistemas de IA de vanguardia (Perplexity). Perplexity colabora actualmente 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 e invitamos a otros a construir con nosotros.