AI-agent beveiligen: promptfilters zijn onvoldoende

Een AI-agent die externe documenten leest en tools aanroept, heeft meer nodig dan een promptfilter. Behandel opgehaalde inhoud als onvertrouwde gegevens, beperk de rechten van de agent en laat een afzonderlijke beleidscontrole gevoelige acties beoordelen. Volgens de OWASP-richtlijn voor promptinjectie kan ook een aanvullend guardrailmodel worden misleid; filtering vervangt daarom geen technische toegangscontrole of menselijke goedkeuring.

Begin bij de schade die de agent met zijn huidige toegang kan aanrichten. De OWASP-richtlijn voor AI-agenten noemt naast promptinjectie ook toolmisbruik, privilege-escalatie, gegevenslekken, geheugenvergiftiging en buitensporige autonomie. Een agent die informatie samenvat, heeft andere grenzen nodig dan een agent die berichten verstuurt of bestanden wijzigt. Leg per taak vast welke bronnen, bewerkingen en uitgaande verbindingen noodzakelijk zijn.

Houd externe inhoud buiten de instructielaag

Een webpagina, e-mailbijlage, zoekresultaat of API-antwoord kan tekst bevatten die zich voordoet als een opdracht. Geef zulke inhoud de status van bronmateriaal: bewaar de herkomst, plaats de inhoud in een afzonderlijk gegevensveld en haal systeeminstructies uitsluitend uit een vertrouwde configuratie. Scheiding in de prompt helpt het model het onderscheid te zien; de toepassing moet die grens ook bij opslag en toolaanroepen handhaven.

Controleer formaat, omvang en verwachte velden voordat inhoud de context ingaat. Verwijder opmaak of verborgen elementen die de taak niet vereist, en gebruik een filter op bekende aanvalspatronen als extra signaal. Een document dat het filter passeert, krijgt daarmee geen hogere vertrouwensstatus. Als de agent informatie voor latere sessies onthoudt, controleer dan ook wat hij opslaat: beperk de omvang en bewaartermijn, scheid gebruikers van elkaar en voorkom dat een instructie uit een document een blijvende voorkeur wordt.

Beperk de rechten van elke tool

Maak per agenttaak een expliciete lijst van toegestane tools en bewerkingen. Een agent die rapporten samenvat, kan bijvoorbeeld leesrechten krijgen op een afgebakende map, zonder schrijf- of verwijderrechten. Gebruik afzonderlijke identiteiten en toegangsgegevens voor taken met verschillende bevoegdheden. Daarmee kan een injectie in een leestaak niet via dezelfde identiteit een beheerdersfunctie bereiken.

Beperk naast bestandsrechten ook API-routes en netwerkbestemmingen. Laat de uitvoerende component autorisatie toetsen aan de gebruiker, de taak en de doelbron. Modeluitvoer is daarbij een verzoek om een actie, geen bewijs van toestemming. Controleer toolnaam en parameters met vaste regels voor bewerking, bestemming, gegevenscategorie en toegestane omvang. Een zin als ‘de gebruiker heeft toestemming gegeven’ mag die controle niet vervangen; weiger onbekende tools en ontbrekende beleidsgegevens.

Laat gevoelige acties apart goedkeuren

Laat de agent een actie met merkbare gevolgen eerst als concreet voorstel indienen: welke tool wordt gebruikt, wat is de bestemming, welke gegevens gaan mee en wat verandert er? Een afzonderlijke beleidslaag beslist of het voorstel binnen de verleende rechten valt. Voor het versturen van externe berichten, het wijzigen van toegangsrechten of het verwijderen van gegevens is expliciete menselijke goedkeuring passend. Toon de beoordelaar de werkelijke bestemming en parameters, zodat de beslissing niet alleen op een samenvatting van de agent berust.

Koppel de goedkeuring aan precies dat voorstel en geef haar een beperkte geldigheidsduur. Veranderen de bestemming of de inhoud daarna, dan is opnieuw goedkeuring nodig. Registreer wie toestemming gaf en laat de uitvoerende component die toestemming vlak voor de toolaanroep onafhankelijk controleren. Bij een fout in autorisatie of goedkeuring blijft de actie geblokkeerd. Zo kan geïnjecteerde tekst een voorstel beïnvloeden, maar niet op eigen kracht de uitvoeringsgrens passeren.

Leg beslissingen vast en test de grenzen

Registreer per sessie welke bron de agent gebruikte, welke tool hij wilde aanroepen, welke beleidsregel besliste, of goedkeuring vereist was en wat de uitvoering opleverde. Bewaar ook de gebruikte beleidsversie. Daarmee is zichtbaar of een document onverwacht tot een uitgaande actie leidt en welke regels op dat moment golden. Stel waarschuwingen in voor herhaalde weigeringen, ongebruikelijke bestemmingen en opvallend veel toolaanroepen.

Logs kunnen zelf vertrouwelijke gegevens bevatten. Beperk daarom de toegang, bescherm ze tegen wijziging en sla geheimen of volledige parameters alleen op als die werkelijk nodig zijn voor onderzoek. Test met doelbewust gemanipuleerde documenten of weigeringen, goedkeuringsverzoeken en waarschuwingen in de logs verschijnen. Herhaal die tests na wijzigingen aan tools, zoek- of ophaalfuncties, geheugen en beleid. Test ook dat een verlopen goedkeuring of een gewijzigde bestemming daadwerkelijk tot een weigering leidt.

Oefen een noodstop voor de hele keten

Een noodstop moet nieuwe acties tegenhouden zodra de agent afwijkend gedrag vertoont. Het advies van het Britse NCSC noemt naast het stilleggen van agentprocessen ook het snel beperken van netwerktoegang en het onderbreken van de communicatie tussen geselecteerde agenten en de modelinfrastructuur. Andere onderdelen van de keten kunnen immers nog opdrachten verwerken wanneer alleen het agentproces stopt.

Wijs vooraf aan wie de stop kan activeren en welke systemen de ingreep raakt. Oefen met een veilige testaanroep: controleer of geplande toolacties niet meer starten, uitgaande verbindingen worden geblokkeerd en de gebeurtenis zichtbaar blijft in de logs. Leg ook vast wie de toegang weer mag herstellen en welke controles daaraan voorafgaan. De oefening laat zien of de technische grenzen blijven werken wanneer een kwaadaardige instructie door de detectie glipt.