IETF-draft schetst eigen IAM-keten voor autonome AI-agents, los van gebruikers-SSO

De IETF-werkgroep WIMSE publiceerde op 2 november 2026 een internetdraft voor identiteits- en toegangsbeheer van autonome AI-agents. De kern: geef elke agent een eigen, cryptografisch gebonden identiteit, gebruik kortlevende credentials, leg de menselijke opdrachtgever apart vast als gedelegeerde context en registreer controleerbaar welke agent welke actie namens wie uitvoerde, want een gewone gebruikers-SSO volstaat daarvoor niet.

Deze draft, getiteld AI Identity Management System, beschrijft hoe bestaande bouwstenen zoals WIMSE en de OAuth 2.0-familie kunnen worden toegepast voor software die zelfstandig tools, diensten en gegevensbronnen aanspreekt. Belangrijk om vast te houden: het is een werkdocument, geen vastgestelde RFC en geen bindende norm. De onderliggende ontwerpvraag is nu wel concreet en toetsbaar geworden voor iedereen die agents in productie wil nemen.

Wat staat er precies in de IETF-draft over IAM voor autonome AI-agents?

De draft behandelt elke agent als een afzonderlijke workload met een unieke identifier en credentials die cryptografisch aan die agent zijn gebonden. Die credentials moeten kortlevend zijn, runtime worden uitgegeven en buiten het bereik van het taalmodel zelf blijven. OAuth 2.0, transaction tokens, policy-based authorization, menselijke bevestiging en continue monitoring vormen samen het model.

De draft onderscheidt vijf controlepunten in één doorlopende keten:

• Agentidentiteit die niet samenvalt met de menselijke opdrachtgever; de gebruiker of het systeem wordt apart vastgelegd als gedelegeerde subject-context.
• Runtime-authenticatie met kortlevende, cryptografisch gebonden credentials in plaats van statische API-sleutels.
• Fijnmazige autorisatie die de missie van de agent vertaalt naar minimale scopes en resource-, actie-, tijd- en transactielimieten.
• Menselijke bevestiging voor gevoelige acties; volgens de draft is een lokale goedkeuringsknop in de agent-UI op zichzelf geen autorisatie.
• Posture- en risicosignalen, intrekking en auditbewijs, zodat credentials vernieuwd, privileges beperkt of sessies beëindigd kunnen worden als de runtimecontext verandert.

Waarom volstaat een gewone gebruikers-SSO of serviceaccount niet voor AI-agents?

Omdat een SSO-sessie een mens vertegenwoordigt en een serviceaccount doorgaans een langlevende, breed geautoriseerde identiteit is. Een autonome agent neemt zelfstandig beslissingen over welke tool hij aanroept en welke gegevens hij opvraagt, en handelt vaak namens wisselende gebruikers. Daardoor moet de identiteit van de agent en de gedelegeerde context van de opdrachtgever afzonderlijk worden beheerd. Threatmodellen voor agentketens, zoals die van de OWASP Foundation voor applicatiebeveiliging bekend zijn, laten zien dat brede, statische identiteiten een aantrekkelijk doelwit vormen.

Microsoft laat in de documentatie over Microsoft Entra Agent ID zien hoe dit er in een enterprise-omgeving uit kan zien: agentidentiteiten krijgen een eigen lifecycle met owners, sponsors, provisioning en verwijdering, en beleid zoals Conditional Access kan apart worden toegepast op autonome agents. Dit is leveranciersdocumentatie en geen universele norm, maar het bevestigt het principe dat een agent geen gewoon serviceaccount is.

De operationele urgentie blijkt uit onderzoek van Microsoft Threat Intelligence, dat op 5 november 2026 beschreef hoe aanvallers agentische tooling gebruiken om blootgestelde secrets op te sporen en te misbruiken. In een waargenomen vervolgincident werden gelekte of gestolen applicatiecredentials gebruikt om Entra-tenants en gekoppelde Azure- en Microsoft 365-resources te benaderen. Wij lezen hierin geen voorspelling dat elke aanval zo verloopt, maar wel een bevestiging van de noodzaak van least privilege, credentialrotatie, monitoring van workload- of applicatie-identiteiten en snelle intrekking.

De Coalition for Secure AI (CoSAI), actief onder OASIS Open, beschrijft agentic IAM in haar publicatie over agentische identiteit en toegang als een vertrouwenslaag bovenop bestaande enterprise-IAM, met continue verificatie, veilige delegatie en intent-based autorisatie. Ze benoemt ook het risico dat een agent gevoelige inzichten samenstelt uit op zichzelf onschuldige bronnen.

Wat betekent dit voor bestuurders, juristen en CISO's die agents inzetten?

Onze analyse: omdat de IETF-draft agents als aparte workloads behandelt met eigen identiteit en kortlevende credentials, kan een CISO niet volstaan met het uitbreiden van de bestaande SSO; daarom moet het identiteitsteam nu een aparte lifecycle inrichten voor agentidentiteiten, met een aanwijsbare eigenaar of sponsor per agent. Onze analyse: omdat de draft statische sleutels en credentials die het model zelf kan zien expliciet buiten het ontwerp plaatst, loopt elke agent met een langlevende API-sleutel een vermijdbaar risico; daarom is het verstandig om voor het einde van het lopende begrotingsjaar een inventaris te maken van alle agents en hun credentials en de langlevende sleutels te vervangen door runtime-uitgifte. Onze analyse: omdat de draft stelt dat een lokale goedkeuringsknop geen autorisatie is, mag een organisatie naar onze beoordeling niet aannemen dat een menselijke klik in de agent-UI op zichzelf juridisch of technisch voldoende is; daarom verdient het bij hoog-impactacties aanbeveling om een aparte, verifieerbare bevestiging via de autorisatieserver te eisen en die keuze in het ontwerp vast te leggen. Onze analyse: omdat de threat intelligence laat zien hoe snel misbruik kan verlopen, volstaat periodieke review niet; daarom moet de CISO gedragsdetectie op workload-identiteiten en onmiddellijke intrekking inregelen, want zonder die snelheid kan schade ontstaan voordat een kwartaalaudit begint.

Samengevat volgt uit dit nieuws de volgende volgorde van maatregelen:

1. Inventariseer welke agents actief zijn en welke identiteit en credentials zij gebruiken.
2. Wijs per agent een eigenaar of sponsor aan en beheer de identiteit als aparte lifecycle-entiteit.
3. Vervang langlevende sleutels door kortlevende, runtime uitgegeven credentials.
4. Leg per agent minimale scopes en transactielimieten vast in een onafhankelijke autorisatielaag.
5. Eis verifieerbare menselijke bevestiging voor gevoelige acties en regel onmiddellijke intrekking in.

Wie agents al in productie heeft, kan hiervoor aansluiten bij bredere kaders rond agentic AI en AI-agents en bij de werkwijze om een autonome agent te scheiden van de autorisatie en menselijke fiatteur.

Welk minimaal auditrecord moet ik per agentactie vastleggen?

De draft stelt dat een auditrecord minimaal de agentidentiteit, de gedelegeerde gebruiker of het systeem, de resource, de actie, het autorisatiebesluit, het tijdstip, een correlatie-ID en eventuele intrekkings- of remediëringsgebeurtenissen bevat. Naar onze inschatting is dat de ondergrens om achteraf te kunnen reconstrueren wie wat namens wie deed.

Een werkbaar minimaal record bevat:

• Agent-ID en de binding aan de credential of sleutel;
• Gedelegeerde gebruiker of systeem;
• Missie- of transactiereferentie;
• Resource, actie en toegekende scope;
• Autorisatiebesluit en het posture- of risicosignaal dat meewoog;
• De gebruikte tool- en serviceketen;
• Tijdstip, resultaat en eventuele intrekking.

Zo'n record maakt controle mogelijk zonder dat een controleur brede toegang tot de onderliggende gevoelige gegevens nodig heeft. Voor de keuze welke gebeurtenissen u precies registreert en hoe lang, helpt onze eerdere uitleg over een tweelaags auditrecord dat technische gebeurtenis en beslissing koppelt.

Bronnen: Het artikel steunt op de IETF WIMSE-internetdraft over AI-identiteitsbeheer, documentatie over Microsoft Entra Agent ID, onderzoek van Microsoft Threat Intelligence en guidance van de Coalition for Secure AI onder OASIS Open.