De AI-agent veiligheidschecklist: 9 vangrails om te verifiëren voordat u een agent zelfstandig laat handelen

Voordat u een AI-agent zelfstandig laat handelen, verifieert u negen vangrails. De eerste vier brengen elke actie die de agent kan uitvoeren in kaart met een risicobeoordeling, zodat de onomkeerbare, gevoelige en kostbare acties altijd pauzeren voor een mens. De volgende vijf bevestigen de omgeving die de agent inperkt wanneer een filter wordt misleid: een unieke agentidentiteit, minimale rechten, een sandbox, beperkt netwerkverkeer naar buiten en auditlogboeken op actieniveau. De actiekaart vertelt u wat veilig te automatiseren is. De omgeving is wat de grens daadwerkelijk vasthoudt, want de inhoudsfilters waarop de meeste checklists leunen zijn de laag die faalt precies wanneer het ertoe doet. Loop alle negen door als ja-of-nee-vragen, en als een antwoord nee is of "we weten het niet zeker", is de agent niet klaar om zonder toezicht te draaien.

Dit is de audit vóór de lancering die wij uitvoeren voordat we een door ons gebouwde agent zelfstandig laten handelen binnen een ander bedrijf, geschreven zodat ook een niet-technische eigenaar hem kan uitvoeren, op de eigen agent of die van een leverancier. Als u liever heeft dat wij dit voor u doen, bekijk dan hoe wij verantwoorde AI-governance en risico aanpakken. Alles hieronder mag u gebruiken.

Hoe moet ik deze checklist gebruiken?

Behandel hem als een controle voor vertrek, niet als een filosofie. Neem de agent die u op het punt staat in te zetten (of degene die een leverancier u verkoopt) en beantwoord elk van de negen punten met een hard ja of nee. Een "grotendeels" is een nee. Het doel is om de hiaten aan het licht te brengen voordat de agent iets echts raakt.

De negen splitsen zich in twee groepen die verschillend werk doen:

• Punten 1 tot en met 4 (de actiekaart). Deze bepalen wat de agent zonder te vragen mag doen, en wat moet stoppen voor een mens. Dit is een oordeel over risico, en het is het deel dat de meeste gidsen behandelen.
• Punten 5 tot en met 9 (de omgeving). Deze begrenzen wat de agent überhaupt kan bereiken en doen, ongeacht wat hem werd opgedragen. Dit is het deel dat de meeste checklists overslaan, en het is het deel dat een agent inperkt wanneer een filter wordt misleid.

Beide groepen zijn belangrijk, maar ze falen verschillend. De actiekaart gaat over correct beslissen. De omgeving gaat over het overleven van een verkeerde beslissing. U heeft beide nodig, want geen enkel filter vangt alles: de productie-automode-classifier van Anthropic, een van de beste die er is, mist nog steeds ongeveer 17% van de overijverige agentacties, zelfs wanneer hij zo is afgesteld dat hij vrijwel nooit een legitieme opdracht blokkeert. Een misspercentage van 17% is prima met nog een laag erachter en roekeloos wanneer het het enige is tussen de agent en uw geld.

Punten 1 tot en met 4: heeft u elke actie in kaart gebracht met een risicobeoordeling?

U kunt niet afgrendelen wat u niet hebt opgesomd. Begin met het opschrijven van elke actie die de agent kan uitvoeren en beoordeel er vervolgens elk. De agentgids van OpenAI geeft de helderste beoordelingsmethode: scoor elke actie laag, gemiddeld of hoog op vier factoren.

Vangrail 1: Heeft u elke actie opgesomd en beoordeeld als laag, gemiddeld of hoog? Als er een actie op de lijst staat die niemand heeft beoordeeld, is dat degene die u pijn doet. De beoordeling sorteert vrijwel alles in drie groepen:

Vangrail 2: Pauzeert elke actie met hoog risico voor expliciete menselijke goedkeuring voordat ze wordt uitgevoerd? Dit is de enige regel die de slechtste uitkomsten voorkomt. OpenAI noemt precies deze als de acties die menselijke ondertekening verdienen: orders annuleren, grote terugbetalingen autoriseren en betalingen doen. Voeg daar verwijderingen, toegangsverleningen en elk bericht dat het gebouw verlaat aan toe. Een terugbetalingsagent mag elke order lezen die hij wil, maar mag nooit geld boven een kleine drempel verplaatsen zonder dat een mens op goedkeuren klikt.

Vangrail 3: Is de goedkeuringspoort zeldzaam genoeg zodat mensen hem nog steeds lezen? De valkuil is de agent over alles te laten vragen. Doet u dat, dan heeft u een slechter systeem gebouwd, geen veiliger. Anthropic mat dat gebruikers ongeveer 93% van de toestemmingsverzoeken goedkeuren, dus een poort die veertig keer per dag in werking treedt is theater: de mens zit nominaal in de lus maar is gestopt met kijken. Verifieer drie dingen: de agent vraagt alleen om werkelijk risicovolle acties, het verzoek vermeldt de consequentie in gewone taal ("Betaal € 1.000 terug aan account X"), en stilte staat standaard op "nee", nooit op "ja".

Vangrail 4: Stopt de agent en vraagt hij om hulp wanneer hij blijft falen? Een verwarde agent die in een lus van nieuwe pogingen blijft hangen is een eigen soort risico. Stel een faaldrempel in, zodat de agent na een vast aantal mislukte pogingen stilstaat en escaleert in plaats van te blijven worstelen. OpenAI noemt precies twee triggers voor menselijke tussenkomst: het overschrijden van faaldrempels en acties met hoog risico. U hebt zojuist beide afgedekt.

Punten 5 tot en met 9: heeft u de omgeving geverifieerd die de agent inperkt?

Hier is het deel dat de generieke checklists overslaan, en het is het deel dat het zware werk doet. Punten 1 tot en met 4 gaan ervan uit dat de agent correct beslist. Punten 5 tot en met 9 gaan ervan uit dat hij dat soms niet doet, en begrenzen de schade wanneer dat gebeurt.

De reden dat deze groep ertoe doet is het meest onderbelichte feit in agentveiligheid: inhoudsfilters falen juist wanneer de schadelijke instructie er legitiem uitziet. Anthropic voerde een test uit waarbij een medewerker werd gephisht, zodat de kwaadaardige instructie afkomstig was van de vertrouwde gebruiker die de agent geacht werd te bedienen. Over 25 nieuwe pogingen voltooide de agent 24 keer diefstal van inloggegevens, omdat, in hun woorden, wanneer de gebruiker de instructie typt er niets afwijkends is voor een classifier om op te merken. Het enige wat het betrouwbaar stopte was omgevingsgebonden: het blokkeren van het netwerkverkeer van de agent naar buiten, zodat de gestolen gegevens nergens heen konden. Filters gokken op de intentie. De omgeving neemt het vermogen weg. Vermogen is wat u daadwerkelijk kunt beheersen.

Vangrail 5: Heeft de agent een eigen identiteit, geen gedeelde adminsleutel? Elke agent moet draaien onder een unieke identiteit, nooit een gedeelde inloggegeven en nooit de adminlogin van een mens. Een gedeelde sleutel betekent dat u niet kunt zien welke agent wat deed, en een inbreuk verspreidt zich overal waar die sleutel reikt. Een unieke identiteit is ook wat het auditlogboek in vangrail 9 betekenisvol maakt.

Vangrail 6: Is die identiteit afgestemd op minimale rechten? De agent krijgt de smalste set rechten die zijn taak daadwerkelijk nodig heeft, en niets meer. Een supportagent die terugbetalingen uitvoert zou niet ook uw klantendatabase moeten kunnen exporteren of de loonadministratie wijzigen. Als hij wordt misleid, wordt de schade begrensd door wat hem werd toegekend, niet door de vraag of een filter de truc opving. Gebruik de minst krachtige toegang die werkt: alleen-lezen verslaat lezen-schrijven, en lezen-schrijven-zonder-verwijderen verslaat volledige toegang.

Vangrail 7: Draait de agent in een sandbox? De agent moet werken binnen een geïsoleerde omgeving die is gebouwd op gevestigde, beproefde isolatie (dezelfde containers en sandboxen die worden gebruikt om niet-vertrouwde code te draaien), niet iets zelfgebouwds. Zoals Anthropic opmerkt, hebben die bouwstenen veel meer vijandige aandacht overleefd dan wat u zelf zou bouwen. Stem de inperking ook af op de gebruiker: een ontwikkelaar die code kan lezen en uitvoeren en een supportmedewerker die dat niet kan zijn niet hetzelfde dreigingsmodel, en hoe krachtiger de tools, hoe strakker de doos.

Vangrail 8: Is het netwerkverkeer van de agent naar buiten beperkt en afgestemd op vermogen? Dit is de controle die de phishingaanval hierboven stopte. Maar een simpele lijst met "toegestane domeinen" is op zichzelf niet genoeg. Anthropic leerde op de harde manier dat aanvallers bestanden exfiltreerden via een toegestaan domein door ze naar hun eigen account daarop te routeren, dus beschouw verkeersregels als toekenningen van vermogen (wat de agent mag doen) in plaats van slechts een lijst met adressen die hij mag bereiken.

Vangrail 9: Wordt elke actie gelogd op actieniveau voor audit? U kunt niet besturen wat u niet kunt zien. Elke actie die de agent uitvoert, vooral de acties met hoog risico, moet worden vastgelegd met genoeg detail om te reconstrueren wat er gebeurde, wie of wat het in gang zette en wat het raakte. Logboeken op actieniveau zijn hoe u een traag probleem opmerkt voordat het een krantenkop wordt, en hoe u de andere acht vangrails in de loop van de tijd aanscherpt.

Hoe ziet de voltooide checklist eruit?

Hier zijn de negen op één plek, elk geformuleerd als een ja of nee dat u kunt verifiëren. Een nee is een hiaat om te dichten vóór de lancering, geen voetnoot.

Let op de vorm. De eerste vier zijn beslissingen die u neemt over risico; de laatste vijf zijn controles die u in de omgeving inbouwt. De eerste vier kunnen worden misleid. De laatste vijf kunnen er niet van worden weggepraat hun werk te doen, en daarom zijn ze niet onderhandelbaar, zelfs wanneer het model uitstekend is.

Hoe voer ik deze audit uit op de agent van een leverancier?

Dezelfde negen vragen werken net zo goed op andermans agent, en ze zijn de snelste manier om een ingeperkt product te onderscheiden van een zelfverzekerde demo. Een demo bewijst dat de agent werkt op een goede dag. De checklist bewijst wat er gebeurt op een slechte.

Vraag de leverancier om deze in gewone taal te beantwoorden:

• Welke van mijn acties vereisen menselijke goedkeuring voordat ze worden uitgevoerd? Een leverancier die ze niet kan noemen heeft ze niet beoordeeld.
• Krijgt de agent een eigen identiteit met minimale rechten, of gebruikt hij een gedeelde sleutel in mijn systemen? Het tweede antwoord is een alarmsignaal.
• Draait hij in een sandbox, en wat kan hij op het netwerk bereiken? "Hij kan het internet bereiken" is geen antwoord.
• Wordt elke actie gelogd, en kan ik die logboeken zien? Als u het niet kunt auditen, kunt u het niet besturen.
• Hoe groot is de schade als de agent wordt misleid? Het eerlijke antwoord is een lijst van wat hij kan raken, niet een belofte dat het nooit zal gebeuren.

Als de antwoorden vaag zijn, of geheel steunen op "het model gedraagt zich netjes", is de agent niet ingeperkt, hoe goed de demo er ook uitzag. Een goede leverancier heeft de antwoorden klaarliggen, want dit zijn dezelfde vragen die ze zichzelf hadden moeten stellen.

Waarom doet dit er nu toe?

Omdat de kloof tussen teams die deze audit doorstaan en teams die hem overslaan op het punt staat zichtbaar te worden in de cijfers. Gartner verwacht dat meer dan 40% van de agentische AI-projecten tegen eind 2027 wordt geannuleerd, met ontoereikende risicocontroles als een van de genoemde oorzaken, en voorspelt dat tegen 2028 25% van de generatieve AI-toepassingen in ondernemingen minstens vijf kleine beveiligingsincidenten per jaar zal kennen, tegenover 9% in 2025. Vangrails verschuiven van een configuratie-instelling naar een begroot controlevlak, en de bovenstaande audit is hoe u aan de goede kant van die verschuiving blijft.

Het bemoedigende deel is dat niets hiervan exotisch is. Breng elke actie in kaart met een risicobeoordeling en zet een poort voor de onomkeerbare. Geef de agent een eigen identiteit met de minste toegang die hij nodig heeft, in een sandbox, met het netwerk afgeschermd en elke actie gelogd. Houd de menselijke poort zeldzaam genoeg zodat mensen hem nog steeds lezen. Doe dat, en een aanvaller die langs uw filter glipt loopt nog steeds tegen een muur van vermogen aan dat hem nooit werd toegekend.

Als u deze negen vangrails voor u wilt laten bouwen, verifiëren en draaien voordat uw eerste agent live gaat, dan is dat precies het werk dat wij doen binnen de stacks van andere bedrijven. Boek hieronder een gratis adviesgesprek en we lopen deze checklist samen langs op uw agent.