Er bestaat geen vastgestelde standaard voor de identiteit van AI-agents. In augustus 2026 is elke AI-agent-identiteitsdraft bij de IETF een individuele inzending zonder formele status, zijn twee van de vier meest geciteerde drafts al verlopen, en heeft geen enkele werkgroep er één van overgenomen. Wat vandaag werkt, is een claim uit 2020 en de naamgevingsdiscipline die u zelf oplegt. Hieronder de eerlijke inventarisatie, en het patroon dat u nu al kunt bouwen.
Welke identiteit heeft uw AI-agent vandaag eigenlijk?
Bij vrijwel elke agent-opstelling die wij bij kleinere bedrijven zien is het antwoord: uw identiteit, of een gedeelde.
De agent draait in n8n, Make of een kleine eigen service. Hij bereikt Exact Online, AFAS of e-Boekhouden via één API-sleutel of één koppelgebruiker die is aangemaakt toen de workflow werd gebouwd. De agent heeft geen identiteit. Hij leent er één, en hij leent hem helemaal.
Daar volgen drie dingen uit, en alleen het derde verrast de meeste teams.
Het eerste is de omvang van de schade bij misbruik. De agent kan alles wat die sleutel kan, niet alleen de twee handelingen die de workflow nodig heeft. Het tweede is de grofheid van intrekken: als er iets misgaat is de enige knop het uitschakelen van de sleutel, en daarmee ligt elke workflow stil die hem gebruikt. Beide problemen zijn bekend en hebben bekende antwoorden.
Het derde is toewijzing, en dat is het probleem dat pijn doet. Het auditlogboek van uw ERP registreert die koppelgebruiker, of erger nog de medewerker wiens sleutel is hergebruikt. Een half jaar later vraagt iemand of een creditfactuur door een mens is goedgekeurd of door een model dat onbewaakt draaide, en het logboek kan dat niet vertellen. Die vraag komt nooit vooraf. Die komt na een incident, als de logregels al geschreven zijn. Het aanpalende aanvalsoppervlak beschreven we in het dreigingsmodel dat het mkb mist; dit is het boekhoudkundige probleem daaronder.
Welke standaarden voor AI-agent-identiteit bestaan er in 2026 echt?
Hier gaat het in de meeste artikelen mis, want een lange lijst draftnamen leest als een standaard die vorm krijgt. Dat is het niet. Deze week nagetrokken in de IETF Datatracker:
- **Geen enkel `draft-ietf-oauth-*`-document gaat over AI-agents.** De documentenlijst van de OAuth-werkgroep bevat geen overgenomen werk over agent-identiteit. De twee drafts die het vaakst als agentstandaard worden aangehaald, `identity-chaining` (inmiddels in de wachtrij bij de RFC Editor als Proposed Standard, nog zonder RFC-nummer) en `transaction-tokens-11`, zijn wel degelijk overgenomen, maar geen van beide gaat specifiek over agents. Ze lossen tokenuitwisseling tussen domeinen en context in een aanroepketen op, en zouden ook zonder AI bestaan.
- WIMSE is een echte werkgroep die dit niet doet. Workload Identity in Multi System Environments is actief, het charter is in maart 2026 goedgekeurd, er liggen zes werkgroepdrafts plus één bij de IESG, en er is nul RFC gepubliceerd. Het charter definieert een workload als een draaiende instantie van software met een specifiek doel, en gebruikt de woorden "AI" en "agent" nergens. Er bestaat een draft "WIMSE Applicability for AI Agents", maar dat is een individuele inzending. Tijdens het interim-overleg van juni 2026 noteerde de voorzitter dat dit nadrukkelijk nog geen adoptieverzoek was.
- `agentproto` is een BOF, geen werkgroep. De sessie om tot een werkgroep te komen vond plaats op IETF 126 in Wenen in juli 2026; een charter is er niet.
De Datatracker zegt het bij al deze individuele drafts onomwonden: niet onderschreven door de IETF, geen formele status.
Waarom zijn twee van de vier OAuth-agentdrafts verlopen?
Vier documenten worden aangehaald als de opkomende autorisatiestack voor agents. Hun werkelijke status, deze week geverifieerd:
- On-Behalf-Of User Authorization for AI Agents (Senarath en Dissanayaka, WSO2). Voegt een `requested_actor`-parameter toe op het autorisatie-eindpunt en een `actor_token` op het tokeneindpunt, zodat het toestemmingsscherm de agent bij naam kan noemen. Gepubliceerd in augustus 2025, verlopen in februari 2026.
- Agent Authorization Profile (AAP). Gestructureerde claims voor agentidentiteit, taakcontext en menselijk toezicht, bovenop OAuth 2.0 en JWT. Verlopen.
- OAuth Actor Profile for Delegation (Karl McGuinness). Actief, herzien in april 2026, verloopt in november 2026. Geeft de bestaande `act`-claim een consistente vorm over JWT-grants, accesstokens en transactietokens heen. Het legt uitdrukkelijk geen beleid vast over de vraag wie namens wie mag handelen.
- Attenuating Authorization Tokens (Niyikiza, Tenuo). Actief, herzien in juni 2026, verloopt in december 2026, bedoeld als Standards Track. Een ondertekend token legt vast welke tools een agent mag aanroepen en met welke argumentbeperkingen, en de houder kan er offline een smaller token uit afleiden. De keten is te verifiëren tegen het hoofdvertrouwensanker, zonder netwerkaanroep.
Internet-Drafts verlopen standaard na zes maanden, dus verlopen op zich betekent nog geen mislukking. Dat er twee verlopen zonder dat een werkgroep ze oppakt, is wél het signaal: niemand stuurt hier op convergentie.
Nuttiger dan de status is wat de scheidslijn u vertelt. Dit zijn geen vier pogingen tot hetzelfde. De eerste twee beantwoorden wie namens wie handelt, een kwestie van identiteit en toestemming. De vierde beantwoordt wat deze agent mag aanroepen, met welke argumenten, een kwestie van bevoegdheid. De AAT-draft zegt dat zelf: benaderingen op basis van `requested_actor` beperken niet welke tools de agent mag aanroepen of met welke argumentwaarden, en positioneert zich als aanvullend in plaats van concurrerend.
Daaronder ligt een echt architectuurverschil. RFC 8693-tokenuitwisseling vereist bij elke delegatiestap een synchrone gang naar de autorisatieserver. Die server wordt daarmee deelnemer aan elke stap, en uw agenttopologie raakt gekoppeld aan zijn beschikbaarheid. Offline verzwakking haalt die koppeling weg en levert centrale bemiddeling in ruil daarvoor in. Ontwerpt u nu een systeem met meerdere agents, dan is dát de afweging die u werkelijk moet maken. Het tokenformaat is het deel dat nog gaat veranderen.
Lost MCP de identiteit van agents op?
Nee, en dat probeert het ook niet.
In de huidige specificatie 2026-07-28 is autorisatie OPTIONEEL. Waar die wordt gebruikt, treedt de MCP-server op als OAuth 2.1-resourceserver en de client als OAuth 2.1-client die verzoeken doet namens een resource-eigenaar. Servers MOETEN RFC 9728 Protected Resource Metadata implementeren, clients MOETEN een RFC 8707-resource-indicator meesturen, ongeacht of de autorisatieserver die ondersteunt, en PKCE is verplicht.
De release van juli heeft die laag aangescherpt in plaats van uitgebreid: RFC 9207-issuervalidatie om verwisseling van autorisatieservers te dichten, clientgegevens gebonden aan de issuer die ze uitgaf, en Dynamic Client Registration formeel afgeschaft ten gunste van Client ID Metadata Documents. De migratiedetails staan in onze notitie over wat er breekt in 2026-07-28.
RFC 8693 wordt in de kernspecificatie helemaal niet aangehaald. Delegatie komt alleen voor in een uitbreiding waarvoor u zelf kiest, Enterprise-Managed Authorization, die single sign-on, RFC 8693-tokenuitwisseling en een RFC 7523 JWT-grant aan elkaar knoopt zodat een identityprovider kan bepalen of een client namens een gebruiker mag optreden. Uitbreidingen staan nooit standaard aan.
Het ontwerp is te verdedigen. MCP standaardiseert het transport en schuift identiteit door naar uw identityprovider. Maar het betekent wel dat "namens welke gebruiker handelt deze agent" uw probleem is en niet dat van het protocol, en dat het uw probleem blijft.
Wat kunt u vandaag al bouwen, zonder te wachten?
Vijf dingen, allemaal nu beschikbaar, geen ervan afhankelijk van een draft die het haalt.
Eén inloggegeven per agent, per doel. Niet één sleutel voor het bedrijf en niet één sleutel voor het automatiseringsplatform. Kan uw ERP maar een handvol API-gebruikers uitgeven, besteed ze dan aan workflows en niet aan afdelingen.
Laat de agent nooit het inloggegeven van een persoon dragen. Heeft de agent de bevoegdheid van een medewerker nodig, dan hoort hij een token te dragen dat voor die delegatie is uitgegeven, geen kopie van diens login. Deze grens bepaalt of een incident beperkt blijft.
Gebruik tokenuitwisseling als uw identityprovider dat ondersteunt, en log de `act`-claim. RFC 8693 onderscheidt delegatie, waarbij de agent zijn eigen identiteit houdt met de aantekening dat hij namens iemand handelt, van imitatie, waarbij het logboek simpelweg zegt dat de mens het deed. Controleer wat uw provider werkelijk implementeert voordat u er een ontwerp op baseert.
Kan het onderliggende systeem geen actorclaim dragen, leg de actor dan vast in uw eigen applicatielaag. Exact Online, AFAS en e-Boekhouden laten u geen `act`-claim zien. Elke schrijfactie van uw agent hoort dus een agentkenmerk, een taakkenmerk en de persoon die akkoord gaf mee te dragen, opgeslagen aan uw kant. Aan het begin van een project is dat een kleine ingreep, achteraf een migratie. Het is dezelfde discipline die een koppeling van AI met Exact, AFAS of e-Boekhouden een controle laat doorstaan.
Begrens bevoegdheid bij de aanroep, niet bij het inloggegeven. De AAT-draft wordt misschien nooit een RFC, maar het ontwerpdoel is het overnemen waard: de bevoegdheid die een agent voor een taak gebruikt hoort de tools te beschrijven die díe taak nodig heeft, niet alles wat de aanroepende partij zou kunnen.
Draait u agents via n8n, dan is de concentratie van inloggegevens in dat platform een apart en eerder probleem, dat we behandelden in n8n-beveiliging in 2026.
Wat betekent dit voor het Nederlandse mkb?
Heeft u vandaag een agent die Exact, AFAS of een WMS raakt, dan heeft u het toewijzingsprobleem al, en geen leverancier neemt het dit jaar voor u weg.
Wees voorzichtig met de data aan de regelgevingskant. Registratie onder artikel 12 is een verplichting voor hoogrisicosystemen, en Verordening (EU) 2026/1744, van kracht sinds 27 juli 2026, verschoof het merendeel van de hoogrisicoverplichtingen naar 2 december 2027 voor systemen uit bijlage III en 2 augustus 2028 voor bijlage I. De transparantieplichten uit artikel 50 en het boeteregime voor GPAI gingen wél in op 2 augustus 2026. Geen toezichthouder gaat een Nederlandse mkb'er dus binnenkort beboeten voor een dun auditspoor rond agents. Bouw het toch, want het uitstel geeft u de tijd om het goed te doen, en u kunt de identiteit van de handelende partij niet reconstrueren uit een jaar logregels waarin die nooit is vastgelegd.
Voor een bedrijf van 20 tot 50 medewerkers dat zijn eerste agent op een Nederlandse boekhoudstack zet, is dit ongeveer een dag ontwerpwerk: geef de agents een naam, beperk hun rechten, en schrijf actor, taak en fiatteur bij elke mutatie weg. Het is weinig spectaculair, het overleeft elke standaard die er uiteindelijk komt, en het is het verschil tussen een controle die u kunt beantwoorden en een die u niet kunt beantwoorden. Wilt u dat de eerste keer goed ontworpen hebben, dan is dat waar ons werk aan AI-agents voor bedoeld is.