AI agents met tijdelijke paspoorten: waarom permanente API-sleutels niet meer kunnen

Het oude model van API-sleutels voor systeemaccounts werkt niet meer zodra je AI agents gebruikt op je infrastructuur. Een LLM die namens een gebruiker DNS-records aanpast, een storage bucket aanmaakt of een firewallregel toevoegt, vraagt om een andere manier van toegang. Niet permanent, niet te ruim, en met een duidelijke einddatum.

Bij een zorginstelling die ik recent bezocht, kreeg een AI-agent die automatisch een testomgeving opschaalde een API-sleutel die ook toegang had tot productiedata. De reden was eenvoudigheid. Dat is kortetermijn denken. En onder de AVG en BIO2 is het meer dan dat: het is een fout die wacht om gemaakt te worden.

Cloudflare introduceerde deze week temporary accounts voor AI agents. Het idee is rechttoe rechtaan: een orchestrator, zoals een Cloudflare Worker, maakt via de API een tijdelijk account aan. Daaraan koppelt hij een beperkte set rechten. De credentials geeft hij door aan de AI agent. Na een ingestelde tijd, of zodra de taak klaar is, wordt het account automatisch verwijderd. De AI agent krijgt nooit een permanente sleutel.

Hoe het technisch werkt

De API-call is een POST naar /accounts/:account_id/temporary_accounts. De body bevat de gewenste resources, acties en een vervaldatum. De response bevat een tijdelijk token. Het lijkt op een standaard Cloudflare API token, maar met een ingebouwde vervaltijd. Je kunt policies definiëren op resource-niveau: alleen toegang tot een specifieke zone, alleen lezen van DNS records, of alleen het deployen van een bepaalde Worker. De orchestrator koppelt de levensduur aan de taak. Een TTL van 15 minuten voor het aanpassen van een DNS-record. Of een webhook die het account verwijdert zodra de CI/CD-pipeline klaar is.

Een voorbeeld van zo’n policy in de API-request:

{
  "name": "temp-agent-dns-update",
  "policies": [
    {
      "effect": "allow",
      "resources": {
        "com.cloudflare.api.account.zone.eb7a4b3c": "*"
      },
      "permission_groups": [
        {
          "id": "c8fed203ed3043cba015a93ad1616f1f",
          "name": "DNS Write"
        }
      ]
    }
  ],
  "ttl": "15m"
}

De orchestrator ontvangt het token. Hij injecteert het in de context van de AI agent. Bijvoorbeeld als omgevingsvariabele in een sandbox. Na gebruik wordt het token gewist. Zelfs als het token uitlekt, is het na vervaltijd onbruikbaar. Het lijkt op wat AWS al jaren doet met de Security Token Service (STS) voor IAM-roles. Maar dan toegepast op het Cloudflare-ecosysteem. Het bijzondere is dat Cloudflare dit expliciet bedoelt voor AI agents. Niet voor mensen. Dat is een keuze. Non-human actors vragen een ander toegangsmodel.

Waarom dit ertoe doet voor de Nederlandse publieke sector

Voor de Nederlandse publieke sector is dit geen theoretisch idee. De BIO2 verplicht organisaties om toegangsrechten regelmatig te herzien. En accounts met veel rechten extra te monitoren. Een permanente API-sleutel voor een AI agent die af en toe iets doet, is per definitie een account met te veel rechten. En zelden gecontroleerd. Tijdelijke accounts lossen dat op. Geen recht, geen risico.

De AVG eist dat verwerkingen doelgebonden en minimaal zijn (artikel 5 lid 1 onder c). Een AI agent die alleen tussen 14:00 en 14:15 toegang heeft tot een specifieke dataset voor een eenmalige analyse, voldoet aan dataminimalisatie. De NIS2-richtlijn, die per 2025 in Nederlandse wetgeving is omgezet, vereist voor essentiële en belangrijke entiteiten passende toegangscontrolemaatregelen (artikel 21). Tijdelijke, taakgebonden credentials zijn een goed voorbeeld van ‘passend’.

De AI Act classificeert AI-systemen in de publieke sector vaak als hoog-risico. Transparantie en controleerbaarheid zijn dan verplicht (artikel 12). Met tijdelijke accounts kun je exact loggen welk AI-agent, voor welke taak, op welk moment toegang had. Dat is een audit trail. Iets dat met een gedeelde permanente sleutel niet haalbaar is.