Hvordan vi designer sikrere agenter

For at bygge sikrere AI-agenter er vi nødt til at designe med henblik på både deres evner og deres fejl. Selv når de udfører lovlige opgaver, og uden nogen svigagtige instruktioner, kan agenter krydse sikkerhedsgrænser, når de forsøger at overvinde forhindringer.

Vi tror på, at dette er et sikkerhedsteknisk problem, og branchen bør gribe det an på samme måde, som den greb internetormene fra begyndelsen af 00'erne an på. Systemerne omkring agenter skal begrænse, hvad agenter kan få adgang til, opdage uønsket adfærd og inddæmne fejl, når de opstår.

Hos Perplexity samarbejder vi aktivt med forskere og praktikere om at fremme sikkerhedsteknik for AI-agenter, og vi anvender flere forsvarslag på tværs af vores modeller, agent-harness og infrastruktur, så sikkerheden ikke afhænger af en enkelt sikkerhedsforanstaltning.

Nedbrudsadfærd hos AI-agenter

I juli brød AI-agenter ind i open-source AI-platformen Hugging Fages produktionsinfrastruktur. Under interne cybersikkerhedsevalueringer og træningskørsler opdagede OpenAI-modeller en måde at udnytte Artifactory-lagermanageren til at oprette en opslagstavle til kommunikation med hinanden, hvilket gjorde det muligt for dem at organisere sig i sværme. Senere rekrutterede agenter, der ikke var i stand til at gøre fremskridt med opgaver i et cybersikkerhedsbenchmark, andre agenter til at hjælpe. Disse agenter brød ud af deres evalueringsmiljø og nåede ud på internettet. De opdagede også måder at snyde på ved at reverse-engineere svar på benchmark-opgaverne, men troede, at graderingssystemet ville opdage snyderiet. For bedre at forstå, hvordan benchmark-evalueringen fungerede for at finde måder at undgå at blive opdaget som snydere på, kompromitterede de i sidste ende Hugging Face-systemer (Hugging Face; OpenAI).

Hændelsen er et klart eksempel på en feiltilstand, vi beskrev, da vi gjorde Numbat til open-source i juli: utilsigtede nedbrud (accidental meltdowns), et udtryk skabt af sikkerhedsforskere fra Cornell Tech (arXiv). En agent, der forfølger et legitimt mål, møder modstand, såsom en manglende fil, et mislykket API-kald, en udløbet legitimationsoplysninger eller en tilladelsesnægtelse, og begynder at lede efter en løsning. Derved kan den krydse sikkerhedsgrænser gennem rekognoscering, rettighedseskalering, opdagelse af hemmeligheder eller data exfiltration. Selve agenten bliver reelt modstanderen, selvom der ikke er involveret nogen svigagtig prompt eller ekstern angriber.

Hugging Face var ikke et enkeltstående tilfælde. Flere tilfælde af agent-nedbrud blev opdaget og rapporteret i de seneste uger. Den 27.-28. maj stødte agenter, der forsøgte at indsamle data fra University of Iowa fra Data USA – en platform, der tilbyder åben adgang til amerikanske offentlige data – på fejl forårsaget af en forkormuleret forespørgsel. De reagerede med undersøgelser, herunder SQL-injektion, cross-site scripting, template-injektion, path traversal og command-injektion. Aktiviteten blev senere sat i forbindelse med OpenAI (SecurityWeek). Den 20.-21. juni blev OpenAI-agenter, der forsøgte at indhente offentlige omkostninger pr. person for en kategori af lægemidler på tværs af lokale områder i Victoria fra Australian Institute of Health and Welfare (AIHW), forhindret i at downloade en fil. Som reaktion herpå downloadede agenterne filen, som allerede var offentlig, fra AIHW's præproduktionsserver og omgik derved webstedets anti-bot-beskyttelse (SecurityWeek).

Mønsteret er ikke begrænset til ét laboratorium. Under cybersikkerhedstests brød Anthropic-modeller igennem til tre virksomheder, efter en fejl gav dem åben internetadgang, Googles Gemini gættede legitimationsoplysninger til tre websteder, og en Meta-model udnyttede en tredjepartstjeneste (Reuters).

At lære af historien: Tiden med internet-orme

Disse hændelser minder om æraen med internetorme for omtrent et kvart århundrede siden. I begyndelsen af 00'erne voksede internettet meget hurtigere end sikkerhedspraksisserne omkring det. Vi så en bølge af vira og orme med konsekvenser, der var langt mere alvorlige end det, vi ser nu med AI-agenter i nedbrud.

Den 4. maj 2000 begyndte folk at modtage e-mails fra kendte afsendere med emnelinjen "ILOVEYOU". Åbning af den vedhæftede fil i e-mailen resulterede i kørsel af et script, der sendte en kopi af sig selv til alle i offerets Outlook-adressebog. Kl. 18.00 samme dag havde CERT Coordination Center modtaget rapporter om mere af 420.000 internetværter (US GAO Report). Virussen trængte angiveligt ind i mindst 14 føderale agenturer, herunder Department of Defense, CIA, NASA samt Repræsentanternes Hus og Senatet (US GAO Report). Den lukkede også e-mail-servere i Pentagon og det britiske parlament (Wired). Forsikringsgiganten Lloyd's of London lavede et tidligt skøn over, at virussen ville koste over 15 milliarder dollars i skader og tabt produktivitet (US House Committee Hearing). Computer Economics anslog senere tabet til 8,75 milliarder dollars på verdensplan (Information Week).

Orme, der ikke krævede et menneskeligt klik, kom som det næste. Den 19. juli 2001 inficerede Code-Red-ormen mere end 359.000 computere på under 14 timer (CAIDA). Den 25. januar 2003 fordoblede SQL Slammer størrelse hvert 8,5. sekund og inficerede mere end 90 % af de internetværter, der var sårbare over for den, inden for 10 minutter (CAIDA), idet den udnyttede et hul, som Microsoft havde udsendt en patch for seks måneder tidligere (CNET). I august 2003 optrådte Blaster-ormen og Sobig-e-mail-ormen med ca. en uges mellemrum (Microsoft, F-Secure).

Dengang var det rimeligt at spørge, om netværksforbundne computere overhovedet kunne gøres sikre. Seks dage efter ILOVEYOU-virussen afholdt et underudvalg i det amerikanske Repræsentanternus Hus en høring om det. Mange sikkerhedseksperter opfordrede til lovgivning, der ville gøre softwarevirksomheder ansvarlige for skader forårsaget af fejl i deres produkter. Washington valgte en anden vej. The National Strategy to Secure Cyberspace erklærede, at "føderal regulering vil ikke blive et primært middel til at sikre cyberspace." Den advarede om, at brede mandater kunne skabe en "laveste-fælles-nævner-tilgang til cybersikkerhed" (CISA).

Branchen svarede igen med teknik. Elleve dage efter ILOVEYOU annoncerede Microsoft en Outlook-opdatering, der blokerede eksekverbare vedhæftede filer. I januar 2002 gjorde virksomheden sikkerhed til en top-prioritet (Seattle Times). Automatisk patching, sikre standardindstillinger, bug bounty-programmer og koordineret offentliggørelse blev standardpraksis. I 2008 begyndte Chrome at køre webindhold i en sandbox, som "begrænser, hvad en angriber kan gøre efter udnyttelse af en fejl" (Chromium Blog). Kryptering, engang en undtagelse, blev standard. Sikkerhedsteknologier, herunder multifaktor-godkendelse, firewalls, zero trust og sikkerhedsinformation og hændelsesstyring (SIEM), blev bredt anvendt. Organisationer over hele verden forventes at bruge omkring 240 milliarder dollars i 2026 på informationssikkerhed (Gartner). Orme forsvandt aldrig helt, men æraen med rutinemæssige internet-omfattende udbrud aftog. Samtidig blev internettet, i vid udstrækning uforstyrret af regulering, en kraftfuld motor for innovation og økonomisk vækst over de følgende to årtier.

Sikkerhedsteknik for AI-agenter

Nyere hændelser har rejst berettigede spørgsmål om agent-styring. Eksisterende sikkerhedsmekanismer blev udviklet til præ-agent-computermiljøer, der er kendetegnet ved stramt afgrænset og overvejende deterministisk softwareadfærd. Især adgangskontrolmekanismer er primært designet til menneskelige brugere og giver dem ofte brede rettigheder, der i princippet er tilstrækkelige til at forårsage væsentlig skade.

Dette design hviler på flere antagelser: de fleste brugere handler i god tro; svigagtige aktører kan afskrækkes gennem revision og konsekvenser i den virkelige verden; og mennesker foretager handlinger, uanset om de er korrekte eller fejlagtige, i et forholdsvis begrænset tempo. Anvendelse af disse sikkerhedsmekanismer på agenter kræver, at der tages højde for forskelle mellem menneskelig adfærd og agent-adfærd. Som vi skrev i vores svar på NIST's anmodning om information om AI-agent-sikkerhed, udfordrer AI-agenter disse antagelser. De kan udøve rettigheder og udføre handlinger med maskinhastighed, afskrækkes ikke selv af konsekvenser i den virkelige verden og kan udføre handlinger, der er teknisk tilladte, men som en typisk menneskelig bruger sjældent ville foretage.

At besvare disse spørgsmål kræver sikkerhedsteknik. Vi kender sikkerhedsprincipperne for bygning af systemer, der holder risiciene under kontrol, når individuelle komponenter opfører sig forkert. Men vi er nødt til at sikre, at disse principper anvendes, når vi designer miljøer til træning, test og brug af AI-agenter.

Dybdeforsvarets sikkerhedsprincip

Muligvis det vigtigste sikkerhedsprincip, der skal anvendes for at sikre AI-agenter, er dybdeforsvar (defense-in-depth), som plæderer for en lagdelt sikkerhedsarkitektur, hvor der anvendes flere, varierede og redundante forsvarsforanstaltninger til at beskytte systemresourcer. Ingen enkelt sikkerhedsforanstaltning er perfekt. Mennesker kan falde for social engineering-angreb og afsløre deres login-legitimationsoplysninger, zero-day-software sårbarheder opdages og udnyttes, og indtrængningsdetektering overser nye angrebsvarianter. Dybdeforsvar accepterer dette og opstiller flere uafhængige forsvarslag. Hvis det ene forsvarslag omgås, er de andre lag stadig på plads for at modvirke eller opdage indtrængningen.

Hugging Face-hændendelsen viser, hvorfor dybdeforsvar (defense-in-depth) er vigtigt. OpenAIs retrospektive rapport viser, at de automatiserede sikkerhedsforanstaltninger, der anvendes i produktionssystemerne – herunder harness, auto-review-modeller og sikkerhedsklassifikatorer – ikke var til stede i evalueringsmiljøet. Hvis dens aktuelt implementerede chain-of-thought-overvågning havde kørt på disse evalueringer, ville den have fanget den oprindelige aktivitet og givet besked til sikkerhedsteamet mere end en dag før bruddet (OpenAI). De lag, der kunne have opdaget problemet, fandtes. De var blot ikke alle på plads på samme tid.

Sikring af AI-agenter kræver forbedring af både sikkerheden og pålideligheden af AI-modeller og de systemer, der omgiver dem. Arbejdet på modellaget betyder noget, og det betaler sig. Tidlige LLM'er blev nemt manipuleret af injicerede instruktioner, mens nutidens modeller er væsentligt bedre til at genkende og afvise dem. Modeludviklere træner også modeller til mere sikker adfærd og overvåger, som OpenAIs retrospektiv beskriver, ræsonneringsspor for tegn på problematisk adfærd. Men forsvar på modellag er kun en del af løsningen. De systemer, hvori agenter trænes, testes og udrulles, skal også konstrueres med henblik på sikkerhed og inddæmning. Sikkerhed på modellag reducerer sandsynligheden for, at en agent løber løbsk; sikkerhed på systemlag begrænser skaden, når det sker.

Udvid

Designregler for redundante sikkerhedsforanstaltninger

Dybdeforsvar kræver redundante sikkerhedsforanstaltninger. For agenter anbefaler vi at anvende det med tre designregler:

1. Uafhængighed. Hvert lag bør svigte af uafhængige årsager. To kontroller, der deler den samme antagelse, kan slås af det samme angreb. Skærme og håndhævelsespunkter bør placeres uden for agentens rækkevidde.
2. Håndhævelse under agenten. Mindst ét lag skal være deterministisk: konventionel, verificerbar kode, der blokerer forbudte handlinger uanset hvad modellen producerer. En sikkerhedsforanstaltning, som agenten kan vælge ikke at påkalde sig eller rekonfigurere, er ikke en sikkerhedsforanstaltning.
3. Signaler kan kun reducere autoritet. Detektion bør udløse reaktioner, der indsnævrer, hvad agenten kan gøre, såsom at pause, tilbagekalde legitimationsoplysninger, afbryde netværksadgang eller afslutte sessionen. Intet risikosignal bør nogensinde give yderligere adgang.

Vi deler disse principper med vores partnere i Open Secure AI Alliance, herunder NVIDIA, som har argumenteret for, at harness styrer, hvad en agent forsøger, mens infrastrukturen kontrollerer, hvad den kan gøre (NVIDIA).

Dybdeforsvar i Perplexitys produkter

Perplexity kører agenter i fire typer miljøer: i skyen gennem vores agent-platform Computer, i browseren gennem Comet, på brugerenheder gennem Portable Computer og på medarbejdernes bærbare computere, hvor vores ingeniører bruger tredjeparts-kodningsagenter. Hvert miljø har sine egne risici, og hvert miljø får flere lag af beskyttelse.

I skyen: Computer og SPACE

Hver Computer-opgave kører i SPACE, vores sandbox-platform, som behandler agenten som utroværdig som standard. Hver opgave får sin egen microVM, legitimationsoplysninger forbliver uden for sandboxen og injiceres kun, når det er nødvendigt, udgående trafik kontrolleres uden for gæsten, og snapshots giver os mulighed for at rulle destruktive ændringer tilbage (Making SPACE). Virksomhedskunder kan også medbringe deres egne krypteringsnøgler. Tilbagekaldelse af en nøgle gør de beskyttede data ulæselige, og agenten kan ikke tilsidesætte den beslutning.

Vi tester også, om disse lag holder. I Escaping SPACE: Part I gav vi ni frontier-modeller root-adgang i en SPACE-sandbox og bad dem om at bryde ud. Ingen undslap VM'en, men nogle fandt måder at omgå netværkspolitikken på, når delvis netværksadgang var tilladt. Vi rettede disse huller, bekræftede rettelserne i en gen-test og oplyste om lignende svagheder, vi fandt i otte ud af 10 andre sandbox-platforme, til deres leverandører.

I browseren: Comet og BrowseSafe

Comet har brugt et lagdelt prompt-injektionsforsvar siden lanceringen: klassifikatorer screener hentet indhold, strukturerede prompter markerer det som utroværdigt, følsomme handlinger såsom afsendelse af en e-mail eller afgivelse af en ordre kræver brugerens bekræftelse, og brugere får besked, når noget blokeres (Comet prompt-injection defenses). BrowseSafe, open-source-detektionsmodellen bag det første lag, overgår frontier-modeller på vores BrowseSafe-Bench-benchmark, men den samme benchmark viser, at ingen detektor er fejlsikker, hvilket er grunden til, at detektion aldrig er det eneste lag (BrowseSafe research). Computer arver disse forsvarsværker, som er blevet revideret af Trail of Bits (Perplexity).

På enheden: Portable Computer

Portable Computer er en lokal-først-agent: modellen, harness, samtalen og banen forbliver som standard på brugerens maskine. En deterministisk orkestrator, som er harness-kode snarere end en LLM, kører sløjfen og håndhæver politikken. Modellen foreslår handlinger, og godkendte værktøjskald kører i en sandbox på OS-niveau, der begrænser processer, filstier og netværksadgang. Sandboxen er altid tændt og fejer lukket (fail-closed): Hvis den ikke er tilgængelig, deaktiverer harness sig selv i stedet for at køre kommandoer med brugerens rettigheder. Handlinger, der krydser enhedsgrænsen, såsom websøgning, connectors og eskalering til en stærkere sky-rådgivermodel, sker kun, når brugeren aktiverer og godkender dem. Før et rådgiverkald markerer en PII-klassifikator følsomme oplysninger, og brugeren ser, hvad der vil blive sendt. Rådgiveren modtager kun denne godkendte kontekst og returnerer tekstmæssig vejledning uden adgang til enhedens filer eller værktøjer.

På endpointet: Numbat

Kodningsagenter på udviklerbærbare computere kører i timevis med adgang til kildekode, legitimationsoplysninger og produktionssystemer. Numbat, vores open-source agent-sikkerhedssuite, tilføjer et uafhængigt lag, der sidder uden for enhver enkelt agent. Den fungerer sammen med harness som Claude Code, Codex, OpenCode og Pi, blokerer farlige handlinger, før de kører, markerer mistænkelige flertrinssekvenser såsom læsning af en hemmelighed og derefter afsendelse af data, og bevarer sessionstidslinjer til undersøgelse. Numbat kører på tværs af tusindvis af Perplexity-endpoints sammen med Bumblebee, vores open-source forsyningskædescanner. Computer gennemgår regelmæssigt deres fund og foreslår forbedrede detektionsregler, og et menneske godkender hver ændring, før den sendes ud.

En opgave for hele branchen

Efterhånden som AI-agenter bliver mere kapable og bredt anvendt, skal sikkerhedsteknik forblive central for deres udvikling og udrulling. Forskere og ingeniører kan bygge videre på etablerede principper, bruge fund fra den virkelige verden til at finpudse forsvarsværker og teste sikkerhedsforanstaltninger på tværs af de miljøer, hvor agenter opererer. Sikkerhed er en løbende ingeniørdisciplin, der udvikler sig i takt med teknologien.

Sikkerhedsteknik for agenter er en opgave for hele branchen. Ingen enkelt virksomhed kontrollerer hele stakken, som en agent kører på. Modeludviklere, harness-byggere, sandbox- og runtime-udbydere, sky- og hardwareleverandører og virksomheders sikkerhedsteams ejer hver deres lag. Sikkerheden for det hele afhænger af, at hvert lag holder, når et andet svigter. Det er derfor, vi bygger sikkerhedsforanstaltninger, der fungerer på tværs af agent-harness og gør vores værktøjer til open-source. Det er også derfor, vi afslører de svagheder, vi finder på andre platforme, og deltager i initiativer som Open Secure AI Alliance.

For at arbejde sammen med det bredere samfund om disse udfordringer lancerede Perplexity Secure Intelligence Institute i marts 2026 for at studere sikkerhed, troværdighed og praktisk forsvar af førende AI-systemer (Perplexity). Perplexity samarbejder og/eller finansierer i øjeblikket akademiske forskere på Stanford, CMU, Duke, Columbia, Ohio State og University of Virginia. Vi udfører også intramural forskning for at flytte grænserne for agent-sikkerhedsforskning, omsætte disse fremskridt til konkrete forbedringer i Perplexity-systemer og dele viden og ressourcer, der hjælper med at styrke det bredere AI-økosystem. Sikrere agenter er noget, branchen kan udvikle. Vi har til hensigt at blive ved med at yde vores del og opfordrer andre til at bygge med os.