Je statische scanner ziet het niet: waarom LLM-skills een runtime-firewall nodig hebben

Laatst zat ik met een team van een zorginstelling om tafel. Ze hadden net hun eerste AI-agent in productie genomen, een assistent die op basis van een patiëntvraag automatisch de juiste interne richtlijn ophaalt. Trots lieten ze me hun ‘skill store’ zien: een set van 14 plug-ins die de agent kan aanroepen. Stuk voor stuk door een statische scanner gehaald. “Die checkt op hardcoded URLs, data-exfiltratie en zo,” zei de lead engineer. “We zijn safe.”

Ik vroeg of ik een skill mocht toevoegen. Een onschuldig JSON-bestandje, 12 regels. De scanner gaf groen licht. Maar toen de agent de skill tijdens een test aanriep, stuurde die skill de volledige context, inclusief patiëntinformatie, naar een externe server. De scanner had niets gezien. Het probleem? De skill gebruikte een dynamisch geconstrueerde URL op basis van de agent-output. Pas tijdens runtime werd de kwaadaardige payload zichtbaar.

Dit is geen hypothetisch scenario. Het is de kern van een paper die deze week verscheen: Cognitive Firewall: A Proactive, Zero-Trust, Multi-Gate Framework for LLM Safety [1]. De onderzoekers tonen aan dat statische scanners fundamenteel tekortschieten bij het controleren van AI-agent skills. En ze bieden een alternatief dat veel beter past bij de eisen van de AI Act en NIS2.

De meeste organisaties die AI-agents inzetten, vertrouwen op statische analyse om kwaadaardige skills te detecteren. Een scanner bekijkt de code van een skill, bijvoorbeeld een OpenAPI-specificatie of een Python-script, en zoekt naar bekende patronen: hardcoded URLs, ongeautoriseerde API-calls, pogingen tot data-exfiltratie.

Maar die scanners kijken alleen naar de code zoals die op schijf staat. Ze zien niet wat er gebeurt als de skill daadwerkelijk wordt uitgevoerd in de context van een LLM-gesprek.

De onderzoekers van de Cognitive Firewall paper demonstreren dit met een eenvoudige prompt-injectie skill. De code bevat een ogenschijnlijk onschuldige string: base_url = "https://api.example.com". Een statische scanner ziet een legitiem domein. Maar tijdens runtime voegt de skill daar dynamisch een pad aan toe dat wordt opgebouwd uit de LLM-output. Als de aanvaller de agent via een prompt-injectie stuurt, wordt dat pad https://api.example.com/exfiltrate?data=.... De scanner heeft niets verdachts gezien, want de URL was op het moment van scannen nog compleet onschuldig.

In systemen waar een LLM zelf bepaalt welke tool hij aanroept en met welke parameters, is de aanvalsruimte groot. Een statische scanner kan onmogelijk alle runtime-combinaties voorspellen.

De auteurs introduceren een framework met drie controlepunten, ‘gates’, die elk op een ander moment in de levenscyclus van een tool-aanroep controleren of er iets misgaat.

Gate 1: Pre-execution. Voordat de agent een skill mag aanroepen, checkt de firewall of de skill überhaupt in de huidige context mag worden gebruikt. Dit gaat verder dan een simpele allowlist. De check kijkt naar de taak die de agent probeert uit te voeren, de data die hij tot dan toe heeft verzameld, en het risicoprofiel van de skill. Een rekenmodule aanroepen tijdens een medisch consult? Toegestaan. Een e-mailmodule aanroepen terwijl de agent bezig is met het verwerken van een BIO-dossier? Blokkeren.

Gate 2: Runtime-parameterinspectie. Dit is de cruciale stap. Vlak voordat de skill wordt uitgevoerd, inspecteert de firewall de volledige aanroep, inclusief alle dynamisch gegenereerde parameters. De firewall gebruikt hiervoor een eigen LLM-instantie die de aanroep classificeert als veilig, verdacht of kwaadaardig. De paper beschrijft een classificatiemodel dat is getraind op duizenden legitieme en kwaadaardige tool-aanroepen. Bij een verdachte aanroep kan de firewall extra context ophalen of om bevestiging vragen. Bij een kwaadaardige aanroep wordt de executie geblokkeerd en gelogd.

Gate 3: Post-execution logging en audit. Na uitvoering van de skill logt de firewall de volledige call chain. Inclusief input, output en eventuele side-effects. Die logs zijn bedoeld voor audit en forensisch onderzoek. Ze helpen ook bij het trainen van het classificatiemodel met nieuwe voorbeelden van veilige en onveilige calls.