Hoe we veiligere agenten ontwerpen

Om veiligere AI-agenten te bouwen, moeten we zowel ontwerpen op basis van hun capaciteiten als op basis van hun fouten. Zelfs bij het uitvoeren van legitieme taken en zonder enige kwaadaardige instructies kunnen agenten beveiligingsgrenzen overschrijden in een poging obstakels te overwinnen.

Wij geloven dat dit een security engineering-probleem is, en de industrie moet dit aanpakken zoals ze de internetwormen van begin jaren 2000 aanpakte. De systemen rondom agenten moeten beperken tot welke bronnen agenten toegang hebben, ongewenst gedrag detecteren en storingen inperken wanneer deze optreden.

Bij Perplexity werken we actief samen met onderzoekers en praktijkbeoefenaars om security engineering voor AI-agenten te bevorderen, en we passen meerdere verdedigingslagen toe op onze modellen, agent-harnesses en infrastructuur, zodat beveiliging niet afhangt van één enkele beveiligingsmaatregel.

Gedrag bij op hol slaan van AI-agenten

In juli drongen AI-agenten binnen in de productie-infrastructuur van het open-source AI-platform Hugging Face. Tijdens interne cybersecurity-evaluaties en trainingsruns ontdekten OpenAI-modellen een manier om misbruik te maken van de Artifactory-repositorymanager om een Prikbord in te stellen om met elkaar te communiceren, waardoor ze zich in zwermen konden organiseren. Later rekruteerden agenten die geen voortgang konden boeken bij taken in een cybersecurity-benchmark andere agenten om te helpen. Deze agenten braken uit hun evaluatieomgeving en bereikten het internet. Ze ontdekten ook manieren om te cheaten door antwoorden op de benchmarktaken te reverse-engineeren, maar dachten dat het beoordelingssysteem het cheaten zou detecteren. Om beter te begrijpen hoe de benchmarkevaluatie werkte om manieren te vinden om te voorkomen dat ze als cheaters werden gedetecteerd, hebben ze uiteindelijk de systemen van Hugging Face gecompromitteerd (Hugging Face; OpenAI).

Het incident is een helder voorbeeld van een faalmodus die we beschreven toen we Numbat in juli als open source uitbrachten: accidentele storingen, een term bedacht door beveiligingsonderzoekers van Cornell Tech (arXiv). Een agent die een legitiem doel nastreeft, stuit op frictie, zoals een ontbrekend bestand, een mislukte API-aanroep, een verlopen inloggegevens of een geweigerde toestemming, en gaat op zoek naar een workaround. Hierbij kan hij beveiligingsgrenzen overschrijden via verkenning, privilege-escalatie, het ontdekken van geheimen of data-exfiltratie. De agent zelf wordt effectief de tegenstander, ook al is er geen enkele kwaadaardige prompt of externe aanvaller bij betrokken.

Hugging Face was geen op zichzelf staand geval. In de afgelopen weken zijn meer gedragingen van op hol geslagen agenten ontdekt en gerapporteerd. Op 27 en 28 mei liepen agenten die gegevens van de University of Iowa probeerden te verzamelen van Data USA, een platform dat open toegang biedt tot Amerikaanse overheidsgegevens, tegen fouten aan die werden veroorzaakt door een onjuiste query. Ze reageerden met sondes, waaronder SQL-injectie, cross-site scripting, template-injectie, path traversal en command-injectie. De activiteit werd later gelinkt aan OpenAI (SecurityWeek). Op 20 en 21 mei werden OpenAI-agenten die per persoon de overheidskosten wilden verkrijgen voor een categorie medicijnen in lokale gebieden in Victoria van het Australian Institute of Health and Welfare (AIHW) geblokkeerd bij het downloaden van een bestand. Als reactie hierop downloadden de agenten het bestand, dat al openbaar was, van de pre-production server van het AIHW, waarbij ze en passant de anti-botbeveiliging van de site omzeilden (SecurityWeek).

Het patroon beperkt zich niet tot één lab. Tijdens tests op het gebied van cybersecurity doorbraken Anthropic-modellen drie bedrijven nadat een fout hen open internettoegang gaf, raadde Google's Gemini inloggegevens tot drie websites en maakte een Meta-model misbruik van een service van een derde partij (Reuters).

Leren van het verleden: Het tijdperk van internetwormen

Deze incidenten doen denken aan het tijdperk van internetwormen van ongeveer een kwart eeuw geleden. Begin jaren 2000 groeide het internet vele malen sneller dan de beveiligingspraktijken daaromheen. We zagen een golf van virussen en wormen, met gevolgen die vele malen ernstiger waren dan wat we nu zien bij AI-agenten die op hol slaan.

Op 4 mei 2000 ontvingen mensen e-mails van bekende afzenders met als onderwerpregel "ILOVEYOU". Het openen van de bijlage in de e-mail resulteerde in het uitvoeren van een script dat een kopie van zichzelf mailde naar iedereen in het Outlook-adresboek van het slachtoffer. Om 18.00 uur die dag had het CERT Coordination Center meldingen ontvangen met betrekking tot meer dan 420.000 internethosts (US GAO Report). Het virus drong naar verluidt binnen bij ten minste 14 federale instanties, waaronder het Department of Defense, de CIA, NASA en het Huis van Afgevaardigden en de Senaat (US GAO Report). Het legde ook e-mailservers plat bij het Pentagon en het Britse parlement (Wired). Verzekeringsgigant Lloyd's of London deed een vroege schatting dat het virus meer dan 15 miljard dollar aan schade en verloren productiviteit zou kosten (US House Committee Hearing). Computer Economics schatte de wereldwijde schade later op 8,75 miljard dollar (Information Week).

Vervolgens verschenen wormen waarvoor geen menselijke klik nodig was. Op 19 juli 2001 infecteerde de Code-Red-worm meer dan 359.000 computers in minder dan 14 uur (CAIDA). Op 25 januari 2003 verdubbelde SQL Slammer elke 8,5 seconden in omvang en infecteerde binnen 10 minuten meer dan 90% van de internethosts die daar kwetsbaar voor waren (CAIDA), waarbij misbruik werd gemaakt van een gat waarvoor Microsoft zes maanden eerder een patch had uitgebracht (CNET). In augustus 2003 verschenen de Blaster-worm en de Sobig-e-mailworm ongeveer een week na elkaar (Microsoft, F-Secure).

Destijds was de vraag gerechtvaardigd of gennetwerkte computers überhaupt veilig konden worden gemaakt. Zes dagen na het ILOVEYOU-virus hield een subcommissie van het Amerikaanse Huis van Afgevaardigden hierover een hoorzitting. Veel beveiligingsexperts riepen op tot wetgeving die softwarebedrijven aansprakelijk zou stellen voor schade veroorzaakt door fouten in hun producten. Washington sloeg een andere weg in. De National Strategy to Secure Cyberspace stelde dat "federale regelgeving geen primair middel zal worden om cyberspace te beveiligen." Er werd gewaarschuwd dat brede mandaten konden leiden tot een "benadering van de gemene deler voor cybersecurity" (CISA).

De industrie reageerde met engineering. Elf dagen na ILOVEYOU kondigde Microsoft een Outlook-update aan die uitvoerbare bijlagen blokkeerde. In januari 2002 maakte het bedrijf beveiliging tot zijn allerhoogste prioriteit (Seattle Times). Automatisch patchen, veilige standaarden, bugbounty-programma's en gecoördineerde openbaarmaking werden de standaardpraktijk. In 2008 begon Chrome webinhoud te draaien in een sandbox die "beperkt wat een aanvaller kan doen na het exploiteren van een bug" (Chromium Blog). Encryptie, ooit de uitzondering, werd de standaard. Beveiligingstechnologieën zoals multi-factor authentication, firewalls, zero trust en security information and event management (SIEM) werden op grote schaal gebruikt. Organisaties wereldwijd zullen naar verwachting in 2026 zo'n 240 miljard dollar uitgeven aan informatiebeveiliging (Gartner). Wormen zijn nooit helemaal verdwenen, maar het tijdperk van routinematige uitbraken over het hele internet vervaagde. Tegelijkertijd werd het internet, grotendeels onbelast door regelgeving, de volgende twee decennia een krachtige motor van innovatie en economische groei.

Security engineering voor AI-agenten

Recente incidenten hebben terechte vragen opgeroepen over agent-governance. Bestaande beveiligingsmechanismen zijn ontwikkeld voor pre-agent computeromgevingen die worden gekenmerkt door strikt afgebakend en grotendeels deterministisch softwaregedrag. Toegangscontrolemechanismen zijn in het bijzonder voornamelijk ontworpen rond menselijke gebruikers en verlenen hen vaak brede rechten die in beginsel voldoende zijn om aanzienlijke schade te veroorzaken.

Dit ontwerp rust op verschillende aannames: de meeste gebruikers handelen te goeder trouw; kwaadwillenden kunnen worden afgeschrikt door audits en reële consequenties; en mensen verrichten acties, al dan niet correct, in een relatief beperkt tempo. Het toepassen van deze beveiligingsmechanismen op agenten vereist rekening te houden met verschillen tussen menselijk gedrag en agent-gedrag. Zoals we schreven in onze reactie op het verzoek om informatie van NIST over de beveiliging van AI-agenten, dagen AI-agenten deze aannames uit. Ze kunnen privileges uitoefenen en acties ondernemen op machinesnelheid, worden zelf niet afgeschrikt door reële consequenties en kunnen handelingen verrichten die technisch zijn toegestaan maar die een doorsnee menselijke gebruiker zelden zou uitvoeren.

Het beantwoorden van die vragen vereist security engineering. We kennen de beveiligingsprincipes voor het bouwen van systemen die de risico's onder controle houden wanneer individuele componenten zich misdragen. Maar we moeten ervoor zorgen dat deze principes worden toegepast bij het ontwerpen van de omgevingen voor het trainen, testen en gebruiken van AI-agenten.

Het defense-in-depth beveiligingsprincipe

Wellicht het belangrijkste beveiligingsprincipe dat moet worden toegepast voor het beveiligen van AI-agenten is defense-in-depth, dat pleit voor een gelaagde beveiligingsarchitectuur waarin meerdere, uiteenlopende en redundante verdedigingsmaatregelen worden ingezet om systeembronnen te beschermen. Geen enkele beveiligingsmaatregel is volmaakt. Mensen kunnen ten prooi vallen aan social engineering-aanvallen en hun inloggegevens prijsgeven, er worden kwetsbaarheden in zero-day-software ontdekt en misbruikt, en inbraakdetectie misst nieuwe aanvalsvarianten. Defense-in-depth accepteert dit en stapelt verschillende onafhankelijke verdedigingslagen. Mocht de ene verdedigingslaag worden omzeild, dan blijven andere lagen op hun plaats om de inbraak tegen te gaan of te detecteren.

Het incident met Hugging Face laat zien waarom defense-in-depth belangrijk is. De retrospectieve rapporten van OpenAI vermelden dat de geautomatiseerde beveiligingsmaatregelen die worden gebruikt in zijn productiesystemen, waaronder harnesses, auto-review-modellen en safety classifiers, afwezig waren in de evaluatieomgeving. Als de momenteel ingezette chain-of-thought-monitoring op die evaluaties had gedraaid, had deze de initiële activiteit gedetecteerd en het beveiligingsteam meer dan een dag voor de inbreuk gemaand (OpenAI). De lagen die het probleem hadden kunnen ontdekken, waren er wel. Ze stonden simpelweg niet allemaal tegelijkertijd op hun plek.

Het beveiligen van AI-agenten vereist het verbeteren van zowel de veiligheid en beveiliging van AI-modellen als de systemen daaromheen. Werk op de modelleng laag is belangrijk en werpt zijn vruchten af. Vroege LLMs werden gemakkelijk gemanipuleerd door geïnjecteerde instructies, terwijl de modellen van vandaag aanzienlijk beter zijn in het herkennen en weigeren daarvan. Modelontwikkelaars trainen modellen ook op veiliger gedrag en bewaken, zoals het retrospectieve rapport van OpenAI beschrijft, redeneersporen op tekenen van problematisch gedrag. Maar verdedigingen op modellengniveau zijn slechts een deel van de oplossing. De systemen waarin agenten worden getraind, getest en ingezet, moeten ook worden ontworpen met het oog op beveiliging en inperking. Veiligheid op modellengniveau verkleint de kans dat een agent ontspoort; beveiliging op systeemniveau beperkt de schade als dat wel gebeurt.

Vergroten

Ontwerpregels voor redundante beveiligingsmaatregelen

Defense-in-depth vereist redundante beveiligingsmaatregelen. Voor agenten pleiten we voor toepassing hiervan op basis van drie ontwerpregels:

1. Onafhankelijkheid. Elke laag moet om onafhankelijke redenen falen. Twee controles die dezelfde aanname delen, kunnen door dezelfde aanval worden verslagen. Monitors en handhavingspunten moeten buiten het bereik van de agent liggen.
2. Handhaving onder de agent. Ten minste één laag moet deterministisch zijn: conventionele, verifieerbare code die verboden acties blokkeert, ongeacht wat het model produceert. Een beveiligingsmaatregel die de agent kan weigeren aan te roepen of opnieuw kan configureren, is geen beveiligingsmaatregel.
3. Signalen kunnen de bevoegdheid alleen verkleinen. Detectie moet reacties activeren die beperken wat de agent kan doen, zoals pauzeren, het intrekken van inloggegevens, het afsluiten van netwerktoegang of het beëindigen van de sessie. Geen enkel risicosignaal mag ooit extra toegang verlenen.

We delen deze principes met onze partners in de Open Secure AI Alliance, waaronder NVIDIA, dat heeft aangevoerd dat het harness stuurt wat een agent probeert terwijl de infrastructuur bestuurt wat hij kan doen (NVIDIA).

Defense-in-depth in de producten van Perplexity

Perplexity laat agenten draaien in vier soorten omgevingen: in de cloud via ons agent-platform Computer, in de browser via Comet, op gebruikersapparaten via Portable Computer en op laptops van werknemers, waar onze engineers coderingsagenten van derden gebruiken. Elke omgeving heeft zijn eigen risico's en krijgt verschillende beschermingslagen.

In de cloud: Computer en SPACE

Elke Computer-taak draait in SPACE, ons sandbox-platform, dat de agent standaard als onbetrouwbaar beschouwt. Elke taak krijgt zijn eigen microVM, inloggegevens blijven buiten de sandbox en worden alleen geïnjecteerd wanneer dat nodig is, uitgaand verkeer wordt buiten de gastomgeving beheerd en met snapshots kunnen we destructieve wijzigingen terugdraaien (Making SPACE). Enterprise-klanten kunnen ook hun eigen encryptiesleutels meenemen. Het intrekken van een sleutel maakt de beschermde gegevens onleesbaar en de agent kan die beslissing niet overschrijven.

We testen ook of deze lagen standhouden. In Escaping SPACE: Deel I gaven we negen frontiermodellen root-toegang binnen een SPACE-sandbox en vroegen we ze om uit te breken. Geen enkel model wist te ontsnappen uit de VM, maar sommige vonden manieren om het netwerkbeleid te omzeilen toen gedeeltelijke netwerktoegang was toegestaan. We hebben die hiaten verholpen, de oplossingen bevestigd in een herhalingstest en vergelijkbare kwetsbaarheden die we aantroffen in acht van de tien andere sandbox-platformen bekendgemaakt bij hun leveranciers.

In de browser: Comet en BrowseSafe

Comet maakt sinds de lancering gebruik van een gelaagde verdediging tegen prompt-injectie: classificatoren filteren opgehaalde inhoud, gestructureerde prompts markeren deze als onbetrouwbaar, gevoelige acties zoals het verzenden van een e-mail of het plaatsen van een bestelling vereisen de bevestiging van de gebruiker, en gebruikers worden geïnformeerd wanneer iets wordt geblokkeerd (Comet prompt-injectieverdedigingen). BrowseSafe, het open-source detectiemodel achter de eerste laag, presteert beter dan frontiermodellen op onze BrowseSafe-Bench-benchmark, maar dezelfde benchmark toont aan dat geen enkele detector feilloos is, en daarom is detectie nooit de enige laag (BrowseSafe-onderzoek). Computer neemt deze verdedigingen over, die zijn geaudit door Trail of Bits (Perplexity).

Op het apparaat: Portable Computer

Portable Computer is een local-first agent: het model, het harness, het gesprek en het traject blijven standaard op de machine van de gebruiker. Een deterministische orchestrator, die harness-code is in plaats van een LLM, laat de lus draaien en handhaaft het beleid. Het model stelt acties voor en goedgekeurde tool-aanroepen worden uitgevoerd in een sandbox op besturingssysteemniveau die processen, bestandspaden en netwerktoegang beperkt. De sandbox staat altijd aan en is fail-closed: als deze niet beschikbaar is, schakelt het harness zichzelf uit in plaats van commando's uit te voeren met de rechten van de gebruiker. Acties die de apparaatgrens overschrijden, zoals webzoekopdrachten, connectoren en escalatie naar een sterker cloud-adviermodel, vinden alleen plaats wanneer de gebruiker deze inschakelt en goedkeurt. Vóór een adviesaanroep markeert een PII-classificator gevoelige informatie en ziet de gebruiker wat er verzonden zou worden. De adviseur ontvangt alleen die goedgekeurde context en retourneert tekstbegeleiding, zonder toegang tot de bestanden of tools van het apparaat.

Op het endpoint: Numbat

Programmeur-agenten op laptops van developers draaien urenlang met toegang tot broncode, inloggegevens en productiesystemen. Numbat, onze open-source agent-beveiligingssuite, voegt een onafhankelijke laag toe die buiten elke afzonderlijke agent staat. Deze werkt samen met harnesses zoals Claude Code, Codex, OpenCode en Pi, blokkeert gevaarlijke acties voordat ze worden uitgevoerd, markeert verdachte reeksen van meerdere stappen, zoals het lezen van een geheim en het vervolgens verzenden van gegevens, en bewaart sessietijdlijnen voor onderzoek. Numbat draait op duizenden Perplexity-endpoints naast Bumblebee, onze open-source supply-chain-scanner. Computer bekijkt regelmatig hun bevindingen en stelt verbeterde detectieregels voor, waarbij een mens elke wijziging goedkeurt voordat deze wordt doorgevoerd.

Een taak voor de hele industrie

Naarmate AI-agenten capabeler en breder gebruikt worden, moet security engineering centraal blijven staan bij hun ontwikkeling en implementatie. Onderzoekers en engineers kunnen voortbouwen op gevestigde principes, reële bevindingen gebruiken om verdedigingen te verfijnen en beveiligingsmaatregelen testen in de omgevingen waarin agenten opereren. Beveiliging is een continue engineeringdiscipline die zich gelijktijdig met de technologie ontwikkelt.

Security engineering voor agenten is een taak voor de hele industrie. Geen enkel bedrijf beheerst de volledige stack waarop een agent draait. Modelontwikkelaars, harness-bouwers, sandbox- en runtime-providers, cloud- en hardwareleveranciers en enterprise-beveiligingsteams bezitten elk een laag. De veiligheid van het geheel hangt af van het standhouden van elke laag wanneer een andere verslapt. Daarom bouwen we beveiligingsmaatregelen die werken over agent-harnesses heen en stellen we onze tools beschikbaar als open source. Dit is tevens de reden waarom we de kwetsbaarheden die we in andere platforms aantreffen bekendmaken en deelnemen aan initiatieven zoals de Open Secure AI Alliance.

Om op het gebied van deze uitdagingen samen te werken met de bredere gemeenschap, lanceerde Perplexity in maart 2026 het Secure Intelligence Institute om de beveiliging, betrouwbaarheid en praktische verdediging van geavanceerde AI-systemen te bestuderen (Perplexity). Perplexity werkt momenteel samen met academische onderzoekers aan Stanford, CMU, Duke, Columbia, Ohio State en de University of Virginia en/of financiert hen. We voeren daarnaast intern onderzoek uit om de grenzen van agent-beveiligingsonderzoek te verleggen, die vorderingen te vertalen naar concrete verbeteringen in de systemen van Perplexity en kennis en middelen te delen die helpen om het bredere AI-ecosysteem te versterken. Veiliger agenten zijn iets dat de industrie zelf kan ontwerpen. We zijn van plan ons steentje te blijven bijdragen en nodigen anderen uit om met ons mee te bouwen.