Wie is de AI-agent? Identiteit, bevoegdheid en bewijs bij financiële transacties

Zodra een agent financiële handelingen kan uitvoeren, ontstaat een fundamentele vraag: wie of wat verricht die handeling eigenlijk?

Het antwoord “de AI-agent” is niet voldoende.

Een organisatie moet kunnen aantonen welke specifieke agent handelde, namens wie die agent optrad, welke bevoegdheden op dat moment golden en welke systemen of middelen hij mocht gebruiken. Wat zulke handelingen precies zijn, staat beschreven bij wat agenttransacties zijn.

Een agent heeft een eigen identiteit nodig

In traditionele systemen worden rechten gekoppeld aan personen, gebruikersaccounts of technische serviceaccounts. Bij AI-agents ontstaat een extra categorie: software die zelfstandig handelingen kan initiëren en meerdere systemen achter elkaar kan gebruiken.

Daarom wordt het steeds belangrijker om een agent niet als een anoniem technisch proces te behandelen, maar als een afzonderlijke digitale identiteit. Het artikel over de digitale identiteit van AI-agents werkt dat identiteitsmodel verder uit.

Zo’n identiteit moet in ieder geval duidelijk maken:

• welke agent het betreft;
• wie eigenaar of verantwoordelijke is;
• welk doel de agent heeft;
• welke systemen de agent mag gebruiken;
• welke handelingen zijn toegestaan;
• en wanneer de toegang moet worden ingetrokken.

NIST heeft in 2026 specifiek aandacht gevraagd voor identiteit en autorisatie van software- en AI-agents. De kern daarvan is dat organisaties agents moeten kunnen identificeren en passende autorisatiecontroles moeten toepassen wanneer zij toegang krijgen tot data, applicaties en tools.

Geen gedeelde accounts

Een veelvoorkomend probleem ontstaat wanneer een AI-agent dezelfde gebruikersnaam, API-key of technische identiteit gebruikt als een medewerker of andere agent.

Dan kan achteraf wel zichtbaar zijn dát er iets gebeurde, maar niet noodzakelijk:

• welke agent de actie uitvoerde;
• onder wiens verantwoordelijkheid dat gebeurde;
• of de actie binnen het mandaat viel;
• en wie de toegang had kunnen intrekken.

Microsoft adviseert daarom om agents als afzonderlijke identiteiten te behandelen, met eigen rollen en expliciet begrensde bevoegdheden.

Identiteit alleen is niet genoeg

Een unieke identiteit zegt nog niets over wat een agent daadwerkelijk mag doen. Daarom moeten identiteit en autorisatie altijd samen worden ingericht.

Een agent die facturen controleert, hoeft bijvoorbeeld niet automatisch ook betalingen te mogen uitvoeren. Een agent die een wallet uitleest, hoeft niet automatisch transacties te mogen ondertekenen. En een agent die betalingen mag voorbereiden, hoeft niet automatisch zelfstandig hoge bedragen te mogen verzenden.

Het uitgangspunt hoort daarom te zijn: alleen de minimale bevoegdheden die nodig zijn voor de taak. Dit wordt vaak aangeduid als het least privilege-principe. Hoe dat organisatorisch wordt vastgelegd, staat op Governance.

Microsoft adviseert daarbij onder andere:

• taakgerichte rollen;
• beperkte toegang tot systemen en data;
• expliciet toegestane tools;
• tijdelijke of beperkte rechten voor risicovolle handelingen;
• en aanvullende goedkeuring voor handelingen met grote impact.

Namens wie handelt de agent?

Bij financiële transacties is nog een vraag belangrijk: handelt de agent zelfstandig of namens iemand anders? Dat verschil moet zichtbaar blijven.

Denk bijvoorbeeld aan een AI-agent die namens een financieel medewerker een betaling voorbereidt. De audittrail zou dan niet alleen moeten vastleggen welke agent de actie uitvoerde, maar ook:

• namens welke gebruiker of organisatie;
• onder welk mandaat;
• welke rol actief was;
• welke limieten golden;
• en of menselijke goedkeuring vereist was.

Zonder deze informatie kan een technisch logboek bestaan, terwijl de feitelijke verantwoordelijkheid nog steeds onduidelijk blijft. De demo laat met fictieve gegevens zien hoe mandaat, limieten en autorisatie samen worden vastgelegd.

Wat moet in de audittrail staan?

Voor financiële processen is alleen een tijdstip en transactienummer meestal niet voldoende. Een bruikbare audittrail legt bijvoorbeeld vast:

• identiteit van de agent;
• verantwoordelijke eigenaar;
• namens wie de agent handelde;
• gebruikte rol of bevoegdheid;
• toegestane scope;
• geraadpleegde tool of API;
• uitgevoerde handeling;
• doel of context van de actie;
• eventuele menselijke goedkeuring;
• tijdstip;
• resultaat;
• en een unieke referentie waarmee alle stappen van de workflow aan elkaar kunnen worden gekoppeld.

Daarmee kan later niet alleen worden vastgesteld wat er gebeurde, maar ook onder welke bevoegdheid. Microsoft benadrukt juist die end-to-end herleidbaarheid als onderdeel van agentgovernance. Het artikel over controle over transacties van AI-agents gaat dieper in op logging en reconstructie.

Intrekken moet direct kunnen

Een agentidentiteit moet niet alleen kunnen worden aangemaakt, maar ook worden beheerd gedurende de volledige levenscyclus. Dat betekent bijvoorbeeld:

• toegang activeren;
• rechten wijzigen;
• credentials roteren;
• tijdelijk blokkeren;
• en volledig intrekken.

Dat laatste is vooral belangrijk wanneer een agent verkeerd gedrag vertoont, gecompromitteerd raakt of niet meer wordt gebruikt.

Een kill switch heeft weinig waarde wanneer de onderliggende tokens, sleutels of toegangsrechten actief blijven. Daarom moet het uitschakelen van een agent ook daadwerkelijk betekenen dat zijn toegang tot systemen en financiële middelen wordt beëindigd. Dat geldt ook wanneer die toegang via een externe partij loopt, zoals beschreven in het artikel over een gehackte AI-agentleverancier.

Extra belangrijk bij wallets en digitale vermogens

Bij wallets, stablecoins en andere digitale vermogens wordt dit vraagstuk nog scherper. Wanneer een agent een wallet kan gebruiken, moet duidelijk zijn:

• van wie die wallet is;
• welke agent toegang had;
• welke sleutel of ondertekeningsmethode werd gebruikt;
• welke transactielimieten golden;
• wie toestemming gaf;
• en hoe achteraf kan worden aangetoond dat de transactie rechtmatig namens de organisatie is uitgevoerd.

Hier raken agentidentiteit, financiële governance en bewijsvoering direct aan elkaar. Sleutelbeheer, functiescheiding en technische begrenzing staan beschreven op Veiligheid.

Een blockchain kan uitstekend aantonen dat een transactie heeft plaatsgevonden. Maar de blockchain vertelt niet automatisch wie binnen de organisatie bevoegd was om die transactie te initiëren. Juist daarom moet de interne controlelaag goed worden ingericht; zie ook crypto compliance in de praktijk.

Vijf vragen die iedere organisatie moet kunnen beantwoorden

Voordat een AI-agent financiële bevoegdheden krijgt, zou een organisatie minimaal deze vragen moeten kunnen beantwoorden:

1. Welke unieke identiteit heeft deze agent?
2. Wie is verantwoordelijk voor die agent?
3. Welke financiële handelingen mag hij uitvoeren?
4. Onder welke limieten, voorwaarden en goedkeuringen?
5. Kunnen we achteraf aantonen wie wat onder welke bevoegdheid heeft gedaan?

Als één van deze vragen niet goed kan worden beantwoord, is de agent mogelijk technisch operationeel, maar bestuurlijk nog onvoldoende beheerst. De bijbehorende aanvalsroutes en faalscenario’s staan bij Risico’s.

Van identiteit naar controle

Een betrouwbare financiële AI-workflow begint daarom niet bij autonomie. Hij begint bij identiteit. Daarna volgen bevoegdheid, limieten, goedkeuring, logging en controle.

Pas wanneer die onderdelen met elkaar verbonden zijn, ontstaat een audittrail waarmee een organisatie werkelijk kan aantonen wat er is gebeurd.