Digitale identiteit van AI-agents: wie handelt er eigenlijk?

Een agent is geen zelfstandige juridische persoon

Een agent kan zich technisch identificeren met een account, certificaat, API-token of cryptografische sleutel. Dat maakt hem nog geen zelfstandige drager van rechten en verplichtingen. De verantwoordelijkheid blijft verbonden aan de natuurlijke persoon of organisatie die de agent inzet, configureert en toegang geeft.

Daarom is de belangrijkste vraag niet alleen: welke agent deed dit? De volledige vraag luidt:

• namens welke organisatie handelde de agent;
• welke eigenaar of beheerder hoorde bij de agent;
• welke softwareversie en configuratie waren actief;
• welk mandaat was verleend;
• welke limieten en beleidsregels golden;
• wie kon de bevoegdheid wijzigen of intrekken?

Identiteit, authenticatie en bevoegdheid zijn verschillende zaken

Deze begrippen worden gemakkelijk door elkaar gehaald:

• Identiteit: welk systeem of welke organisatie wordt bedoeld?
• Authenticatie: hoe wordt vastgesteld dat de aanvrager werkelijk die identiteit gebruikt?
• Autorisatie: welke handelingen mag die identiteit uitvoeren?
• Mandaat: namens wie en met welk doel mag de agent optreden?

Een geldig certificaat bewijst bijvoorbeeld dat een verbinding bij een bekende technische identiteit hoort. Het bewijst niet automatisch dat een betaling van €25.000 is toegestaan. Daarvoor zijn afzonderlijke bevoegdheden, limieten en controles nodig.

Een bruikbaar identiteitsmodel

Een organisatie kan voor iedere agent een eigen registratie bijhouden met minimaal:

• een unieke agent-ID;
• de juridische eigenaar of opdrachtgever;
• de verantwoordelijke beheerder;
• het toegestane doel;
• toegestane systemen en tegenpartijen;
• transactie- en daglimieten;
• gebruikte credentials en hun geldigheidsduur;
• ingangsdatum, wijzigingshistorie en intrekkingsstatus.

Gebruik geen gedeeld beheeraccount voor verschillende agents. Een unieke technische identiteit maakt het mogelijk rechten per agent in te trekken en gebeurtenissen achteraf aan de juiste configuratie te koppelen.

Tijdelijke bevoegdheden zijn veiliger dan permanente toegang

Langlevende API-sleutels en brede walletrechten vergroten de schade wanneer gegevens uitlekken of een agent wordt misleid. Geef daarom waar mogelijk kortlevende credentials uit voor één beperkte taak. Combineer dat met:

• minimale rechten;
• een maximum bedrag;
• een lijst van toegestane ontvangers;
• beperking tot één omgeving of betaalroute;
• automatische afloop;
• directe intrekking bij afwijkend gedrag.

Een agent die alleen een betalingsvoorstel hoeft te maken, heeft geen ondertekeningssleutel nodig. Voorstellen, autoriseren, ondertekenen en uitvoeren blijven afzonderlijke handelingen.

Lees bij Veiligheid hoe sleutelbeheer, minimale bevoegdheden en technische begrenzing samenkomen. De demo laat het onderscheid tussen voorstellen, autoriseren, ondertekenen en uitvoeren praktisch zien.

Wat eIDAS en de Europese digitale identiteit wel en niet oplossen

Het Europese kader voor digitale identiteit biedt middelen waarmee natuurlijke en rechtspersonen zich kunnen identificeren en elektronische attributen kunnen delen. Ook elektronische handtekeningen, zegels en attestaties van attributen hebben daarin een plaats.

Dat kan nuttig zijn om de organisatie achter een agent of een bevoegd vertegenwoordiger betrouwbaar vast te stellen. Het Europese identiteitskader maakt een AI-agent echter niet automatisch tot een zelfstandige juridische partij. De technische agent-identiteit moet nog steeds worden gekoppeld aan een organisatie, bevoegdheid en controleerbaar mandaat.

Logging: leg ook de context vast

Een transactielog met alleen bedrag en tijdstip is onvoldoende. Leg per belangrijke handeling vast:

• agent-ID en softwareversie;
• opdrachtgever en doel van de taak;
• gebruikte databronnen;
• voorgestelde transactie;
• resultaat van beleidscontroles;
• menselijke of geautomatiseerde autorisatie;
• gebruikte ondertekeningsroute;
• uiteindelijke status en netwerkreferentie;
• wijzigingen in bevoegdheden voor en na het incident.

Logs moeten worden beschermd tegen ongeautoriseerde wijziging, maar wees voorzichtig met absolute claims als “onveranderlijk”. De betrouwbaarheid hangt af van toegangsbeheer, tijdstempels, bewaarbeleid en onafhankelijke controle.

Praktische checklist

• Heeft iedere agent een unieke technische identiteit?
• Is duidelijk namens welke rechtspersoon hij handelt?
• Zijn doel, limieten en toegestane tegenpartijen vastgelegd?
• Zijn credentials kortlevend en intrekbaar?
• Kan de agent zelf geen ruimere bevoegdheden aanvragen of activeren?
• Worden beleidsbesluiten en uitzonderingen gelogd?
• Is er een noodprocedure om alle toegang onmiddellijk te stoppen?
• Wordt periodiek gecontroleerd of ongebruikte identiteiten nog actief zijn?

Conclusie

Een betrouwbare agentidentiteit is meer dan een gebruikersnaam of sleutel. Zij bestaat uit een controleerbare koppeling tussen systeem, organisatie, mandaat, bevoegdheden en historie. Pas wanneer die onderdelen samen worden vastgelegd, kan achteraf worden uitgelegd wie of wat handelde — en waarom dat mocht. Op de pagina Governance staat hoe verantwoordelijkheid en mandaat organisatorisch kunnen worden vastgelegd.