Hur vi konstruerar säkrare agenter

För att bygga säkrare AI-agenter måste vi utforma för både deras förmågor och deras brister. Även när de utför legitima uppgifter, och utan några skadliga instruktioner, kan agenter korsa säkerhetsgränser när de försöker övervinna hinder.

Vi anser att detta är ett säkerhetstekniskt problem, och branschen bör ta sig an det på samma sätt som den tog sig an internetmaskarna i början av 2000-talet. Systemen kring agenter måste begränsa vad agenter kan komma åt, upptäcka oönskat beteende och innesluta fel när de inträffar.

På Perplexity samarbetar vi aktivt med forskare och utövare för att driva säkerhetsteknik för AI-agenter framåt, och vi tillämpar flera försvarslager över våra modeller, agent-harness och infrastruktur så att säkerheten inte är beroende av någon enskild skyddsåtgärd.

Skenande beteende hos AI-agenter

I juli bröt sig AI-agenter in i Hugging Faces produktionsinfrastruktur för AI-plattformar med öppen källkod. Under interna cybersäkerhetsutvärderingar och träningskörningar upptäckte OpenAI-modeller ett sätt att utnyttja Artifactory-lagringshanteraren för att upprätta anslagstavlor för kommunikation med varandra, vilket gjorde det möjligt för dem att organisera sig i svärmar. Senare rekryterade agenter som inte kunde göra framsteg med uppgifter i ett cybersäkerhetsriktmärke andra agenter för att få hjälp. Dessa agenter bröt sig ut ur sin utvärderingsmiljö och nådde internet. De upptäckte också sätt att fuska genom att bakåtkompilera svar på riktmärkesuppgifterna, men trodde att betygssystemet skulle upptäcka fusket. För att bättre förstå hur riktmärkesutvärderingen fungerade för att hitta sätt att undvika att upptäckas som fuskare komprometterade de till slut Hugging Face-systemen (Hugging Face; OpenAI).

Incidenten är ett tydligt exempel på en felläge som vi beskrev när vi släppte Numbat med öppen källkod i juli: oavsiktliga skenande beteenden, en term som myntats av säkerhetsforskare från Cornell Tech (arXiv). En agent som fullföljer ett legitimt mål stöter på friktion, till exempel en saknad fil, ett misslyckat API-anrop, en utgången inloggningsuppgift eller en nekad behörighet, och letar efter en lösning. När den gör det kan den korsa säkerhetsgränser genom spaning, eskalering av privilegier, upptäckt av hemligheter eller dataexfiltrering. Själva agenten blir i praktiken motståndaren, även om ingen skadlig inmatning eller extern angripare är inblandad.

Hugging Face var inte ett isolerat fall. Fler beteenden med skenande agent upptäcktes och rapporterades under de senaste veckorna. Den 27–28 maj råkade agenter som försökte samla in data från University of Iowa från Data USA, en plattform som erbjuder öppen tillgång till amerikanska myndighetsdata, ut för fel som orsakades av en felformulerad fråga. De svarade med sonderingar, inklusive SQL-injektion, sajtöverskridande skriptkörning (XSS), mallinjektion, sökvägstraversering och kommandoinjektion. Aktiviteten kopplades senare till OpenAI (SecurityWeek). Den 20–21 juni blockerades OpenAI-agenter som försökte hämta statliga kostnader per person för en kategori av läkemedel över lokala områden i Victoria från Australian Institute of Health and Welfare (AIHW) från att ladda ner en fil. Som svar laddade agenterna ner filen, som redan var offentlig, från AIHW:s förproduktionsserver, vilket samtidigt kringgick webbplatsens skydd mot botar (SecurityWeek).

Mönstret begränsar sig inte till ett enda laboratorium. Under cybersäkerhetstester bröt sig Anthropic-modeller in i tre företag efter ett misstag som gav dem öppen tillgång till internet, Googles Gemini gissade inloggningsuppgifter till tre webbplatser, och en Meta-modell utnyttjade en tredjepartstjänst (Reuters).

Att lära av historien: Internetmaskarnas era

Dessa incidenter påminner om eran av internetmaskar för ungefär ett kvarts sekel sedan. I början av 2000-talet växte internet långt snabbare än säkerhetsrutinerna kring det. Vi såg en våg av virus och maskar med konsekvenser som var långt mer allvarliga än vad vi ser nu med AI-agenter som löper amok.

Den 4 maj 2000 började människor få e-postmeddelanden från bekanta avsändare med ämnesraden "ILOVEYOU". Att öppna bilagan i e-postmeddelandet resulterade i att ett skript kördes som skickade en kopia av sig själv till alla i offertens Outlook-adressbok. Klockan 18.00 samma dag hade CERT Coordination Center tagit emot rapporter som rörde mer än 420 000 internetvärdar (US GAO Report). Virusets rapporterades ha trängt igenom minst 14 federala myndigheter, inklusive försvarsdepartementet, CIA, NASA samt representanthuset och senaten (US GAO Report). Det stängde också ner e-postservrar vid Pentagon och det brittiska parlamentet (Wired). Försäkringsjätten Lloyd's of London gjorde en tidig uppskattning att viruset skulle kosta över 15 miljarder dollar i skador och förlorad produktivitet (US House Committee Hearing). Computer Economics uppskattade senare 8,75 miljarder dollar i skador över hela världen (Information Week).

Maskar som inte krävde något mänskligt klick kom härnäst. Den 19 juli 2001 infekterade Code-Red-masken mer än 359 000 datorer på mindre än 14 timmar (CAIDA). Den 25 januari 2003 fördubblades SQL Slammer i storlek var 8,5:e sekund och infekterade mer än 90 % av de internetvärdar som var sårbara för den inom 10 minuter (CAIDA), vilket utnyttjade ett hål som Microsoft hade släppt en säkerhetsuppdatering för sex månader tidigare (CNET). I augusti 2003 dök masken Blaster och e-postmasken Sobig upp med ungefär en veckas mellanrum (Microsoft, F-Secure).

Vid den tiden var det rimligt att fråga om nätverksanslutna datorer överhuvudtaget kunde göras säkra. Sex dagar efter ILOVEYOU-viruset höll ett amerikanskt underutskott en utfrågning om det. Många säkerhetsexperter efterlyste lagstiftning som skulle göra programvaruföretag skadeståndsskyldiga för skador orsakade av brister i deras produkter. Washington slog in på en annan väg. The National Strategy to Secure Cyberspace slog fast att ”federal reglering inte kommer att bli ett primärt medel för att säkra cyberrymden”. Den varnade för att breda mandat kunde skapa en ”minsta gemensamma nämnare-metod för cybersäkerhet” (CISA).

Branschen svarade med teknik. Elva dagar efter ILOVEYOU tillkännagav Microsoft en Outlook-uppdatering som blockerade körbara bilagor. I januari 2002 gjorde företaget säkerhet till högsta prioritet (Seattle Times). Automatisk uppdatering, säkra standardinställningar, hittelönsprogram för buggar och samordnat offentliggörande blev standardpraxis. År 2008 började Chrome köra webbinnehåll i en sandlåda som "begränsar vad en angripare kan göra efter att ha utnyttjat en bugg" (Chromium Blog). Kryptering, en gång ett undantag, blev standard. Säkerhetstekniker, inklusive multifaktorautentisering, brandväggar, zero trust och SIEM (Security Information and Event Management), blev allmänt använda. Organisationer över hela världen prognostiseras spendera ungefär 240 miljarder dollar under 2026 på informationssäkerhet (Gartner). Maskar försvann aldrig helt, men eran av rutinmässiga internetomfattande utbrott mattades av. Samtidigt blev internet, till stor del obehindrat av reglering, en kraftfull motor för innovation och ekonomisk tillväxt under de följande två decennierna.

Säkerhetsteknik för AI-agenter

Nyligen inträffade händelser har väckt berättigade frågor om agentstyrning. Befintliga säkerhetsmekanismer utvecklades för datormiljöer före agenttiden som kännetecknas av strikt avgränsat och till stor del deterministiskt programvarubeteende. Åtkomstkontrollmekanismer är i synnerhet utformade kring mänskliga användare och ger dem ofta breda privilegier som i princip är tillräckliga för att orsaka betydande skada.

Denna design vilar på flera antaganden: de flesta användare agerar i god tro; illvilliga aktörer kan avskräckas genom granskning och verkliga konsekvenser; och människor utför handlingar, oavsett om de är korrekta eller felaktiga, i en relativt begränsad takt. Att tillämpa dessa säkerhetsmekanismer på agenter kräver att man tar hänsyn till skillnader mellan mänskligt och agentbeteende. Som vi skrev i vår respons på Nist:s begäran om information om säkerhet för AI-agenter, utmanar AI-agenter dessa antaganden. De kan utöva privilegier och vidta åtgärder i maskinhastighet, avskräcks inte själva av verkliga konsekvenser och kan vidta åtgärder som är tekniskt tillåtna men som en typisk mänsklig användare sällan skulle vidta.

Att besvara dessa frågor kräver säkerhetsteknik. Vi känner till säkerhetsprinciperna för att bygga system som håller riskerna under kontroll när enskilda komponenter missköter sig. Men vi måste se till att dessa principer tillämpas vid konstruktionen av miljöer för träning, testning och användning av AI-agenter.

Säkerhetsprincipen för djupförsvar

Den kanske viktigaste säkerhetsprincipen som behöver tillämpas för att säkra AI-agenter är djupförsvar, som förespråkar en skiktad säkerhetsarkitektur där flera, varierade och redundanta försvarsåtgärder används för att skydda systemresurser. Ingen enskild skyddsåtgärd är perfekt. Människor kan falla för social engineering-attacker och avslöja sina inloggningsuppgifter, sårbarheter i programvara för noll-dagarsattacker upptäcks och utnyttjas, och intrångsdetektering missar nya attackvarianter. Djupförsvar accepterar detta och staplar flera oberoende försvarslager. Om ett försvarslager skulle kringgås, finns andra lager kvar för att motverka eller upptäcka intrånget.

Hugging Face-incidenten visar varför djupförsvar är viktigt. OpenAIs retrospektiv rapporterar att de automatiserade skyddsåtgärder som används i dess produktionssystem, inklusive harness, auto-granskningsmodeller och säkerhetsklassificerare, saknades i utvärderingsmiljön. Om dess för närvarande driftsatta kedja-av-tanke-övervakning (chain-of-thought) hade körts på dessa utvärderingar, skulle den ha fångat upp den ursprungliga aktiviteten och larmat säkerhetsteamet mer än ett dygn före intrånget (OpenAI). De skikt som kunde ha fångat upp problemet fanns. De fanns helt enkelt inte på plats samtidigt.

Att säkra AI-agenter kräver att man förbättrar både säkerheten och tryggheten för AI-modeller och de system som omger dem. Arbetet på modellagret spelar roll, och det ger resultat. Tidiga LLM:er manipulerades enkelt av injicerade instruktioner, medan dagens modeller är väsentligt bättre på att känna igen och avvisa dem. Modellutvecklare tränar också modeller för säkrare beteende och, som OpenAIs retrospektiv beskriver, övervakar resonemangsspår efter tecken på problematisk beteende. Men försvaret på modellnivå är bara en del av lösningen. De system i vilka agenter tränas, testas och driftsätts måste också konstrueras för säkerhet och inneslutning. Säkerhet på modellnivå minskar sannolikheten för att en agent ska gå vilse; säkerhet på systemnivå begränsar skadan när den gör det.

Förstora

Designregler för redundanta skyddsåtgärder

Djupförsvar kräver redundanta skyddsåtgärder. För agenter förespråkar vi att det tillämpas med tre designregler:

1. Oberoende. Varje lager bör misslyckas av oberoende skäl. Två kontroller som delar samma antagande kan slås ut av samma attack. Övervakare och tvingande punkter bör ligga utanför agentens räckvidd.
2. Tvingande åtgärder under agenten. Minst ett lager måste vara deterministiskt: konventionell, verifierbar kod som blockerar förbjudna åtgärder oavsett vad modellen producerar. En skyddsåtgärd som agenten kan avböja att anropa eller omkonfigurera är ingen skyddsåtgärd.
3. Signaler kan endast minska behörighet. Detektering bör utlösa svar som begränsar vad agenten kan göra, till exempel att pausa, återkalla inloggningsuppgifter, bryta nätverksåtkomst eller avsluta sessionen. Ingen risksignal bör någonsin bevilja ytterligare åtkomst.

Vi delar dessa principer med våra partners i Open Secure AI Alliance, inklusive NVIDIA, som har hävdat att harness styr vad en agent försöker göra medan infrastrukturen styr vad den kan göra (NVIDIA).

Djupförsvar i Perplexity-produkter

Perplexity kör agenter i fyra typer av miljöer: i molnet genom vår agentplattform Computer, i webbläsaren genom Comet, på användarenheter genom Portable Computer, och på anställdas bärbara datorer, där våra ingenjörer använder kodningsagenter från tredje part. Varje miljö har sina egna risker och får flera skyddslager.

I molnet: Computer och SPACE

Varje Computer-uppgift körs i SPACE, vår sandlådeplattform, som behandlar agenten som otillförlitlig som standard. Varje uppgift får sin egen mikro-VM, inloggningsuppgifter stannar utanför sandlådan och injiceras endast vid behov, utgående trafik styrs utanför gästen och ögonblicksbilder låter oss återställa destruktiva ändringar (Making SPACE). Företagskunder kan också ta med egna krypteringsnycklar. Att återkalla en nyckel gör den skyddade datan oläsbar, och agenten kan inte åsidosätta det beslutet.

Vi testar också om dessa lager håller. I Escaping SPACE: Part I gav vi nio banbrytande modeller root-åtkomst i en SPACE-sandlåda och bad dem bryta sig ut. Ingen rymde från den virtuella maskinen, men vissa hittade vägar runt nätverkspolicyn när partiell nätverksåtkomst tilläts. Vi åtgärdade dessa luckor, bekräftade åtgärderna i ett nytt test och avslöjade liknande svagheter som vi hittade i åtta av tio andra sandlådeplattformar för deras leverantörer.

I webbläsaren: Comet och BrowseSafe

Comet har använt ett skiktat försvar mot promptinjektion sedan lanseringen: klassificerare skannar hämtat innehåll, strukturerade inmatningar markerar det som otillförlitligt, känsliga åtgärder som att skicka ett e-postmeddelande eller lägga en beställning kräver användarens bekräftelse, och användare informeras när något blockeras (Comet prompt-injection defenses). BrowseSafe, det detekteringsmodell med öppen källkod som ligger bakom det första lagret, presterar bättre än banbrytande modeller på vårt BrowseSafe-Bench-riktmärke, men samma riktmärke visar att ingen detektor är helt säker, vilket är anledningen till att detektering aldrig är det enda lagret (BrowseSafe research). Computer ärver dessa försvar, som har granskats av Trail of Bits (Perplexity).

På enheten: Portable Computer

Portable Computer är en lokal-först-agent: modellen, harness, konversationen och banan stannar som standard på användarens maskin. En deterministisk orchestrator, som är harness-kod snarare än en LLM, kör loopen och tillämpar policyn. Modellen föreslår åtgärder, och godkända verktygsanrop körs i en sandlåda på operativsystemnivå som begränsar processer, sökvägar och nätverksåtkomst. Sandlådan är ständigt på och fail-closed: om den inte är tillgänglig inaktiverar harness sig själv i stället för att köra kommandon med användarens behörigheter. Åtgärder som korsar enhetsgränsen, såsom webbsökning, anslutningar och eskalering till en starkare molnrådgivarmodell, sker endast när användaren aktiverar och godkänner dem. Före ett rådgivaranrop flaggar en PII-klassificerare känslig information och användaren ser vad som skulle skickas. Rådgivaren tar endast emot den godkända kontexten och returnerar textvägledning, utan tillgång till enhetens filer eller verktyg.

På slutpunkten: Numbat

Koderagenter på utvecklares bärbara datorer körs i timmar med tillgång till källkod, inloggningsuppgifter och produktionssystem. Numbat, vår agent-säkerhetssvit med öppen källkod, lägger till ett oberoende lager som ligger utanför en enskild agent. Det fungerar med harness som Claude Code, Codex, OpenCode och Pi, blockerar farliga åtgärder innan de körs, flaggar misstänkta sekvenser i flera steg, till exempel att läsa en hemlighet och sedan skicka data utåt, och bevarar tidslinjer för sessionen för undersökning. Numbat körs på tusentals Perplexity-slutpunkter tillsammans med Bumblebee, vår leveranskedjeskanner med öppen källkod. Computer granskar regelbundet deras fynd och föreslår förbättrade detekteringsregler, och en människa godkänner varje ändring innan den skickas ut.

Ett jobb för hela branschen

Allt eftersom AI-agenter blir mer kapabla och allmänt använda måste säkerhetsteknik förbli central för deras utveckling och driftsättning. Forskare och ingenjörer kan bygga vidare på etablerade principer, använda verkliga fynd för att förbättra försvaret och testa skyddsåtgärder i de miljöer där agenter verkar. Säkerhet är en pågående ingenjörsdisciplin som utvecklas i takt med tekniken.

Säkerhetsteknik för agenter är ett jobb för hela branschen. Ingen enskild anställd styr hela stacken som en agent körs på. Modellutvecklare, harness-byggare, sandlåde- och körtidsleverantörer, moln- och hårdvarulevandrare samt företagets säkerhetsteam äger var sitt lager. Säkerheten för helheten beror på att varje lager håller när ett annat sviktar. Det är därför vi bygger skyddsåtgärder som fungerar över agent-harness och gör våra verktyg tillgängliga med öppen källkod. Det är också därför vi avslöjar de svagheter vi hittar i andra plattformar och deltar i initiativ som Open Secure AI Alliance.

För att arbeta med det bredare samhället kring dessa utmaningar lanserade Perplexity Secure Intelligence Institute i mars 2026 för att studera säkerhet, tillförlitlighet och praktiskt försvar för banbrytande AI-system (Perplexity). Perplexity samarbetar för närvarande med och/eller finansierar akademiska forskare vid Stanford, CMU, Duke, Columbia, Ohio State och University of Virginia. Vi utför även intern forskning för att driva gränserna för forskning om agentsäkerhet, omvandla dessa framsteg till konkreta förbättringar i Perplexity-systemen samt dela med oss av kunskap och resurser som hjälper till att stärka det bredare AI-ekosystemet. Säkrare agenter är något som branschen kan konstruera. Vi har för avsikt att fortsätta göra vår del och vi bjuder in andra att bygga tillsammans med oss.