AI-agenthulpmiddelenlijsten met toestaan per standaard: waarom weigeren per standaard wint

Waarom deny-by-default beter werkt dan proberen om elke slechte oproep te blokkeren

Wanneer je begint met een deny-by-default-houding, hoef je alleen na te denken over wat de agent echt nodig heeft. Elke andere oproep wordt automatisch gestopt, zonder dat je elk mogelijke misbruik hoeft te voorspellen. Dit vermindert de mentale belasting voor de reviewer en verkleint de kans dat een vergeten gevaarlijke slip door het net glipt.

Bedenk een agent die rapporten schrijft. Het moet een sjabloonbestand lezen, gegevens ophalen uit een database en het voltooide PDF naar een intern postvak sturen. Als je alleen deze drie oproepen opneemt, wordt elke poging om een shell-opdracht uit te voeren, een externe API te raadplegen of een tabel te verwijderen, onmiddellijk geweigerd. Je hoeft nooit een regel te schrijven die zegt "blokkeer rm -rf", "blokkeer curl naar evil.com" of "blokkeer DROP TABLE". De deny-by-default-regel dekt ze allemaal.

In de praktijk heb ik gezien dat teams weken besteden aan het opbouwen van lange blokkeerlijsten die nog steeds een nieuwe aanvalsvector missen, terwijl een korte allowlist van vijf items dezelfde aanvallen op de eerste dag tegenhield. De inspanning die op onderhoud wordt bespaard, is echt: je bekijkt de allowlist wanneer een tool verandert, niet wanneer een nieuwe bedreiging verschijnt.

Hoe ik een allowlist voor een nieuwe agent opbouw

Ik volg een herhaalbare checklist die de lijst overzichtelijk en controleerbaar houdt.

- Schrijf de exacte taken op die de agent vandaag moet uitvoeren. Negeer ideeën die 'misschien later nuttig zijn'. - Voor elke taak vind de enige tool die de taak uitvoert met de smalste mogelijke parameters. Als een tool een vlag biedt die de reikwijdte verbreedt, schakel deze dan niet in tenzij de taak deze expliciet nodig heeft. - Noteer de toolnaam, de exacte opdracht of API-eindpunt en de toegestane parameterwaarden in een eenvoudig YAML-bestand. Dit bestand staat naast de agentcode, zodat reviewers het in één oogopslag kunnen zien. - Voer de agent uit in een zandbak en verifieer dat elke vermelde oproep slaagt en dat elke oproep die niet in het bestand staat een fout retourneert. - Vraag een collega om de lijst te controleren. De taak van de reviewer is om te bevestigen dat elke vermelding overeenkomt met een echte taak en dat er geen extra functionaliteit achter de standaardinstellingen verborgen is. - Sla het bestand op in de versiebeheer. Tag elke commit met de agentversie, zodat je kunt traceren welke allowlist met welke release is verzonden. - Stel een CI-stap in die de build mislukt als het YAML-bestand ontbreekt of als het een tool bevat die niet is goedgekeurd in het projecttoolregister.

Dit proces duurt ongeveer een uur voor een eenvoudige agent en produceert een document dat iedereen kan controleren.

Hulpmiddelen classificeren op basis van wat ze kunnen wijzigen

Niet alle hulpmiddelen dragen hetzelfde risico met zich mee. Ik splits toegestane hulpmiddelen op in drie impactklassen, zodat ik weet waar ik extra controles moet toevoegen.

Impactklasse | Wat het betekent | Voorbeeldhulpmiddel | Typische beveiliging Alleen lezen | Kan gegevens ophalen, maar kan geen status wijzigen | Bestandslezen, database SELECT, openbare API GET | Log de oproep, geen extra goedkeuring nodig Schrijven of mutabel | Kan gegevens maken, bijwerken of verwijderen | Bestandsschrijven, database INSERT/UPDATE/VERWIJDEREN, interne berichtpublicatie | Vereist een tweede goedkeurder voor het eerste gebruik, log met gebruikers-ID Onomkeerbare externe effecten | Kan systemen buiten de vertrouwensgrens beïnvloeden | E-mail verzenden, publiceren op sociale media, betaling initiëren, externe webhook aanroepen | Verplichte handmatige goedkeuring, gedetailleerd audittrail, time-out voor de oproep

Wanneer ik een nieuw hulpmiddel beoordeel, vraag ik me af: "Wat is het ergste dat kan gebeuren als deze oproep wordt uitgevoerd?" Het antwoord vertelt me welke rij van de tabel van toepassing is. Voor alleen-lezen-hulpmiddelen voeg ik alleen een logregel toe. Voor schrijfhulpmiddelen voeg ik een lichtgewicht goedkeuringswerkstroom toe. Voor onomkeerbare effecten dwing ik een handmatige poort af en houd ik het oproepvenster kort.

Het combineren van allowlists met invoer- en uitvoerfilters

Een allowlist verwijdert onnodige functionaliteit. Filters vangen slechte gegevens die door de toegestane aanroepen glippen. Ik behandel ze als complementaire lagen, niet als vervangingen.

Aan de invoerkant voer ik een prompt-injectiechecker uit die zoekt naar bekende jailbreak-patronen. Ik gebruik de OWASP LLM Prompt Injection Prevention Cheat Sheet (link) als referentie voor de regels die ik inschakel. Als de checker een prompt markeert, wijs ik deze af of sanitizeer ik het aanstootgevende segment voordat de agent het ziet.

Aan de uitvoerkant scan ik de gegenereerde tekst van de agent op geheimen, SQL-injectiepogingen of niet-toegestane URLs. De Secrets Management Cheat Sheet (link) helpt me regex-patronen te bouwen voor API-sleutels, wachtwoorden en tokens. De SQL Injection Prevention Cheat Sheet (link) leidt de patronen die ik gebruik om gevaarlijke query-strings te vangen die mogelijk in een antwoord worden teruggekaatst.

Beide filtersets draaien als lichtgewicht middleware. Ze voegen een paar milliseconden latentie toe, maar stoppen veel aanvallen met weinig moeite voordat ze de tool-laag bereiken. Omdat de allowlist al hele klassen aanroepen heeft verwijderd, hebben de filters een kleinere oppervlakte om te inspecteren, wat de valse positieven laag houdt.

Wat dit niet is

Ik wil duidelijk zijn over de beperkingen van een allowlist, zodat u niet verwacht dat het problemen oplost die het nooit heeft hoeven aanpakken.

- Het is geen garantie dat de agent nooit slecht zal gedragen. Een vastberaden aanvaller die een manier vindt om een toegestane tool met kwaadaardige parameters aan te roepen, kan nog steeds schade veroorzaken. - Het vervangt geen veilige programmeerpraktijken. Als de code van de agent zelf een kwetsbaarheid bevat, kan de allowlist de exploitatie van die kwetsbaarheid niet stoppen. - Het is geen vervanging voor een goede geheimenbeheer. Zelfs als de agent geen tool voor het lekken van geheimen kan aanroepen, vormen geheimen die in logboeken of uitvoer zijn gelekt nog steeds een risico. - Het stopt geen indirecte injectie van prompts die de agent manipuleren om een toegestane tool op een onverwachte manier te gebruiken. U hebt nog steeds invoervalidatie en uitvoerfiltering nodig. - Het is geen eenmalige taak. Telkens wanneer een tool wordt toegevoegd, de parameters ervan veranderen of het doel van de agent verschuift, moet u de lijst opnieuw bekijken. - Het is geen zilveren kogel voor compliance. Reguleringen zoals de EU AI Act vereisen documentatie, risicobeoordelingen en menselijke toezicht die verder gaan dan een eenvoudige allowlist.

Veelvoorkomende valkuilen die ik heb gezien en hoe ik ze vermijd

Zelfs met een duidelijk proces kunnen teams soms in gewoontes vervallen die de allowlist verzwakken. Hieronder staan de patronen waarop ik let en de concrete stappen die ik neem om de lijst eerlijk te houden.

- Te brede parameters - Iemand voegt een tool toe met een vlag zoals '--recursive' of '--all' omdat het handig lijkt. Ik counter dit door te vragen: 'Wat is de kleinste set opties die de taak bevredigt?' Als het antwoord een subset is, vergrendel ik de vlag naar die subset in de YAML. - Vergeten toolupdates - Een bibliotheek wordt bijgewerkt en voegt een nieuwe opdracht toe die automatisch wordt blootgesteld. Ik mitigeer dit door de exacte versie van de tool vast te pinnen in het afhankelijkheidsbestand van de agent en een CI-stap toe te voegen die faalt als een nieuwe versie ongedocumenteerde opdrachten introduceert. - Mengen van beleid met prompt - Een ontwikkelaar probeert limieten af te dwingen door instructies zoals 'noem geen delete' toe te voegen binnen de prompt. Ik herinner het team eraan dat promptniveau-controles kunnen worden omzeild door slimme herformulering; de echte bewaker moet zitten bij de toolregistratie of uitvoeringslaag. - Ontbrekende logging - De allowlist blokkeert een oproep, maar niemand weet dat het is gebeurd. Ik zorg ervoor dat elke geblokkeerde poging een gestructureerde logboekingang schrijft met tijdstempel, agent-ID en de geweigerde toolnaam. Deze logboek voedt onze alarmsysteem, zodat we kunnen zien of er wordt geprobeerd om...

Referenties

- OWASP LLM Prompt Injectie Preventie Cheat Sheet - OWASP SQL Injectie Preventie Cheat Sheet - OWASP Geheimenbeheer Cheat Sheet - AgentGuard Squads – Configuratiebestanden Handleiding

Veelgestelde vragen

Is een promptinstructie voldoende om tools te beperken?

Nee. Beperkingen op promptniveau kunnen worden omzeild. Forceer de allowlist op het toolregister of het uitvoeringsniveau.

Wat wordt beschouwd als een onomkeerbaar extern effect?

Het verzenden van e-mail of berichten, het overmaken van geld, het verwijderen van records, het publiceren van inhoud - alles wat je niet ongedaan kunt maken.

Hoeveel tools is te veel?

Er is geen specifiek aantal. De test is of je voor elk tool op de lijst kunt uitleggen welke taak het vereist en wat het kan beschadigen.

Vervangen filters een allowlist?

Nee. Filters vangen slechte inhoud; allowlists verwijderen onnodige mogelijkheden. Gebruik beide.

Deckt dit indirecte promptinjectie?

Het beperkt de schade die je kunt aanrichten. Het detecteren en blokkeren van de injectie zelf is een aparte invoerzijdebeveiliging.

Is de beoordeling een beveiligingsaudit?

Nee. Het is beslissingsondersteuning die oproepen beoordeelt en filters suggesteert. Een volledige beoordeling van de implementatie heeft nog steeds een beveiligingsbeoordeling nodig.

Referenties

- OWASP — Top 10 voor grote taalmodeltoepassingen

Probeer het product: AgentGuard

2026-09-20 · alleen primaire bronnen · geen gefabriceerde verkeersmetrieken · alleen beslissingsondersteuning

Gerelateerde artikelen

- AgentGuard beveiligingsmaatregelen in kaart gebracht op basis van de NIST AI RMF - Verken de volledige AI micro-SaaS onderwerpenmatrix →