De sleutel is het probleem: waarom AI-agenten hardware keystores nodig hebben

AI-agenten ondertekenen commits. Ze authenticeren API-calls. Ze issuën certificaten. De private keys die daarvoor nodig zijn staan in software. Dat is een probleem dat we niet meer kunnen negeren.

Een productie-incident uit het recente verleden laat zien hoe snel het misgaat. Een AI-agent die een Git-commit moest ondertekenen, kreeg via een kwaadaardige email-injectie de opdracht om de private key te exfiltreren. Binnen vijf minuten was de key weg. Geen menselijke tussenkomst. Geen alert. Geen kans om in te grijpen.

Het arXiv-paper Hardware Keystores for AI Agent Signing: Zero-Trust MCP pakt dit probleem aan met een vijf-laags zero-trust stack. De resultaten liegen er niet om. De attack success rate daalt van 19,3% naar 0%. Voor Nederlandse overheden die AI-agenten inzetten voor geautomatiseerde workflows is dit geen theoretisch verhaal. BIO2 maatregel 5.7 vereist hardware-gebaseerd key management. Maar geen enkel assessment controleert of AI-agenten dat eenvoudig kunnen omzeilen via prompt injection.

Ik bekijk de techniek, de formele modellen en de praktische implicaties voor de publieke sector.

Het probleem: software keys zijn een single point of failure

De meeste AI-agenten die crypto-operaties uitvoeren, gebruiken software-gebaseerd key management. Denk aan een CI/CD pipeline die commits ondertekent met GPG. Een API-orkestratie die JWT-tokens genereert. Of een certificaatbeheerder die CSR's ondertekent. De private key staat in een bestand op disk. Soms in een environment variable. Of in een secrets manager die de agent zelf kan uitlezen.

Het dreigingsmodel is helder. Een AI-agent is een taalmodel dat tekst genereert. Het kan gemanipuleerd worden via prompt injection. Een kwaadaardige instructie in een email volstaat. Een API-response werkt ook. Zelfs een git commit message kan de agent overhalen om de key te exfiltreren. De agent heeft toegang tot de key. Dus de agent kan de key lekken.

De cijfers uit het paper zijn confronterend. In een gecontroleerde testomgeving met 100 agent-instances en 1.000 pogingen per instance, was de attack success rate 19,3%. Dat betekent: bijna één op de vijf pogingen om een key te exfiltreren via prompt injection slaagt. En dat is in een testomgeving. In productie, met complexere prompts en meer context, is het waarschijnlijk erger.

De vijf-laags zero-trust stack

Het paper stelt een architectuur voor. Ik leg deze hier uit. De kern is simpel. De private key verlaat nooit de hardware keystore. De AI-agent heeft geen directe toegang tot de key. Maar de agent kan wel cryptografische operaties aanvragen. Elke operatie wordt gevalideerd tegen een policy.

Formeel definieert het paper het systeem als een tuple (K, A, P, S), waarbij:

• K = verzameling van hardware keystores (HSM of TPM)
• A = verzameling van AI-agenten
• P = policy-engine die operaties valideert
• S = signing-service die de brug is tussen agent en keystore

De vijf lagen:

1. Isolation layer: scheidt de agent van de keystore. De agent draait in een sandbox zonder directe toegang tot de key material.
2. Policy enforcement: elke signing request wordt gevalideerd tegen een policy. Denk aan: alleen commits van branch main mogen ondertekend worden. Of: alleen certificaten voor domeinen binnen *.overheid.nl.
3. Context binding: de signing request wordt gekoppeld aan de context waarin de agent draait. Een commit signing request moet bijvoorbeeld de git hash bevatten. Die hash moet overeenkomen met wat de agent daadwerkelijk wil committen.
4. Anomaly detection: gedragsanalyse op de signing requests. Als een agent plotseling 1.000 requests per minuut doet, wordt dat geblokkeerd. Requests naar een onbekend key-alias ook.
5. Audit logging: elke operatie wordt cryptografisch vastgelegd. Niet alleen "key X ondertekende Y". Ook "agent Z vroeg om ondertekening van Y, met prompt-context C".

De implementatie gebruikt PKCS#11 als interface tussen de signing-service en de hardware keystore.