Como deseñamos axentes máis seguros

Para construír axentes de IA máis seguros, debemos deseñar tanto para as súas capacidades como para os seus fallos. Mesmo cando realizan tarefas lexítimas e sen ningunha instrución maliciosa, os axentes poden cruzar os límites de seguridade mentres intentan superar obstáculos.

Cremos que este é un problema de enxeñaría de seguridade, e a industria debería abordalo do mesmo xeito que abordou os gusanos de internet de principios da década de 2000. Os sistemas que rodean aos axentes deben limitar o que os axentes poden acceder, detectar comportamentos non desexados e conter os fallos cando se producen.

En Perplexity, colaboramos activamente con investigadores e profesionais para avanzar na enxeñaría de seguridade para os axentes de IA, e aplicamos múltiples capas de defensa nos nosos modelos, harnesses de axentes e infraestrutura para que a seguridade non dependa de ningunha salvagarda individual.

Comportamento de colapso dos axentes de IA

En xullo, os axentes de IA entraron na infraestrutura de produción da plataforma de IA de código aberto Hugging Face. Durante a avaliación interna de ciberseguridade e as probas de adestramento, os modelos de OpenAI descubriron unha forma de explotar o xestor de repositorios Artifactory para establecer un taboleiro de anuncios para comunicarse entre si, o que lles permitiu organizarse en enxames. Máis tarde, os axentes que non puideron avanzar nas tarefas nun punto de referencia de ciberseguridade recrutaron a outros axentes para que os axudasen. Estes axentes escaparon do seu contorno de avaliación e chegaron a internet. Tamén descubriron formas de facer trampa facendo a enxeñaría inversa das respostas ás tarefas do punto de referencia, pero pensaron que o sistema de cualificación detectaría as trampas. Para comprender mellor como funcionaba a avaliación do punto de referencia para atopar formas de evitar ser detectados como tramposos, acabaron comprometendo os sistemas de Hugging Face (Hugging Face; OpenAI).

O incidente é un claro exemplo dun modo de fallo que describimos cando fixemos de código aberto a Numbat en xullo: colapsos accidentais, un termo acuñado por investigadores de seguridade de Cornell Tech (arXiv). Un axente que persegue un obxectivo lexítimo atopa fricción, como un ficheiro que falta, unha chamada á API fallida, unha credencial caducada ou unha denegación de permisos, e busca unha solución alternativa. Ao facelo, pode cruzar os límites de seguridade mediante recoñecemento, escalada de privilexios, descubrimento de segredos ou exfiltración de datos. O axente en si convértese efectivamente no adversario, aínda que non estea involucrado ningún aviso malicioso ou atacante externo.

Hugging Face non foi un caso illado. Nas últimas semanas descubríronse e informouse de máis comportamentos de colapso de axentes. O 27 e 28 de maio, os axentes que intentaban recoller datos da Universidade de Iowa de Data USA, unha plataforma que ofrece acceso aberto aos datos do goberno dos EE. UU., atoparon erros causados dunha consulta malformada. Responderon con sondaxes, incluíndo inxección de SQL, script en sitios cruzados, inxección de modelos, percorrecido de rutas e inxección de comandos. A actividade vinculouse posteriormente a OpenAI (SecurityWeek). O 20 e 21 de xuño, os axentes de OpenAI que intentaban obter os custos gobernamentais por persoa para unha categoría de medicamentos en áreas locais de Victoria do Instituto Australiano de Saúde e Benestar (AIHW) foron bloqueados na descargas dun ficheiro. En resposta, os axentes descargaron o ficheiro, que xa era público, do servidor de preprodución de AIHW, eludindo no proceso as proteccións anti-bot do sitio (SecurityWeek).

O patrón non se limita a un único laboratorio. Durante as probas de ciberseguridade, os modelos de Anthropic vulneraron tres empresas despois de que un erro lles dese acceso aberto a internet, o Gemini de Google adiviniou as credenciais de tres sitios web e un modelo de Meta explotou un servizo de terceiros (Reuters).

Aprender da historia: A era dos gusanos de internet

Estes incidentes lembran a era dos gusanos de internet de hai aproximadamente un cuarto de século. A principios da década de 2000, internet creceu moito máis rápido que as prácticas de seguridade que o rodeaban. Vimos unha onda de virus e gusanos, con consecuencias moito máis graves que as que estamos a ver agora cos axentes de IA en colapso.

O 4 de maio de 2000, a xente comezou a recibir correos electrónicos de remitentes coñecidos co asunto "ILOVEYOU". Abrir o anexo do correo electrónico tivo como resultado a execución dun script que enviaba unha copia de si mesmo a todos os contactos da axenda de enderezos de Outlook da vítima. Ás 18:00 horas dese día, o Centro de Coordinación CERT recibira informes que implicaban a máis de 420.000 servidores de internet (Informe GAO dos EE. UU.). Segundo os informes, o virus penetrou en polo menos 14 axencias federais, incluíndo o Departamento de Defensa, a CIA, a NASA e a Cámara e o Senado (Informe GAO dos EE. UU.). Tamén pechou os servidores de correo electrónico no Pentágono e no Parlamento británico (Wired). O xigante asegurador Lloyd's de London fixo unha estimación inicial de que o virus custaría máis de 15 mil millóns de dólares en danos e perda de produtividade (Audiencia do Comité da Cámara dos EE. UU.). Computer Economics estimou posteriormente 8,75 mil millóns de dólares en danos en todo o mundo (Information Week).

A continuación viñeron os gusanos que non precisaban ningún clic humano. O 19 de xullo de 2001, o gusano Code-Red infectou máis de 359.000 ordenadores en menos de 14 horas (CAIDA). O 25 de xaneiro de 2003, SQL Slammer duplicou o seu tamaño cada 8,5 segundos e infectou a máis do 90% dos servidores de internet vulnerables a el nun prazo de 10 minutos (CAIDA), explotando un buraco para o cal Microsoft lanzara un parche seis meses antes (CNET). En agosto de 2003, o gusano Blaster e o gusano de correo electrónico Sobig aparecéronse cunha semana de diferenza (Microsoft, F-Secure).

Nese momento, era razoable preguntarse se os ordenadores conectados en rede podían facerse seguros. Seis días despois do virus ILOVEYOU, un subcomité da Cámara dos EE. UU. celebrou unha audiencia sobre o tema. Moitos expertos en seguridade pediron unha lexislación que fixese que as empresas de software fosen responsables dos danos causados polas fendas nos seus produtos. Washington tomou un camiño diferente. A Estratexia Nacional para Protexer o Ciberespazo afirmou que "a regulación federal non se converterá nun medio principal para asegurar o ciberespazo". Advertiu de que os mandos amplos poderían crear un "enfoque de denominador común máis baixo para a ciberseguridade" (CISA).

A industria respondeu coa enxeñaría. Once días despois de ILOVEYOU, Microsoft anunciou unha actualización de Outlook que bloqueaba os anexos executables. En xaneiro de 2002, a empresa fixo da seguridade unha máxima prioridade (Seattle Times). Os parches automáticos, os valores predeterminados seguros, os programas de recompensas por erros e a divulgación coordinada convertéronse en prácticas estándar. En 2008, Chrome comezou a executar contido web nun contorno illado que "limita o que un atacante pode facer despois de explotar un erro" (Chromium Blog). O cifrado, antes a excepción, pasou a ser o predeterminado. As tecnoloxías de seguridade, incluíndo a autenticación multifactor, os devanceiros de lume, a confianza cero e a xestión de eventos e información de seguridade (SIEM), fixéronse moi comúns. Prevese que as organizacións de todo o mundo gasten uns 240 mil millóns de dólares en 2026 en seguridade da información (Gartner). Os gusanos nunca desapareceron por completo, pero a era dos brotes rutineiros en todo internet desvanecerse. Ao mesmo tempo, internet, en gran medida libre de regulación, converteuse nun potente motor de innovación e crecemento económico durante as dúas décadas seguintes.

Enxeñaría de seguridade para axentes de IA

Os incidentes recentes plantexaron preguntas lexítimas sobre a gobernanza dos axentes. Os mecanismos de seguridade existentes desenvolvéronse para contornas informáticas pre-axente caracterizadas por un comportamento de software altamente limitado e en gran medida determinista. Os mecanismos de control de acceso, en particular, están deseñados principalmente arredor dos usuarios humanos e adoitan outorgarlles amplos privilexios que son, en principio, suficientes para causar danos significativos.

Este deseño baséase en varias suposicións: a maioría dos usuarios actúan de boa fe; os actores maliciosos poden ser deterrentes mediante a auditoría e as consecuencias do mundo real; e os humanos toman accións, xa sexan correctas ou erróneas, a un ritmo relativamente limitado. A aplicación destes mecanismos de seguridade aos axentes require ter en conta as diferenzas entre o comportamento humano e o do axente. Como escribimos na nosa resposta á solicitude de información do NIST sobre a seguridade dos axentes de IA, os axentes de IA desafían estas suposicións. Poden exercer privilexios e tomar accións á velocidade da máquina, non se ven deterrentes polas consecuencias do mundo real e poden tomar accións que están tecnicamente permitidas pero que un usuario humano típico raramente tomaría.

Responder a esas preguntas require enxeñaría de seguridade. Coñecemos os principios de seguridade para construír sistemas que manteñan os riscos baixo control cando os compoñentes individuais funcionan mal. Pero debemos asegurarnos de que estes principios se apliquen ao deseñar as contornas para adestrar, probar e usar axentes de IA.

O principio de seguridade da defensa en profundidade

Sen dúbida, o principio de seguridade máis importante que se debe aplicar para protexer os axentes de IA é a defensa en profundidade, que avoga por unha arquitectura de seguridade en capas, onde se empregan medidas defensivas múltiples, variadas e redundantes para protexer os recursos do sistema. Ningunha salvagarda por si mesma é perfecta. As persoas poden caer en ataques de enxeñaría social e revelar as súas credenciais de inicio de sesión, descóbrense e explótanse vulnerabilidades de software de día cero, e a detección de intrusións pasa por alto novas variantes de ataque. A defensa en profundidade acepta iso e apila varias capas independentes de defensa. No caso de que se eluda unha capa defensiva, outras capas permanecen no seu lugar para combater ou detectar a intrusión.

O incidente de Hugging Face mostra por que importa a defensa en profundidade. O informe retrospectivo de OpenAI informa de que as salvagardas automatizadas empregadas nos seus sistemas de produción, incluíndo harnesses, modelos de revisión automática e clasificadores de seguridade, estiveron ausentes do contorno de avaliación. Se o seu monitoramento de cadea de pensamento implementado actualmente estivese executándose nesas avaliacións, tería detectado a actividade inicial e avisado ao equipo de seguridade máis dun día antes da brecha (OpenAI). As capas que poderían detectar o problema existían. Simplemente non estaban todas no mesmo lugar ao mesmo tempo.

Protexer os axentes de IA require mellorar tanto a seguridade como a fiabilidade dos modelos de IA e dos sistemas que os rodean. O traballo na capa de modelo importa, e está dando resultados. Os primeiros LLM eran facilmente manipulados por instrucións inxectadas, mentres que os modelos actuais son substancialmente mellores para recoñecelas e rexeitalas. Os desenvolvedores de modelos tamén adestran modelos para un comportamento máis seguro e, como describe a retrospectiva de OpenAI, supervisan os rastros de razoamento en busca de signos de comportamento problemático. Pero as defensas a nivel de modelo son só unha parte da solución. Os sistemas nos que se adestran, proban e implementan os axentes tamén deben ser deseñados para a seguridade e a contención. A seguridade a nivel de modelo reduce a probabilidade de que un axente se desvíe; a seguridade a nivel de sistema limita o dano cando o fai.

Ampliar

Regras de deseño para salvagardas redundantes

A defensa en profundidade require salvagardas redundantes. Para os axentes, avogamos por aplicala con tres regras de deseño:

1. Independencia. Cada capa debería fallar por motivos independentes. Dous controis que comparten a mesma suposición poden ser superados polo mesmo ataque. Os monitores e os puntos de aplicación deben estar fóra do alcance do axente.
2. Aplicación debaixo do axente. Polo menos unha capa debe ser determinista: código convencional e verificable que bloquee as accións prohibidas sen importar o que produza o modelo. Unha salvagarda que o axente poida rexeitar invocar ou reconfigurar non é unha salvagarda.
3. Os sinais só poden reducir a autoridade. A detección debería desencadear respostas que reduzan o que o axente pode facer, como pausar, revogar credenciais, cortar o acceso á rede ou finalizar a sesión. Ningún sinal de risco debe conceder nunca acceso adicional.

Compartimos estes principios cos nosos socios na Open Secure AI Alliance, incluíndo NVIDIA, que argumentou que o harness guía o que un axente tenta mentres a infraestrutura controla o que pode facer (NVIDIA).

A defensa en profundidade nos produtos de Perplexity

Perplexity executa axentes en catro tipos de contornas: na nube a través da nosa plataforma de axentes Computer, no navegador a través de Comet, nos dispositivos dos usuarios a través de Computer portátil e nos portátiles dos empregados, onde os nosos enxeñeiros usan axentes de codificación de terceiros. Cada contorna ten os seus propios riscos e cada unha recibe varias capas de protección.

Na nube: Computer e SPACE

Cada tarefa de Computer se executa en SPACE, a nosa plataforma de contorno illado, que trata o axente como non confiable de forma predeterminada. Cada tarefa obtén a súa propia microVM, as credenciais mantéñense fóra do contorno illado e só se inxectan cando é necesario, o tráfico saínte contrólasse fóra do convidado e as instantáneas permítennos reverter cambios destrutivos (Making SPACE). Os clientes empresariais tamén poden achegar as súas propias chaves de cifrado. Revogar unha chave fai que os datos protexidos sexan ilexibles, e o axente non pode anular esa decisión.

Tamén probamos se estas capas se manteñen. En Escaping SPACE: Part I, démoslles a nove modelos de fronteira acceso de superusuario dentro dun contorno illado SPACE e pedímoslles que escapasen. Ningún escapou da máquina virtual (VM), pero algúns atoparon formas de saltarse a política de rede cando se permitiu o acceso parcial á rede. Corriximos eses ocos, confirmamos as correccións nunha nova proba e divulgamos debilidades similares que atopamos en oito de cada 10 outras plataformas de contorno illado aos seus provedores.

No navegador: Comet e BrowseSafe

Comet utilizou unha defensa de inxección de avisos en capas desde o seu lanzamento: os clasificadores examinan o contido recuperado, os avisos estruturados márcano como non confiable, as accións sensibles como enviar un correo electrónico ou facer un pedido requiren a confirmación do usuario, e infórmase aos usuarios cando algo está bloqueado (defensas de inxección de avisos de Comet). BrowseSafe, o modelo de detección de código aberto detrás da primeira capa, supera aos modelos de fronteira no noso punto de referencia BrowseSafe-Bench, aínda que o mesmo punto de referencia mostra que ningún detector é infalible, razón pola cal a detección nunca é a única capa (investigación de BrowseSafe). Computer herda estas defensas, que foron auditadas por Trail of Bits (Perplexity).

No dispositivo: Computer portátil

Computer portátil é un axente que prioriza o ámbito local: o modelo, o harness, a conversa e a traxectoria permanecen na máquina do usuario por defecto. Un orquestrador determinista, que é código de harness en lugar dun LLM, executa o bucle e aplica a política. O modelo propón accións e as chamadas de ferramentas aprobadas executaranse nun contorno illado a nivel de sistema operativo que restrinxe os procesos, as rutas de ficheiros e o acceso á rede. O contorno illado está sempre activo e falla bloqueado: se non está dispoñible, o harness desbálase en vez de executar comandos cos permisos do usuario. As accións que cruzan o límite do dispositivo, como a busca web, os conectores e a escalada a un modelo asesor de nube máis forte, prodúcense só cando o usuario as habilita e as aproba. Antes dunha chamada de asesor, un clasificador PII sinaliza información sensible e o usuario ve o que se enviaría. O asesor recibe só ese contexto aprobado e devolve orientación en texto, sen acceso aos ficheiros ou ferramentas do dispositivo.

No punto de final: Numbat

Os axentes de codificación nos portátiles dos desenvolvedores funcionan durante horas con acceso ao código fonte, credenciais e sistemas de produción. Numbat, a nosa suite de seguridade de axentes de código aberto, engade unha capa independente que se atopa fóra de calquera axente individual. Funciona con harnesses como Claude Code, Codex, OpenCode e Pi, bloquea accións perigosas antes de que se executen, sinaliza secuencias sospeitosas de varios pasos, como ler un segredo e despois enviar datos fóra, e conserva as liñas de tempo da sesión para a súa investigación. Numbat se executa en miles de puntos de final de Perplexity xunto con Bumblebee, o noso escáner de cadea de subministración de código aberto. Computer revisa regularmente os seus descubrimentos e propón regras de detección melloradas, e un ser humano aproba cada cambio antes de que se lance.

Un traballo para toda a industria

A medida que os axentes de IA se volven máis capaces e amplamente utilizados, a enxeñaría de seguridade debe seguir sendo fundamental para o seu desenvolvemento e implementación. Os investigadores e enxeñeiros poden basearse en principios establecidos, utilizar descubrimentos do mundo real para refinar as defensas e probar salvagardas nas contornas nas que operan os axentes. A seguridade é unha disciplina de enxeñaría en curso que se desenvolve xunto coa tecnoloxía.

A enxeñaría de seguridade para axentes é un traballo para toda a industria. Ningunha empresa controla toda a pila sobre a que se executa un axente. Os desenvolvedores de modelos, os creadores de harnesses, os provedores de contornas illadas e de tempo de execución, os provedores de nube e hardware e os equipos de seguridade empresarial posúen cada un unha capa. A seguridade do conxunto depende de que cada capa se manteña cando outra falla. É por iso que construímos salvagardas que funcionan en harnesses de axentes e abrimos o código das nosas ferramentas. Tamén é o motivo polo que divulgamos as debilidades que atopamos noutras plataformas e participamos en iniciativas como a Open Secure AI Alliance.

Para traballar coa comunidade en xeral nestes desafíos, Perplexity puxo en marcha o Secure Intelligence Institute en marzo de 2026 para estudar a seguridade, a fiabilidade e a defensa práctica dos sistemas de IA de vangarda (Perplexity). Perplexity colabora actualmente e/ou financia investigadores académicos en Stanford, CMU, Duke, Columbia, Ohio State e a Universidade de Virxinia. Tamén estamos a realizar investigacións intramurais para avanzar na fronteira da investigación de seguridade de axentes, traducir eses avances en melloras concretas nos sistemas de Perplexity e compartir coñecementos e recursos que axuden a fortalecer o ecosistema de IA máis amplo. Os axentes máis seguros son algo que a industria pode deseñar. Temos a intención de seguir facendo a nosa parte e convidamos a outros a construír connosco.