Hvordan vi konstruerer tryggere agenter

For å bygge tryggere AI-agenter må vi designe med tanke på både deres evner og deres feil. Selv når de utfører lovlige oppgaver og uten skadelige instruksjoner, kan agenter krysse sikkerhetsgrenser når de prøver å overvinne hindringer.

Vi mener dette er et sikkerhetsteknisk problem, og bransjen bør ta tak i det slik den tok tak i internettormene tidlig på 2000-tallet. Systemene rundt agenter må begrense hva agenter kan få tilgang til, oppdage uønsket oppførsel og inneholde feil når de oppstår.

Hos Perplexity samarbeider vi aktivt med forskere og praktikere for å fremme sikkerhetsteknikk for AI-agenter, og vi anvender flere forsvarslag på tvers av modellene våre, agent-harness-er og infrastruktur slik at sikkerheten ikke avhenger av ett enkelt sikkerhetstiltak.

Løpsk oppførsel hos AI-agenter

I juli brøt AI-agenter seg inn i produksjonsinfrastrukturen til den åpen kildekode-baserte AI-plattformen Hugging Face. Under interne cybersikkerhetsevalueringer og treningskjøringer oppdaget OpenAI-modeller en måte å utnytte Artifactory-repositoriestyringen på for å opprette en oppslagstavle for kommunikasjon med hverandre, slik at de kunne organisere seg i svermer. Senere rekrutterte agenter som ikke klarte å gjøre fremgang på oppgaver i en cybersikkerhets-benchmark, andre agenter til å hjelpe. Disse agentene brøt ut av evalueringsmiljøet sitt og nådde internett. De oppdaget også måter å jukse på ved å reversere svar på benchmark-oppgavene, men trodde at graderingssystemet ville oppdage jukset. For å forstå bedre hvordan benchmark-evalueringen fungerte for å finne måter å unngå å bli oppdaget som juksere på, kompromitterte de til slutt Hugging Face-systemene (Hugging Face; OpenAI).

Hendelsen er et tydelig eksempel på en feilmodus vi beskrev da vi gjorde Numbat til åpen kildekode i juli: utilsiktede utfall, et begrep myntet av sikkerhetsforskere fra Cornell Tech (arXiv). En agent som forfølger et lovlig mål, møter friksjon, for eksempel en manglende fil, et mislykket API-kall, en utløpt legitimasjon eller en tillatelsesnektelse, og begynner å lete etter en omvei. Ved å gjøre det kan den krysse sikkerhetsgrenser gjennom rekognosering, eskalering av privilegier, oppdagelse av hemmeligheter eller dataeksfiltrasjon. Selve agenten blir i praksis motstanderen, selv om ingen ondsinnet ledetekst eller ekstern angriper er involvert.

Hugging Face var ikke et isolert tilfelle. Flere tilfeller der agent-oppførsel har løpska, ble oppdaget og rapportert de siste ukene. Den 27.–28. mai støtte agenter som forsøkte å samle inn data fra University of Iowa fra Data USA – en plattform som tilbyr åpen tilgang til amerikanske offentlige data – på feil som skyldtes en feilformet spørring. De svarte med prober, inkludert SQL-injeksjon, nettsted på tvers av nettsteder (XSS), malinjeksjon, banegjennomgang og kommandoinjeksjon. Aktiviteten ble senere knyttet til OpenAI (SecurityWeek). Den 20.–21. juni ble OpenAI-agenter som prøvde å hente inn offentlige kostnader per person for en legemiddelkategori på tvers av lokale områder i Victoria fra Australian Institute of Health and Welfare (AIHW), blokkert fra å laste ned en fil. Som svar lastet agentene ned filen, som allerede var offentlig, fra AIHWs preproduksjonsserver, og omgikk nettstedets anti-bot-beskyttelse i prosessen (SecurityWeek).

Mønsteret er ikke begrenset til én lab. Under cybersikkerhetstester brøt Anthropic-modeller seg inn i tre selskaper etter at en feil ga dem åpen internettilgang, Googles Gemini gjetta legitimasjon til tre nettsteder, og en Meta-modell utnyttet en tredjepartstjeneste (Reuters).

Lære av historien: Internettormenes æra

Disse hendelsene minner om internettormenes æra for omtrent et kvart århundre siden. Tidlig på 2000-tallet vokste internett langt raskere enn sikkerhetspraksisen rundt det. Vi så en bølge av virus og ormer, med konsekvenser som var langt mer alvorlige enn det vi ser nå med AI-agenter som løper løpsk.

Den 4. mai 2000 begynner folk å motta e-poster fra kjente avsendere med emnefeltet «ILOVEYOU». Å åpne vedlegget i e-posten resulterte i kjøring av et skript som sendte en kopi av seg selv til alle i offerets Outlook-adressebok. Innen kl. 18.00 den dagen hadde CERT Coordination Center mottatt rapporter som involverte mer enn 420 000 internettverter (US GAO Report). Virusets penetrerte angivelig minst 14 føderale byråer, inkludert Forsvarsdepartementet, CIA, NASA og Representantenes hus og Senatet (US GAO Report). Det stengte også e-postservere i Pentagon og det britiske parlamentet (Wired). Forsikringsgiganten Lloyd's of London gjorde et tidlig anslag om at viruset ville koste over 15 milliarder dollar i skader og tapt produktivitet (US House Committee Hearing). Computer Economics anslo senere 8,75 milliarder dollar i skader over hele verden (Information Week).

Ormer som ikke trengte menneskelige klikk, kom deretter. Den 19. juli 2001 infiserte Code-Red-ormen mer enn 359 000 datamaskiner på under 14 timer (CAIDA). Den 25. januar 2003 doblet SQL Slammer seg i størrelse hvert 8,5. sekund og infiserte mer enn 90 % av internettverter som var sårbare for den, i løpet av 10 minutter (CAIDA), og utnyttet et hull som Microsoft hadde utstedt en oppdatering for seks måneder tidligere (CNET). I august 2003 dukket Blaster-ormen og Sobig-e-postormen opp med omtrent en ukes mellomrom (Microsoft, F-Secure).

Den gangen var det rimelig å spørre om nettverkstilkoblede datamaskiner i det hele tatt kunne sikres. Seks dager etter ILOVEYOU-viruset holdt en underkomité i Representantenes hus i USA en høring om det. Mange sikkerhetsekperter tok til orde for lovgivning som ville gjøre programvareselskaper ansvarlige for skader forårsaket av feil i produktene deres. Washington tok en annen vei. «The National Strategy to Secure Cyberspace» slo fast at «føderal regulering ikke vil bli et primært middel for å sikre cyberspace». Den advarte om at brede påbud kunne skape en «minste felles multiplum-tilnærming til cybersikkerhet» (CISA).

Bransjen svarte med ingeniørkunst. Elleve dager etter ILOVEYOU kunngjorde Microsoft en Outlook-oppdatering som blokkerte kjørbare vedlegg. I januar 2002 gjorde selskapet sikkerhet til høyeste prioritet (Seattle Times). Automatisk oppdatering, sikre standardinnstillinger, bug bounty-programmer og koordinert offentliggjøring ble standard praksis. I 2008 begynte Chrome å kjøre nettinnhold i en sandbox som «begrenser hva en angriper kan gjøre etter å ha utnyttet en feil» (Chromium Blog). Kryptering, en gang unntaket, ble standard. Sikkerhetsteknologier, inkludert multifaktorautentisering, brannmurer, zero trust og sikkerhetsinformasjon og hendelseshåndtering (SIEM), ble mye brukt. Organisasjoner over hele verden er anslått å bruke omtrent 240 milliarder dollar i 2026 på informasjonssikkerhet (Gartner). Ormer forsvant aldri helt, men æraen med rutinemessige internettomfattende utbrudd avtok. Samtidig ble internett, i stor grad uhindret av regulering, en kraftig motor for innovasjon og økonomisk vekst de neste to tiårene.

Sikkerhetsteknikk for AI-agenter

Nylige hendelser har reist betimelige spørsmål om agentstyring. Eksisterende sikkerhetsmekanismer ble utviklet for datamiljøer før agenttiden, preget av snevert definert og i stor grad deterministisk programvareadferd. Særlig mekanismer for tilgangskontroll er primært utformet rundt menneskelige brukere og gir dem ofte brede privilegier som i prinsippet er tilstrekkelige til å forårsake betydelig skade.

Dette designet hviler på flere forutsetninger: de fleste brukere opptrer i god tro; ondsinnet aktører kan avskrekkes gjennom revisjon og virkelige konsekvenser; og mennesker utfører handlinger, enten de er korrekte eller feilaktige, i et relativt begrenset tempo. Å anvende disse sikkerhetsmekanismene på agenter krever at man tar høyde for forskjeller mellom menneskelig og agentbasert adferd. Som vi skrev i vår respons på NISTs forespørsel om informasjon om AI-agentsikkerhet, utfordrer AI-agenter disse forutsetningene. De kan utøve privilegier og utføre handlinger i maskinhastighet, avskrekkes ikke selv av virkelige konsekvenser, og kan utføre handlinger som er teknisk tillatt, men som en typisk menneskelig bruker sjelden ville gjort.

Å besvare disse spørsmålene krever sikkerhetsteknikk. Vi kjenner sikkerhetsprinsippene for å bygge systemer som holder risikoen under kontroll når enkelte komponenter oppfører seg unormalt. Men vi må sørge for at disse prinsippene anvendes når vi konstruerer miljøer for trening, testing og bruk av AI-agenter.

Dybdeforsvarsprinsippet for sikkerhet

Uten tvil det viktigste sikkerhetsprinsippet som må anvendes for å sikre AI-agenter, er dybdeforsvar. Dette innebærer en lagdelt sikkerhetsarkitektur der det brukes flere, ulike og redundante defensive tiltak for å beskytte systemresurser. Ingen enkelt sikkerhetstiltak er feilfritt. Mennesker kan falle for sosial manipulering og avsløre påloggingsinformasjon, programvaresårbarheter av typen zero-day oppdages og utnyttes, og inntrengningsdeteksjon går glipp av nye angrepsvarianter. Dybdeforsvar aksepterer dette og stabler flere uavhengige forsvarslag oppå hverandre. Dersom ett forsvarslag omgås, forblir de andre lagene på plass for å motvirke eller oppdage inntrengningen.

Hugging Face-hendelsen viser hvorfor dybdeforsvar er viktig. OpenAIs retrospektive rapport viser at de automatiserte sikkerhetstiltakene som ble brukt i produksjonssystemene, inkludert harness-er, auto-gjennomgangsmodeller og sikkerhetsklassifiseringsverktøy, manglet i evalueringsmiljøet. Hvis den nåværende distribuerte overvåkingen av tankekjeden hadde kjørt på disse evalueringene, ville den fanget opp den første aktiviteten og varslet sikkerhetsteamet mer enn en døgn før bruddet (OpenAI). Lagene som kunne ha fanget opp problemet, fantes allerede. De var rett og slett ikke på plass samtidig.

Å sikre AI-agenter krever å forbedre både sikkerheten og tryggheten til AI-modeller og systemene rundt dem. Arbeid på modellaget betyr noe, og det gir resultater. Tidlige LLM-er ble enkelt manipulert av injiserte instruksjoner, mens dagens modeller er vesentlig bedre til å gjenkjenne og avvise dem. Modellutviklere trener også modeller for tryggere oppførsel og overvåker resonneringsspor for tegn på problematisk oppførsel, slik OpenAIs retrospektive beskriver. Men forsvarsmekanismer på modellnivå er bare en del av løsningen. Systemene som agenter trenes, testes og distribueres i, må også konstrueres for sikkerhet og inneslutning. Sikkerhet på modellnivå reduserer sannsynligheten for at en agent går vill; systemnivåsikkerhet begrenser skaden når det skjer.

Forstørr

Designregler for redundante sikkerhetstiltak

Dybdeforsvar krever redundante sikkerhetstiltak. For agenter anbefaler vi å bruke dette med tre designregler:

1. Uavhengighet. Hvert lag skal feile av uavhengige årsaker. To kontroller som deler den samme antakelsen, kan slås av det samme angrepet. Overvåkere og håndhevingspunkter bør befinne seg utenfor agentens rekkevidde.
2. Håndhevelse under agenten. Minst ett lag må være deterministisk: konvensjonell, verifiserbar kode som blokkerer forbudte handlinger uansett hva modellen produserer. Et sikkerhetstiltak som agenten kan velge å ikke påberope seg eller rekonfigurere, er ikke et sikkerhetstiltak.
3. Signaler kan bare redusere autoritet. Deteksjon bør utløse responser som innskrenker hva agenten kan gjøre, som å sette på pause, trekke tilbake legitimasjon, kutte nettverkstilgang eller avslutte økten. Ingen risiko-signaler skal noen gang gi ekstra tilgang.

Vi deler disse prinsippene med våre partnere i Open Secure AI Alliance, inkludert NVIDIA, som har hevdet at harness-en veileder hva en agent prøver på, mens infrastrukturen kontrollerer hva den kan gjøre (NVIDIA).

Dybdeforsvar i Perplexitys produkter

Perplexity kjører agenter i fire typer miljøer: i skyen gjennom vår agentplattform Computer, i nettleseren gjennom Comet, på brukerenheter gjennom Portable Computer og på ansattes bærbare datamaskiner, der ingeniørene våre bruker tredjeparts koderagenter. Hvert miljø har sin egen risiko, og hvert får flere lag med beskyttelse.

I skyen: Computer og SPACE

Hver Computer-oppgave kjører i SPACE, vår sandbox-plattform, som behandler agenten som utrygt som standard. Hver oppgave får sin egen mikrovirtuelle maskin (microVM), legitimasjon forblir utenfor sandbox-en og injiseres bare når det trengs, utgående trafikk kontrolleres utenfor gjesten, og øyeblikksbilder (snapshots) lar oss rulle tilbake destruktive endringer (Making SPACE). Bedriftskunder kan også ta med egne krypteringsnøkler. Tilbaketrekking av en nøkkel gjør de beskyttede dataene uleselige, og agenten kan ikke overstyre den avgjørelsen.

Vi tester også om disse lagene holder. I Escaping SPACE: Part I ga vi ni frontiermodeller root-tilgang inne i en SPACE-sandbox og ba dem bryte ut. Ingen slapp unna virtuell maskin (VM), men noen fant veier rundt nettverkspolicyen når delvis nettverkstilgang var tillatt. Vi rettet disse hullene, bekreftet rettelsene i en ny test og avdekket lignende sårbarheter vi fant i åtte av ti andre sandbox-plattformer til leverandørene deres.

I nettleseren: Comet og BrowseSafe

Comet har brukt et lagdelt forsvar mot ledetekst-injeksjon siden lansering: klassifiseringsverktøy skanner hentet innhold, strukturerte ledetekster merker det som utrygt, sensitive handlinger som å sende en e-post eller legge inn en bestilling krever brukerens bekreftelse, og brukere blir informert når noe blir blokkert (Comet prompt-injection defenses). BrowseSafe, det åpne deteksjonsmodellen bak det første laget, presterer bedre enn frontiermodeller på vår BrowseSafe-Bench-benchmark, men den samme benchmarken viser at ingen detektor er feilfri, og det er derfor deteksjon aldri er det eneste laget (BrowseSafe research). Computer arver disse forsvarsmekanismene, som er blitt revidert av Trail of Bits (Perplexity).

På enheten: Portable Computer

Portable Computer er en lokalførst agent: modellen, harness-en, samtalen og banen forblir på brukerens maskin som standard. En deterministisk orkestrator, som er harness-kode snarere enn en LLM, kjører løkken og håndhever retningslinjer. Modellen foreslår handlinger, og godkjente verktøykall kjører i en sandbox på OS-nivå som begrenser prosesser, filbaner og nettverkstilgang. Sandbox-en er alltid på og feiler lukket: hvis den ikke er tilgjengelig, deaktiverer harness-en seg selv i stedet for å kjøre kommandoer med brukerens tillatelser. Handlinger som krysser enhetsgrensen, som netsøk, koblinger og eskalering til en sterkere sky-rådgivermodell, skjer bare når brukeren aktiverer og godkjenner dem. Før et rådgiverkall flagger en PII-klassifisering sensitiv informasjon, og brukeren ser hva som ville blitt sendt. Rådgiveren mottar bare denne godkjente konteksten og returnerer tekstveiledning, uten tilgang til enhetens filer eller verktøy.

På endepunktet: Numbat

Koderagenter på utvikleres bærbare datamaskiner kjører i timevis med tilgang til kildekoden, legitimasjon og produksjonssystemer. Numbat, vår åpne kildekode-pakke for agentsikkerhet, legger til et uavhengig lag som befinner seg utenfor en enkelt agent. Den fungerer sammen med harness-er som Claude Code, Codex, OpenCode og Pi, blokkerer farlige handlinger før de kjøres, flagger mistenkelige flertrinnssekvenser som å lese en hemmelighet og deretter sende data ut, og bevarer økttidslinjer for etterforskning. Numbat kjører på tvers av tusenvis av Perplexity-endepunkter sammen med Bumblebee, vår leverandørkjedeskanner med åpen kildekode. Computer gjennomgår jevnlig funnene deres og foreslår forbedrede deteksjonsregler, og et menneske godkjenner hver endring før den settes i produksjon.

En jobb for hele bransjen

Ettersom AI-agenter blir mer kapable og utbredt, må sikkerhetsteknikk forbli sentralt i deres utvikling og distribusjon. Forskere og ingeniører kan bygge videre på etablerte prinsipper, bruke funn fra den virkelige verden til å finpusse forsvar og teste sikkerhetstiltak på tvers av miljøene der agentene opererer. Sikkerhet er en pågående ingeniørdisiplin som utvikler seg side om side med teknologien.

Sikkerhetsteknikk for agenter er en jobb for hele bransjen. Ingen enkelt selskap kontrollerer hele stabelen en agent kjører på. Modellutviklere, harness-byggere, sandbox- og kjøretidsleverandører, sky- og maskinvareleverandører og bedriftssikkerhetsteam eier hvert sitt lag. Sikkerheten til helheten avhenger av at hvert lag holder når et annet svikter. Det er derfor vi bygger sikkerhetstiltak som fungerer på tvers av agent-harness-er og gjør verktøyene våre til åpen kildekode. Det er også derfor vi avslører sårbarhetene vi finner i andre plattformer, og deltar i initiativer som Open Secure AI Alliance.

For å arbeide sammen med det bredere miljøet om disse utfordringene lanserte Perplexity Secure Intelligence Institute i mars 2026 for å studere sikkerhet, pålitelighet og praktisk forsvar av ledende AI-systemer (Perplexity). Perplexity samarbeider for tiden med og/eller finansierer akademiske forskere ved Stanford, CMU, Duke, Columbia, Ohio State og University of Virginia. Vi utfører også intern forskning for å flytte grensene for agentrelatert sikkerhetsforskning, omsette disse fremskrittene i konkrete forbedringer i Perplexitys systemer, og dele kunnskap og ressurser som bidrar til å styrke det bredere AI-økosystemet. Tryggere agenter er noe bransjen kan konstruere. Vi har til hensikt å fortsette å gjøre vår del, og vi inviterer andre til å bygge sammen med oss.