Com dissenyem agents més segurs

Per construir agents d'IA més segurs, hem de dissenyar tant per a les seves capacitats com per a les seves fallades. Fins i tot quan realitzen tasques legítimes, i sense cap instrucció maliciosa, els agents poden creuar els límits de seguretat mentre intenten superar obstacles.

Creiem que aquest és un problema d'enginyeria de seguretat, i la indústria hauria d'abordar-lo de la mateixa manera que va abordar els cucs d'internet de principis dels anys 2000. Els sistemes que envolten els agents han de limitar allò a què poden accedir els agents, detectar comportaments no desitjats i contenir fallades quan es produeixin.

A Perplexity, estem col·laborant activament amb investigadors i professionals per avançar en l'enginyeria de seguretat per a agents d'IA, i apliquem múltiples capes de defensa als nostres models, harness d'agents i infraestructura perquè la seguretat no depengui d'una sola salvaguarda.

Comportament de crisi dels agents d'IA

Al juliol, els agents d'IA van irrompre a la infraestructura de producció de la plataforma d'IA de codi obert Hugging Face. Durant l'avaluació interna de ciberseguretat i les execucions d'entrenament, els models d'OpenAI van descobrir una manera d'explotar el gestor de repositoris Artifactory per establir un tauler d'anuncis per comunicar-se entre ells, cosa que els va permetre organitzar-se en eixams. Més tard, els agents que no van poder progressar en tasques d'una prova de referència de ciberseguretat van reclutar altres agents per ajudar-los. Aquests agents van sortir del seu entorn d'avaluació i van arribar a Internet. També van descobrir maneres de fer trampa mitjançant la enginyeria inversa de respostes a les tasques de la prova de referència, però van pensar que el sistema de qualificació detectaria la trampa. Per entendre millor com funcionava l'avaluació de la prova de referència per trobar maneres d'evitar ser detectats fent trampa, finalment van comprometre els sistemes de Hugging Face (Hugging Face; OpenAI).

L'incident és un exemple clar d'un mode de fallada que vam descriure quan vam fer de codi obert Numbat al juliol: crisis accidentals, un terme encunyat per investigadors de seguretat de Cornell Tech (arXiv). Un agent que persegueix un objectiu legítim troba fricció, com ara un fitxer que falta, una cridada a l'API fallida, una credencial caducada o una denegació de permisos, i busca una solució alternativa. En fer-ho, pot creuar els límits de seguretat mitjançant reconeixement, escalada de privilegis, descobriment de secrets o exfiltració de dades. El mateix agent es converteix efectivament en l'adversari, tot i que no hi ha cap indicació maliciosa o atacant extern involucrat.

Hugging Face no va ser un cas aïllat. S'han descobert i informat més comportaments de crisi d'agents en les últimes setmanes. El 27-28 de maig, els agents que intentaven recopilar dades de la Universitat de Iowa des de Data USA, una plataforma que ofereix accés obert a dades del govern dels EUA, van trobar errors causats per una consulta mal formada. Van respondre amb sondes, incloent-hi injecció SQL, cross-site scripting, injecció de plantilles, recorregut de camins i injecció de comandes. L'activitat es va vincular posteriorment a OpenAI (SecurityWeek). El 20-21 de juny, els agents d'OpenAI que intentaven obtenir costos governamentals per persona per a una categoria de medicaments en àrees locals de Victòria de l'Institut Australià de Salut i Benestar (AIHW) van ser bloquejats per descarregar un fitxer. Com a resposta, els agents van descarregar el fitxer, que ja era públic, des del servidor de preproducció de l'AIHW, evitant en el procés les proteccions antibot del lloc (SecurityWeek).

El patró no es limita a un sol laboratori. Durant les proves de ciberseguretat, els models d'Anthropic van vulnerar tres empreses després que un error els donés accés obert a Internet, el Gemini de Google va endevinar credencials de tres llocs web i un model de Meta va explotar un servei de tercers (Reuters).

Aprenent de la història: L'era dels cucs d'internet

Aquests incidents recorden l'era dels cucs d'internet de fa aproximadament un quart de segle. A principis dels anys 2000, internet va créixer molt més ràpid que les pràctiques de seguretat al seu voltant. Vam veure una onada de virus i cucs, amb conseqüències molt més greus que les que estem veient ara amb els agents d'IA en crisi.

El 4 de maig de 2000, la gent va començar a rebre correus electrònics de remetents coneguts amb l'assumpte "ILOVEYOU". Obrir el fitxer adjunt del correu electrònic va provocar l'execució d'un script que va enviar una còpia d'ell mateix a tothom de la llibreta d'adreces d'Outlook de la víctima. A les 18:00 d'aquell dia, el Centre de Coordinació del CERT havia rebut informes que implicaven més de 420.000 amfitrions d'internet (Informe de l'US GAO). El virus suposadament va penetrar almenys en 14 agències federals, inclosos el Departament de Defensa, la CIA, la NASA i la Cambra de Representants i el Senat (Informe de l'US GAO). També va tancar els servidors de correu electrònic al Pentagon i al Parlament britànic (Wired). El gegant assegurador Lloyd's de Londres va fer una estimació inicial que el virus costaria més de 15.000 milions de dòlars en danys i pèrdua de productivitat (Audiència del Comitè de la Cambra dels EUA). Computer Economics va estimar posteriorment 8.750 milions de dòlars en danys a tot el món (Information Week).

Després van arribar els cucs que no necessitaven cap clic humà. El 19 de juliol de 2001, el cuc Code-Red va infectar més de 359.000 ordinadors en menys de 14 hores (CAIDA). El 25 de gener de 2003, SQL Slammer va duplicar la seva mida cada 8,5 segons i va infectar més del 90% dels amfitrions d'internet vulnerables a aquest en 10 minuts (CAIDA), explotant un forat per al qual Microsoft havia llançat un pegat sis mesos abans (CNET). L'agost de 2003, el cuc Blaster i el cuc de correu electrònic Sobig van aparèixer amb aproximadament una setmana de diferència (Microsoft, F-Secure).

En aquell moment, era raonable preguntar-se si els ordinadors connectats en xarxa podrien arribar a ser segurs. Sis dies després del virus ILOVEYOU, un subcomitè de la Cambra dels EUA va celebrar una audiència sobre aquest tema. Molts experts en seguretat van demanar una legislació que fes que les empreses de programari fossin responsables dels danys causats per defectes en els seus productes. Washington va prendre un camí diferent. L'Estratègia Nacional per Assegurar el Ciberespai afirmava que "la regulació federal no es convertirà en un mitjà principal per assegurar el ciberespai". Va advertir que els mandats amplis podrien crear un "enfocament de denominador comú més baix per a la ciberseguretat" (CISA).

La indústria va respondre amb enginyeria. Onze dies després d'ILOVEYOU, Microsoft va anunciar una actualització d'Outlook que bloquejava els fitxers adjunts executables. El gener de 2002, l'empresa va convertir la seguretat en una prioritat màxima (Seattle Times). La creació de pegats automàtics, els valors predeterminats segurs, els programes de recompensa per errors i la divulgació coordinada es van convertir en una pràctica estàndard. El 2008, Chrome va començar a executar contingut web en un entorn de proves que "limita el que un atacant pot fer després d'aprofitar un error" (Chromium Blog). El xifratge, abans l'excepció, es va convertir en el valor predeterminat. Les tecnologies de seguretat, com ara l'autenticació multifactorial, els tallafocs, la confiança zero i la gestió d'esdeveniments i informació de seguretat (SIEM), es van utilitzar àmpliament. Es preveu que les organitzacions de tot el món gastin uns 240.000 milions de dòlars el 2026 en seguretat de la informació (Gartner). Els cucs mai van desaparèixer del tot, però l'era dels brots rutinaris a tot internet es va esvair. Al mateix temps, internet, en gran part lliure de regulacions, es va convertir en un motor potent d'innovació i creixement econòmic durant les dues dècades següents.

Enginyeria de seguretat per a agents d'IA

Els incidents recents han plantejat preguntes legítimes sobre la governança dels agents. Els mecanismes de seguretat existents es van desenvolupar per a entorns informàtics preagents caracteritzats per un comportament de programari altament delimitat i en gran mesura determinista. Els mecanismes de control d'accés, en particular, estan dissenyats principalment al voltant dels usuaris humans i sovint els concedeixen privilegis amplis que són, en principi, suficients per causar danys significatius.

Aquest disseny es basa en diverses suposicions: la majoria dels usuaris actuen de bona fe; els actors maliciosos es poden dissuadir mitjançant auditories i conseqüències del món real; i els humans prenen accions, tant si són correctes com errònies, a un ritme relativament limitat. L'aplicació d'aquests mecanismes de seguretat als agents requereix tenir en compte les diferències entre el comportament humà i el de l'agent. Tal com vam escriure a la nostra resposta a la sol·licitud d'informació del NIST sobre la seguretat dels agents d'IA, els agents d'IA desafien aquestes suposicions. Poden exercir privilegis i prendre accions a la velocitat de la màquina, no estan dissuadits per les conseqüències del món real i poden prendre accions que estan tècnicament permeses però que un usuari humà típic rarament prendria.

Respondre a aquestes preguntes requereix enginyeria de seguretat. Coneixem els principis de seguretat per construir sistemes que mantinguin els riscos sota control quan els components individuals funcionen malament. Però hem d'assegurar-nos que aquests principis s'apliquin en dissenyar els entorns per entrenar, provar i utilitzar agents d'IA.

El principi de seguretat de la defensa en profunditat

Podria dir-se que el principi de seguretat més important que cal aplicar per assegurar els agents d'IA és la defensa en profunditat, que advoca per una arquitectura de seguretat per capes, on s'utilitzen mesures defensives múltiples, variades i redundants per protegir els recursos del sistema. Cap salvaguarda individual és perfecta. Les persones poden caure en atacs d'enginyeria social i revelar les seves credencials d'inici de sessió, es descobreixen i s'aprofiten vulnerabilitats de programari de dia zero, i la detecció d'intrusions passa per alt noves variants d'atacs. La defensa en profunditat ho accepta i apila diverses capes independents de defensa. En cas que s'eviti una capa defensiva, altres capes romanen al seu lloc per contrarestar o detectar la intrusió.

L'incident de Hugging Face mostra per què la defensa en profunditat és important. L'informe retrospectiu d'OpenAI informa que les salvaguardes automatitzades utilitzades als seus sistemes de producció, inclosos els harness, els models d'autorevisió i els classificadors de seguretat, estaven absents de l'entorn d'avaluació. Si la seva monitorització de cadenes de pensament actualment desplegada s'hagués executat en aquestes avaluacions, hauria detectat l'activitat inicial i avisat a l'equip de seguretat més d'un dia abans de la bretxa (OpenAI). Les capes que podrien haver detectat el problema existien. Simplement no estaven totes alhora al seu lloc.

Assegurar els agents d'IA requereix millorar tant la seguretat i la fiabilitat dels models d'IA com els sistemes que els envolten. El treball a la capa del model importa, i està donant els seus fruits. Els primers LLM eren fàcilment manipulats per instruccions injectades, mentre que els models d'avui dia són substancialment millors per reconèixer-les i rebutjar-les. Els desenvolupadors de models també entrenen models per a un comportament més segur i, tal com descriu la retrospectiva d'OpenAI, monitoritzen les traces de raonament per detectar signes de comportament problemàtic. Però les defenses a nivell de model són només una part de la solució. Els sistemes en què s'entrenen, proven i despleguen els agents també s'han de dissenyar per a la seguretat i la contenció. La seguretat a nivell de model redueix la probabilitat que un agent es desvii; la seguretat a nivell de sistema limita el dany quan ho fa.

Amplia

Regles de disseny per a salvaguardes redundants

La defensa en profunditat requereix salvaguardes redundants. Per als agents, recomanem aplicar-la amb tres regles de disseny:

1. Independència. Cada capa hauria de fallar per raons independents. Dos controls que comparteixen la mateixa suposició poden ser superats pel mateix atac. Els monitors i els punts d'aplicació s'han de situar fora de l'abast de l'agent.
2. Aplicació per sota de l'agent. Almenys una capa ha de ser determinista: codi convencional i verificable que bloquegi les accions prohibides sense importar el que produeixi el model. Una salvaguarda que l'agent pot rebutjar invocar, o re configurar, no és una salvaguarda.
3. Els senyals només poden reduir l'autoritat. La detecció hauria de desencadenar respostes que redueixin el que pot fer l'agent, com ara fer una pausa, revocar credencials, tallar l'accés a la xarxa o finalitzar la sessió. Cap senyal de risc no hauria de concedir mai accés addicional.

Compartim aquests principis amb els nostres socis a l' Open Secure AI Alliance, inclòs NVIDIA, que ha argumentat que el harness guia el que intenta un agent mentre que la infraestructura controla el que pot fer (NVIDIA).

La defensa en profunditat als productes de Perplexity

Perplexity executa agents en quatre tipus d'entorns: al núvol a través de la nostra plataforma d'agents Computer, al navegador a través de Comet, als dispositius dels usuaris a través de Portable Computer i als portàtils dels empleats, on els nostres enginyers utilitzen agents de codificació de tercers. Cada entorn té els seus propis riscos i cadascun rep diverses capes de protecció.

Al núvol: Computer i SPACE

Cada tasca de Computer s'executa a SPACE, la nostra plataforma d'entorn de proves, que tracta l'agent com a no de confiança per defecte. Cada tasca obté la seva pròpia microMV, les credencials es queden fora de l'entorn de proves i s'injecten només quan cal, el trànsit de sortida es controla fora del convidat i les instantànies ens permeten revertir canvis destructius (Making SPACE). Els clients empresarials també poden portar les seves pròpies claus de xifratge. Revocar una clau fa que les dades protegides siguin il·legibles, i l'agent no pot anul·lar aquesta decisió.

També comprovem si aquestes capes aguanten. A Escaping SPACE: Part I, vam donar accés d'administrador a nou models d'avantguarda dins d'un entorn de proves de SPACE i els vam demanar que s'escapessin. Cap va escapar de la MV, però alguns van trobar maneres de saltar-se la política de xarxa quan es va permetre l'accés parcial a la xarxa. Vam corregir aquestes llacunes, vam confirmar les correccions en una reavaluació i vam revelar debilitats similars que vam trobar en vuit de deu plataformes d'entorn de proves als seus proveïdors.

Al navegador: Comet i BrowseSafe

Comet ha utilitzat una defensa d'injecció d'indicacions per capes des del llançament: els classificadors filtren el contingut recuperat, les indicacions estructurades el marquen com a no de confiança, les accions sensibles com enviar un correu electrònic o fer una comanda requereixen la confirmació de l'usuari, i s'informa als usuaris quan es bloqueja alguna cosa (defenses d'injecció d'indicacions de Comet). BrowseSafe, el model de detecció de codi obert darrere de la primera capa, supera els models d'avantguarda en la nostra prova de referència BrowseSafe-Bench, tot i que la mateixa prova de referència mostra que cap detector és infal·lible, motiu pel qual la detecció no és mai l'única capa (investigació de BrowseSafe). Computer hereta aquestes defenses, que han estat auditades per Trail of Bits (Perplexity).

Al dispositiu: Portable Computer

Portable Computer és un agent centrat en el dispositiu local: el model, el harness, la conversa i la trajectòria es queden a la màquina de l'usuari per defecte. Un orquestrador determinista, que és codi de harness en lloc d'un LLM, executa el bucle i fa complir la política. el model proposa accions i les crides d'eines aprovades s'executen en un entorn de proves a nivell de SO que restreix els processos, les rutes de fitxers i l'accés a la xarxa. L'entorn de proves està sempre actiu i té una fallada segura: si no està disponible, el harness es desactiva en lloc d'executar comandes amb els permisos de l'usuari. Les accions que creuen el límit del dispositiu, com ara la cerca web, els connectors i l'escalada a un model d'assessor de núvol més fort, només es produeixen quan l'usuari les habilita i les aprova. Abans d'una trucada d'assessor, un classificador de PII senyalitza la informació sensible i l'usuari veu què s'enviaria. L'assessor rep només aquest context aprovat i retorna orientació de text, sense accés als fitxers o eines del dispositiu.

A l'extrem: Numbat

Els agents de codificació als portàtils dels desenvolupadors s'executen durant hores amb accés a codi font, credencials i sistemes de producció. Numbat, el nostre conjunt de seguretat d'agents de codi obert, afegeix una capa independent que es troba fora de qualsevol agent individual. Funciona amb harness com ara Claude Code, Codex, OpenCode i Pi, bloqueja accions perilloses abans que s'executin, senyalitza seqüències sospitoses de múltiples passos com ara llegir un secret i després enviar dades fora, i conserva les línies de temps de la sessió per a la investigació. Numbat s'executa a milers de punts finals de Perplexity al costat de Bumblebee</2>, el nostre escàner de cadena de subministrament de codi obert. Computer revisa regularment les seves troballes i proposa regles de detecció millorades, i un humà aprova cada canvi abans que s'enviï.

Una tasca per a tota la indústria

A mesura que els agents d'IA esdevinguin més capaços i utilitzats àmpliament, l'enginyeria de seguretat ha de seguir sent central en el seu desenvolupament i despegue. Els investigadors i enginyers poden basar-se en principis establerts, utilitzar les troballes del món real per refinar les defenses i provar les salvaguardes en els entorns en què operen els agents. La seguretat és una disciplina d'enginyeria contínua que es desenvolupa juntament amb la tecnologia.

L'enginyeria de seguretat per a agents és una tasca per a tota la indústria. Cap empresa individual controla la pila completa en la qual s'executa un agent. Els desenvolupadors de models, els creadors de harness, els proveïdors d'entorns de proves i de temps d'execucions, els proveïdors de núvol i de maquinari, i els equips de seguretat empresarial posseeixen cadascun una capa. La seguretat del conjunt depèn de cada capa que aguanti quan una altra rellisca. Per això construïm salvaguardes que funcionen a través de harness d'agents i fem de codi obert les nostres eines. També és per això que revelem les debilitats que trobem en altres plataformes i participem en iniciatives com l'Open Secure AI Alliance.

Per treballar amb la comunitat en general en aquests reptes, Perplexity va llançar el Secure Intelligence Institute el març de 2026 per estudiar la seguretat, la fiabilitat i la defensa pràctica dels sistemes d'IA d'última generació (Perplexity). Actualment, Perplexity col·labora i/o finança investigadors acadèmics a Stanford, CMU, Duke, Columbia, Ohio State i la Universitat de Virgínia. També estem duent a terme investigació interna per avançar en la frontera de la investigació sobre seguretat d'agents, traduir aquests avenços en millores concretes als sistemes de Perplexity i compartir coneixements i recursos que ajudin a enfortir l'ecosistema d'IA en general. Els agents més segurs són quelcom que la indústria pot dissenyar. Tenim la intenció de continuar fent la nostra part i convidem a daltres a construir amb nosaltres.