IAM-keten voor autonome AI-agents

U moet voor elke autonome agent een aparte, cryptografisch gebonden identiteit inrichten met kortlevende credentials die buiten het bereik van het model zelf blijven, en u moet vastleggen welke agent welke actie namens welke gebruiker uitvoerde — een gewone SSO-sessie volstaat daarvoor niet.

De aanleiding is een analyse van 10 november 2026 van identiteits- en toegangsbeheer voor autonome AI-agents, die stelt dat bestaande bouwstenen zoals OAuth 2.0 kunnen worden toegepast om agents als afzonderlijke workloads te behandelen met eigen identiteit en runtime-uitgifte van credentials. Het voorbeeld is een waargenomen vervolgincident waarin gestolen applicatiecredentials werden gebruikt om enterprise-tenants en gekoppelde cloudresources te benaderen. In onze beoordeling betekent dit dat u niet kunt volstaan met het uitbreiden van bestaande SSO; u moet een aparte lifecycle voor agentidentiteiten inrichten, met een aanwijsbare eigenaar per agent, en u moet langlevende sleutels vervangen door runtime-uitgifte voordat agentische tooling in uw omgeving schade kan aanrichten.

Waarom is een agent geen gewoon serviceaccount?

Een SSO-sessie vertegenwoordigt een mens. Een serviceaccount is doorgaans een langlevende, breed geautoriseerde identiteit. 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 laten zien dat brede, statische identiteiten een aantrekkelijk doelwit vormen.

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. Dit principe is niet theoretisch: onderzoek beschrijft hoe aanvallers agentische tooling gebruiken om blootgestelde secrets op te sporen en te misbruiken, en hoe gelekte applicatiecredentials werden gebruikt om enterprise-omgevingen te compromitteren.

Welke risico's ontstaan uit statische identiteiten?

• Brede autorisatie op één sleutel — een langlevende API-sleutel geeft een aanvaller toegang tot alle resources die de agent mag benaderen.
• Inzage in het model — credentials die het model zelf kan zien, kunnen door prompt injection of model-inversion worden blootgesteld.
• Geen onderscheid tussen agent en gebruiker — een statische identiteit maakt niet duidelijk namens wie de agent handelt.
• Trage detectie — periodieke review kan niet voorkomen dat schade ontstaat voordat een kwartaalaudit begint.
• Geen intrekking per agent — het verwijderen van één agent vereist handmatige stappen of brede hersleuteling.

Welke controles moet u kunnen aantonen?

1. Aparte identiteit per agent — elke agent heeft een unieke identifier die cryptografisch aan zijn workload is gebonden.
2. Runtime-uitgifte van credentials — credentials worden bij elke aanvraag gegenereerd en hebben een korte geldigheid, niet langer dan nodig voor één transactie.
3. Gedelegeerde context vastgelegd — elk auditrecord bevat de agentidentiteit, de gebruiker of het systeem namens wie de agent handelt, de resource, de actie en het autorisatiebesluit.
4. Gedragsdetectie en onmiddellijke intrekking — u kunt afwijkende activiteit van workload-identiteiten detecteren en credentials onmiddellijk intrekken zonder handmatige stappen.
5. Aparte autorisatie voor hoog-impact acties — voor acties met groot gevolg eist u een verifieerbare bevestiging via de autorisatieserver, niet alleen een klik in de agent-UI.

Hoe begint u met implementatie?

Wie agents al in productie heeft, kan aansluiten bij bredere kaders rond agentic AI en bij de werkwijze om een autonome agent te scheiden van de autorisatie en menselijke fiatteur. 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. Dit is de ondergrens om achteraf te kunnen reconstrueren wie wat namens wie deed. Zo'n record maakt controle mogelijk zonder dat een controleur brede toegang tot gevoelige gegevens nodig heeft.

De operationele volgorde is: maak eerst een inventaris van alle agents en hun credentials; vervang langlevende sleutels door runtime-uitgifte; richt een aparte lifecycle voor agentidentiteiten in met een aanwijsbare eigenaar per agent; zet gedragsdetectie en onmiddellijke intrekking in gang; en leg vast welke acties een aparte autorisatiebevestiging vereisen.

Tooling kan u helpen bij runtime-uitgifte, gedragsdetectie en auditregistratie. Welke events u precies registreert, hoe lang u ze bewaart, en welke acties u als hoog-impact aanmerkt, blijft uw eigen professionele beoordeling. De draft geeft de ondergrens aan; uw organisatie bepaalt wat daarbovenop nodig is.