PKIaaS voor AI-infrastructuur en AI-agenten

AI-agenten zijn niet langer hypothetisch. Ze worden in 2026 in productieomgevingen ingezet om workflows te automatiseren, API-aanroepen uit te voeren, configuraties te wijzigen, transacties te initiëren en met kritieke systemen te communiceren met machinesnelheid en -schaal. Een enkele AI-workflow kan bestaan ​​uit vijf of meer agenten die taken aan elkaar doorgeven, externe API's aanroepen, gegevens uit databases lezen en naar records schrijven, allemaal zonder menselijke tussenkomst bij elke stap.

De beveiligingsvraag die de meeste organisaties die deze systemen implementeren nog niet volledig hebben beantwoord, is: hoe weet je welke agent wat heeft gedaan en hoe bewijs je dat? De meeste AI-agents authenticeren zich tegenwoordig bij API's en services met behulp van statische referenties: API-sleutels, clientgeheimen en gedeelde tokens. Deze referenties bevatten geen identiteitsclaim behalve hun tekenreeks. Ze kunnen worden gekopieerd. Ze verlopen niet automatisch. Ze bieden geen auditspoor dat een specifieke actie koppelt aan een specifieke agentinstantie. En volgens het IBM Cost of a Data Breach Report 2025 beschikte 97% van de organisaties die te maken kregen met datalekken waarbij AI-modellen betrokken waren, niet over adequate toegangscontrole voor AI.

De oplossing voor het identiteitsprobleem van AI-agenten is dezelfde oplossing die het identiteitsprobleem van machines voor servers, apparaten en workloads heeft opgelost: cryptografische identiteit ondersteund door een beheerde certificeringsinstantie. PKI as a Service biedt de CA-infrastructuur die unieke, kortstondige, verifieerbare identiteiten uitgeeft aan AI-agenten, waardoor mTLS mogelijk wordt voor communicatie tussen agent en service, certificaatgebaseerde OAuth voor delegatieketens en een auditspoor dat elke agentactie cryptografisch toewijsbaar maakt aan een specifieke identiteit.

Kort antwoord: Wat doet PKIaaS voor de identiteit van AI-agenten?

PKIaaS geeft elke AI-agent een uniek X.509-certificaat dat de identiteit van de agent codeert (naam, type, implementatieomgeving, geautoriseerd bereik en uitgevende organisatie). Het certificaat is van korte duur (minuten tot uren voor tijdelijke agents; 24 tot 48 uur voor permanente agents), wordt automatisch geroteerd door de identiteitsinfrastructuur en is ondertekend door de PKIaaS CA waarvan de root zich in de vertrouwensbundel van elke service bevindt die de agent aanroept. Wanneer de agent een API-aanroep doet, presenteert deze het certificaat; de service verifieert het certificaat aan de hand van de PKIaaS root CA; en de verbinding wordt alleen tot stand gebracht als de verificatie slaagt. Elke certificaatuitgifte wordt vastgelegd in het PKIaaS-auditlogboek, dat een cryptografisch traceerbare registratie biedt van welke agent actief was gedurende welk tijdsvenster en welke acties deze mocht uitvoeren.

Key Takeaways

• Statische referenties (API-sleutels, clientgeheimen, gedeelde tokens) bieden geen verantwoordingsplicht voor AI-agenten. Ze bevatten geen identiteitsclaim behalve hun tekenreeks, kunnen worden gekopieerd en gedeeld tussen agenten, verlopen niet automatisch en genereren geen auditspoor dat een specifieke actie koppelt aan een specifieke agentinstantie. Certificaatgebaseerde agentidentiteit biedt al deze eigenschappen structureel, niet via beleid dat kan worden omzeild.
• Zelfs kortstondige AI-agenten die voor één enkele taak worden ingezet, verdienen een unieke cryptografische identiteit. Een certificaat met een geldigheidsduur van 30 minuten, uitgegeven aan een agent met een korte levensduur, betekent dat als het certificaat op de een of andere manier wordt onderschept, het binnen 30 minuten onbruikbaar is. Dezelfde API-sleutel die aan dezelfde agent met een korte levensduur is gegeven, is geldig totdat iemand deze handmatig wijzigt, wat mogelijk nooit zal gebeuren.
• Het delegatieketenprobleem is het moeilijkste onopgeloste identiteitsprobleem in agentische AI. Wanneer agent A agent B aanroept, die op zijn beurt een tool aanroept, wat een transactie in gang zet, moet elke schakel in die keten cryptografisch aantoonbaar zijn en terug te voeren zijn op een verantwoordelijke persoon of opdrachtgever. Certificaatgebaseerde identiteit, gecombineerd met OAuth 2.0 Token Exchange (RFC 8693) die aan die certificaten is gekoppeld, biedt het technische mechanisme voor een verifieerbare delegatieketen.
• mTLS voor agent-naar-service-communicatie is het AI-equivalent van Zero Trust voor workloads. Een AI-agent die een door PKIaaS uitgegeven certificaat aan een API presenteert, wordt cryptografisch geverifieerd voordat een verzoek op applicatieniveau wordt verwerkt. Een agent zonder een geldig PKIaaS-certificaat wordt op de TLS-laag geweigerd, ongeacht of deze in de applicatiepayload beweert een geautoriseerde agent te zijn.
• De regelgeving rondom de identiteit van AI-agenten is in beweging. Het NCCoE van NIST publiceerde in 2026 een conceptdocument over de identiteit en autorisatie van software en AI-agenten. De ITU heeft een focusgroep opgericht voor vertrouwen en identiteit van AI-agenten. De vereisten van de EU-wetgeving inzake kunstmatige intelligentie (AI) met betrekking tot verantwoording en menselijk toezicht leggen impliciet verplichtingen op aan de controleerbaarheid van AI-systemen. Certificaatgebaseerde identiteit is het meest vol成熟e technische mechanisme om aan deze nieuwe eisen te voldoen.

Het identiteitsprobleem van de AI-agent

AI-agenten verschillen van traditionele software in één cruciaal beveiligingsaspect: ze handelen autonoom. Een webserver verwerkt verzoeken; hij initieert ze niet. Een AI-agent doet beide. Hij ontvangt een doel, redeneert over hoe dit te bereiken en onderneemt acties in een reeks van systemen, API's en tools, zonder menselijke autorisatie bij elke stap. De bevoegdheid om deze acties uit te voeren is tijdens de implementatie aan de agent gedelegeerd en de controle op wat de agent kan doen is doorgaans grofmazig: een API-sleutel met een brede reikwijdte, een serviceaccount met ruime machtigingen of een toegangstoken op systeemniveau dat nooit specifiek voor de taak van de agent is bedoeld.

Dit creëert een kloof in identiteit en verantwoording die groeit naarmate de schaal toeneemt. Wanneer een organisatie tien AI-agents inzet, is de kloof beheersbaar: iemand weet tot welke gegevens elke agent toegang heeft. Maar wanneer dezelfde organisatie duizend agents inzet, verspreid over tientallen workflows, kan niemand betrouwbaar antwoorden op de volgende vragen: welke agent heeft die API-aanroep om 2:47 uur 's nachts gedaan? Was die agent daartoe bevoegd? Hoe kan ik bewijzen dat de actie is uitgevoerd door agent A en niet door iemand die de inloggegevens van agent A heeft bemachtigd?

Het Palo Alto Networks 2026 Identity Security Landscape-rapport toonde een verhouding van 109:1 tussen machine-identiteiten en menselijke identiteiten in bedrijfsomgevingen. AI-agenten vormen de snelstgroeiende component van die populatie machine-identiteiten. Het beheren van hun identiteit met hetzelfde statische referentiemodel dat werd gebruikt voor vroege bedrijfssoftware is geen beveiligingsmaatregel, maar een programma dat leidt tot een opeenstapeling van risico's.

Waarom statische inloggegevens niet werken voor AI-agenten

Statische authenticatie werkt niet voor AI-agenten om dezelfde redenen als voor elke andere machine-identiteit, en dat wordt versterkt door het autonome karakter van het gedrag van agenten:

Geen identiteitsbinding. Een API-sleutel bewijst dat de beller de sleutel bezit, niet dat de beller de geautoriseerde agent is. Als de sleutel uit de omgeving van de agent wordt gehaald, is elk proces met de sleutel niet meer te onderscheiden van de agent. In een omgeving waar agenten met andere agenten communiceren (context doorgeven, subtaken delegeren, tijdelijke toegang delen), neemt de kans op het stelen van inloggegevens toe met elke interactie tussen agenten.

Geen automatische vervaldatum. API-sleutels verlopen niet, tenzij iemand ze expliciet roteert. Een AI-agent die buiten gebruik wordt gesteld, behoudt zijn API-sleutel geldig totdat het operationele team dit opmerkt en de sleutel intrekt. In een snel veranderende omgeving waar agents worden aangemaakt en weer verwijderd voor specifieke taken, kan het probleem van achtergebleven inloggegevens zich snel ophopen. Een certificaat dat aan een agent is uitgegeven met een geldigheidsduur van 4 uur, verloopt samen met de agent, waardoor er geen achtergebleven inloggegevens ontstaan ​​en er geen opruimverplichting is.

Geen niet-afwijzing. Als een AI-agent schade veroorzaakt door een API aan te roepen die niet aangeroepen had mogen worden, of door een transactie met onjuiste parameters te initiëren, kan de API-sleutel in het auditlogboek niet ondubbelzinnig aantonen welke agent de aanroep heeft gedaan als de sleutel gedeeld is of als het beheer van de sleutel niet is bijgehouden. Een X.509-certificaat met een specifiek serienummer, uitgegeven aan een specifieke agentimplementatie, biedt niet-afwijzing: de auditlogboekvermelding verwijst naar het certificaat, het PKIaaS-auditlogboek registreert wanneer het certificaat is uitgegeven en aan welke agentidentiteit, en de toeschrijvingsketen is cryptografisch compleet.

X.509-certificaten als identiteit van AI-agenten

Een X.509-certificaat, uitgegeven door een PKIaaS-certificeringsinstantie aan een AI-agent, codeert de identiteit van de agent in een cryptografisch verifieerbaar, gestandaardiseerd formaat. De velden Subject Distinguished Name en Subject Alternative Name van het certificaat bevatten de identiteitskenmerken van de agent. Een goed ontworpen agentidentiteitscertificaat kan bijvoorbeeld de volgende gegevens coderen:

• CN (Algemene naam): De naam en versie-identificatie van de agent (bijvoorbeeld, order-processing-agent-v2.1)
• O (Organisatie): De bedrijfseenheid of het team dat eigenaar is van de agent.
• OU (Organisatie-eenheid): De implementatieomgeving (productie, staging, sandbox)
• URI SAN: Een SPIFFE-ID als de agent is geïmplementeerd in een SPIFFE-compatibele omgeving (spiffe://trust-domain/agents/order-processing)
• Aangepaste OID-extensies: Agentversie, geautoriseerd workflowbereik of implementatie-ID in aangepaste X.509-extensies als het agentautorisatiemodel beleidskenmerken in het certificaat vereist.

Het certificaat is ondertekend door de PKIaaS CA, waardoor het verifieerbaar is door elke service die het PKIaaS root CA-certificaat in zijn vertrouwensbundel heeft. De privésleutel die bij het certificaat hoort, wordt gegenereerd in de uitvoeringsomgeving van de agent en verlaat deze nooit. De PKIaaS CA ondertekent het certificaat op basis van de CSR (Certificate Signing Request) van de agent, die de publieke sleutel bevat. De privésleutel passeert nooit de PKIaaS CA, de secrets manager of enige gedeelde infrastructuur; deze bevindt zich uitsluitend in het beveiligde geheugen van de agent gedurende de geldigheidsduur van het certificaat.

Agentidentiteit instellen bij de lancering

Het proces voor het aanmaken van agentidentiteiten werkt als volgt. Wanneer een agent wordt gestart (als container in Kubernetes, serverloze functie, proces op een virtuele machine of tijdelijke rekentaak), vraagt ​​de provisioningstap een certificaat aan bij de PKIaaS CA. De aanvraag wordt geverifieerd met behulp van een van de volgende mechanismen:

• OIDC-tokenuitwisseling: Het AI-orkestratieplatform geeft de agent bij het opstarten een kortstondig OIDC-token. De agent presenteert dit token aan het PKIaaS ACME-eindpunt (met externe accountbinding) en ontvangt in ruil daarvoor een certificaat. GitHub Actions, GitLab CI, AWS STS, Azure AD Workload Identity en GCP Workload Identity geven allemaal OIDC-tokens uit die hiervoor geschikt zijn. Het OIDC-token is de opstartreferentie; het certificaat is de operationele referentie die de agent gebruikt voor zijn daadwerkelijke werkzaamheden.
• Platformattestatie: In Kubernetes-omgevingen bevestigt SPIRE de pod-identiteit van de agent met behulp van Kubernetes-node-attestatie en pod-selectors, waarna een SVID (SPIFFE Verifiable Identity Document) rechtstreeks aan de agent wordt verstrekt via de SPIFFE Workload API. Met PKIaaS als de upstream CA van SPIRE, wordt deze SVID gekoppeld aan de PKIaaS-root.
• Bootstrap van de geheimenbeheerder: Voor agents die niet in Kubernetes draaien, bewaart een geautoriseerde secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) een eenmalige inschrijvingsreferentie die de agent gebruikt om zijn eerste certificaatverzoek te authenticeren. De inschrijvingsreferentie wordt verbruikt bij gebruik en de daaropvolgende bewerkingen van de agent maken gebruik van het uitgegeven certificaat.

mTLS voor agent-naar-service en agent-naar-agent communicatie

Zodra een agent een door PKIaaS uitgegeven certificaat heeft, gebruikt deze dat certificaat voor wederzijdse TLS-authenticatie met elke service die wordt aangeroepen. mTLS voor communicatie tussen agent en service biedt twee beveiligingseigenschappen die statische referenties niet bieden:

Serviceverificatie door de agent: De agent verifieert het TLS-certificaat van de service aan de hand van de PKIaaS root CA trust bundle voordat er gegevens worden verzonden. Een AI-agent die een vervalst API-eindpunt aanroept (een man-in-the-middle-aanval bedoeld om agentcontext te stelen of agentacties te manipuleren) wordt gedetecteerd tijdens de TLS-handshake, omdat het vervalste eindpunt geen certificaat kan presenteren dat is ondertekend door de PKIaaS CA. Het verzoek van de agent bereikt nooit een systeem dat niet cryptografisch is geverifieerd.

Agentverificatie door de service: De service verifieert het certificaat van de agent aan de hand van de PKIaaS root CA trust bundle voordat een verzoek wordt verwerkt. Een ongeautoriseerde agent of een gecompromitteerd proces dat zich voordoet als een agent, kan geen geldig PKIaaS-certificaat presenteren (het certificaat is cryptografisch gekoppeld aan de privésleutel die is gegenereerd in de uitvoeringscontext van de legitieme agent). De service weigert de verbinding voordat er applicatielogica wordt uitgevoerd.

Voor communicatie tussen agenten in workflows met meerdere agenten geldt hetzelfde mTLS-patroon. Agent A presenteert zijn certificaat aan Agent B; Agent B verifieert dit aan de hand van de PKIaaS-root; Agent B presenteert zijn certificaat aan Agent A; Agent A verifieert dit. Geen van beide agenten kan worden geïmpersoneerd door een proces dat niet over de bijbehorende privésleutel beschikt.

Certificaatgebaseerde OAuth: Beveiliging van agentautorisatiestromen

Veel AI-agenten communiceren met API's die OAuth 2.0 gebruiken voor autorisatie. Het standaard OAuth-patroon voor machineclients is de Client Credentials-grant: de client (agent) presenteert een client-ID en een clientgeheim om een ​​toegangstoken te verkrijgen. Het clientgeheim is een statische authenticatiegegevens met alle bovengenoemde problemen.

Certificaatgebaseerde OAuth vervangt het clientgeheim door het X.509-certificaat van de agent. In dit patroon, dat gebruikmaakt van de OAuth 2.0 Mutual-TLS Client Authentication (RFC 8705), authenticeert de agent zich bij de OAuth-autorisatieserver met behulp van zijn door PKIaaS uitgegeven certificaat in de TLS-handshake (mTLS-clientauthenticatie) in plaats van een clientgeheim in de request body te presenteren. De autorisatieserver verifieert het certificaat aan de hand van de PKIaaS CA-vertrouwensbundel en geeft een toegangstoken uit dat is gekoppeld aan de vingerafdruk van het certificaat. Dit toegangstoken is alleen geldig wanneer het samen met het certificaat wordt gepresenteerd waarmee het is verkregen: het bearer-token en het clientcertificaat moeten overeenkomen, waardoor gestolen toegangstokens nutteloos zijn zonder de bijbehorende privésleutel.

Voor workflows met meerdere agenten maakt de OAuth 2.0 Token Exchange-specificatie (RFC 8693) het mogelijk voor agenten om toegangstokens te verkrijgen die de delegatieketen coderen: Agent B kan een token aanvragen dat bewijst dat deze handelt onder autoriteit die is gedelegeerd door Agent A, die is geautoriseerd door de gebruiker of systeemprincipal die de workflow heeft geïnitieerd. In combinatie met certificaatgebaseerde authenticatie bij elke stap wordt de delegatieketen cryptografisch verifieerbaar: elk toegangstoken in de keten is gekoppeld aan een specifiek certificaat, elk certificaat is uitgegeven door de PKIaaS CA aan een specifieke agentidentiteit en het PKIaaS-auditlogboek registreert de uitgiftegeschiedenis.

Het delegatieketenprobleem in workflows met meerdere agenten

De meest technisch complexe identiteitsuitdaging in agentische AI ​​is de delegatieketen: wanneer agent A een taak delegeert aan agent B, die een tool aanroept die een betaling in een financieel systeem activeert, moet elk systeem in die keten de gezagsstructuur kennen die de uiteindelijke actie heeft gegenereerd. Zonder cryptografische delegatieketens ziet het financiële systeem alleen "Agent B heeft dit verzoek gedaan", zonder te weten dat agent B handelde onder de bevoegdheid van agent A, die was verleend door een menselijke workflow-eigenaar, en die bevoegdheid was vastgelegd in een organisatiebeleid.

Dit is om drie redenen belangrijk. Ten eerste, autorisatie: het financiële systeem moet verifiëren dat de uiteindelijke autoriteit in de keten (de menselijke of organisatorische opdrachtgever) het recht had om de betaling te autoriseren die Agent B aanvraagt. Ten tweede, verantwoording: wanneer de auditor vraagt ​​wie een specifieke transactie heeft geautoriseerd, moet het antwoord traceerbaar zijn via elke agent in de keten terug naar een beslissing die door een mens kan worden genomen. Ten derde, beperking: als Agent B wordt gecompromitteerd of verkeerd geconfigureerd, blijft de schade beperkt tot wat de delegatieketen autoriseert, en niet tot alles waartoe de API-sleutel van Agent B toegang heeft.

Het technische mechanisme voor cryptografische delegatieketens combineert certificaatgebaseerde identiteit met tokenuitwisseling. Agent A bezit een PKIaaS-certificaat dat zijn identiteit codeert. Agent A authenticeert zich bij de autorisatieserver met behulp van dat certificaat en verkrijgt een toegangstoken dat is afgestemd op zijn geautoriseerde workflow. Wanneer Agent A delegeert aan Agent B, gebruikt hij de RFC 8693 Token Exchange om een ​​gedelegeerd toegangstoken voor Agent B te verkrijgen, dat zowel de identiteit van Agent A als die van Agent B (en de beperkingen van de delegatie) codeert. Agent B gebruikt zijn eigen PKIaaS-certificaat voor mTLS-authenticatie bij het presenteren van dit gedelegeerde token. Elk systeem dat Agent B aanroept, kan de volledige delegatieketen verifiëren aan de hand van de claims van het token en het certificaat dat in de mTLS-handshake wordt gepresenteerd.

Beveiliging van AI-infrastructuur: verder dan agentidentiteit

De identiteit van AI-agenten is de meest zichtbare toepassing van PKI voor AI-infrastructuur, maar niet de enige. De infrastructuur die AI ondersteunt, vereist ook beveiliging die door PKI wordt ondersteund.

Model voor het bedienen van infrastructuur

De inferentie-eindpunten van AI-modellen (ongeacht of ze on-premises, in cloudgebaseerde ML-platformen van providers of via API-services worden gehost) fungeren als de backends die door agents worden geraadpleegd. Deze eindpunten hebben TLS-certificaten nodig voor een veilige overdracht van gegevens. In omgevingen waar alleen geautoriseerde agents inferentie-eindpunten mogen aanroepen, moet het inferentie-eindpunt ook de identiteit van de agent verifiëren (mTLS op de inferentie-API-laag). Een PKIaaS-CA die certificaten uitgeeft aan zowel de inferentie-infrastructuur als de agents, creëert de vertrouwensbasis voor deze bidirectionele verificatie.

Trainings- en verfijningsinfrastructuur

De infrastructuur voor het trainen en finetunen van AI-modellen verwerkt gevoelige gegevens: trainingsdatasets, modelgewichten, evaluatieresultaten en feedbackgegevens. Communicatie tussen componenten van de trainingsinfrastructuur (dataladers, rekenknooppunten, opslag voor modelcheckpoints, services voor het bijhouden van experimenten) moet gebruikmaken van TLS-certificaten die zijn uitgegeven door de PKIaaS-CA van de organisatie, in plaats van zelfondertekende certificaten. Dit zorgt ervoor dat de interne communicatie van de trainingsinfrastructuur is geauthenticeerd en versleuteld binnen de vertrouwenshiërarchie van de organisatie, en dat auditlogboeken de certificaatidentiteit vastleggen van elke component die betrokken is bij de modeltraining.

Model artefact ondertekening

Artefacten van AI-modellen (gewichten, configuratiebestanden, prompttemplates, tooldefinities) moeten worden ondertekend met codeondertekeningscertificaten die zijn uitgegeven door de PKIaaS CA. Een modelartefact dat is ondertekend door de PKIaaS CA van de organisatie kan worden geverifieerd als authentiek (geproduceerd door het geautoriseerde modelontwikkelingsproces van de organisatie) en ongewijzigd (de handtekening is ongeldig als het artefact na ondertekening is gemanipuleerd). Dit is het AI-equivalent van beveiliging van de softwareleveringsketen: net zoals codeondertekening garandeert dat geïmplementeerde software is geproduceerd door een geautoriseerde buildpipeline, garandeert ondertekening van modelartefacten dat geïmplementeerde modellen zijn geproduceerd door een geautoriseerde trainings- of finetuningpipeline.

Agentic Framework-infrastructuur

De infrastructuurcomponenten van agentische AI-frameworks (orkestratoren, geheugenopslag, toolregisters, API's voor agentbeheer, observatieplatformen) zijn zelf services waarmee agenten en operators interageren. Deze componenten moeten beschikken over TLS-certificaten uitgegeven door de PKIaaS CA, en de API's die ze beschikbaar stellen, moeten mTLS-authenticatie vereisen van de agenten en operators die ze aanroepen. Een orkestratie-API die door elk niet-geauthenticeerd proces kan worden aangeroepen, is geen veilige orkestratielaag; het is een kwetsbaarheid in het controleplan die kan worden misbruikt door een agent waarvan de authenticatiecontext is gemanipuleerd.

Machine-identiteitsinventarisatie voor AI-agenten

De uitdaging van het bijhouden van machine-identiteiten, zoals beschreven in eerdere berichten over workload-identiteiten, is extra groot voor AI-agents. Agents worden namelijk sneller ingezet en weer buiten gebruik gesteld dan traditionele workloads. Een AI-platform met agents kan honderden agents per uur lanceren, elk met een uniek certificaat. Zonder een inventaris van machine-identiteiten die bijhoudt welke certificaten aan welke agents zijn uitgegeven en welke agents nog actief zijn en welke buiten gebruik zijn gesteld, verliest de organisatie vrijwel direct na de grootschalige implementatie het overzicht over de identiteit van haar AI-agents.

Een CLM-platform dat is gekoppeld aan de PKIaaS CA biedt de inventaris van machine-identiteiten voor AI-agents: elke certificaatuitgifte wordt geregistreerd met de identiteitskenmerken van de agent, het uitgiftetijdstempel, de geldigheidsperiode en de PKIaaS-auditlogboekvermelding die het certificaat koppelt aan het uitgifteverzoek. Voor agentcertificaten met een korte geldigheidsduur (1 tot 24 uur) toont de inventaris de huidige actieve agentpopulatie: welke agents certificaten hebben die momenteel geldig zijn en welke certificaten zijn verlopen (en de bijbehorende agents zouden niet langer actief moeten zijn). Als de CLM-inventaris een actief certificaat toont voor een agent waarvan de implementatie is beëindigd, is dat een signaal dat de beëindiging van de agent niet gepaard ging met een correcte verwijdering van de inloggegevens of dat het certificaat is gestolen voordat de agent werd beëindigd.

Voor het beheer van AI-agenten biedt de CLM-inventaris ook de mogelijkheid tot handhaving van het beleid: certificaten die zijn uitgegeven aan AI-agenten en waarvan de maximaal toegestane geldigheidsduur is overschreden, die zijn uitgegeven aan agenten met naamgevingsconventies die in strijd zijn met het organisatiebeleid, of die zijn uitgegeven aan agenten in omgevingen waarvoor ze geen autorisatie hebben, worden allemaal als beleidsschendingen aangemerkt. Deze schendingen kunnen worden gemarkeerd voor herstel voordat de agent een incident veroorzaakt.

Het auditspoor: AI-acties traceerbaar maken

Een van de governancevereisten voor AI-agenten in gereguleerde omgevingen is dat AI-acties traceerbaar moeten zijn: wanneer een AI-agent een beslissing neemt, een record wijzigt of een transactie initieert, moet er een controleerbaar verslag zijn van welke agent de beslissing heeft genomen, onder wiens autoriteit en binnen welk tijdsbestek. Certificaatgebaseerde agentidentificatie biedt deze traceerbaarheid op infrastructuurniveau in plaats van te vertrouwen op logging op applicatieniveau die de agenten zelf beheren.

De attributieketen werkt als volgt. De PKIaaS CA geeft op tijdstip T een certificaat uit aan Agent X met serienummer S, geldig gedurende 4 uur. Agent X gebruikt dit certificaat om zich te authenticeren bij de transactie-API. Het toegangslogboek van de transactie-API registreert het serienummer S van het clientcertificaat en de details van het verzoek. Het auditlogboek van PKIaaS registreert dat certificaat S is uitgegeven aan agent-identiteit "order-processing-agent-v2.1/production" op tijdstip T met een geldigheidsduur van 4 uur. Door de twee logboeken te combineren, ontstaat een volledige attributie: "Om 14:32:07 heeft de instantie order-processing-agent-v2.1 in de productieomgeving (certificaat S, uitgegeven om 14:00:00) de transactie-API aangeroepen en betalingstransactie #4472 geïnitieerd."

Deze toewijzing is cryptografisch onweerlegbaar: het certificaatserienummer in het toegangslogboek komt overeen met een specifieke privésleutel die is gegenereerd in de uitvoeringscontext van de specifieke agentinstantie. Geen enkel ander proces had certificaat S kunnen presenteren zonder de bijbehorende privésleutel te bezitten, en de privésleutel is gegenereerd in het geheugen van de agent, niet opgeslagen op een locatie waar een ander proces er toegang toe zou kunnen hebben. De toewijzing is niet afhankelijk van de eigen logboekregistratie van de agent, die een aanvaller die de agent heeft gecompromitteerd zou kunnen wijzigen.

Opkomende regelgevingssignalen voor de identiteit van AI-agenten

De regelgeving rondom de identiteit van AI-agenten bevindt zich nog in een vroeg stadium, maar ontwikkelt zich snel. Verschillende signalen uit 2025 en 2026 wijzen in de richting:

NIST NCCoE (2026): Het NIST National Cybersecurity Center of Excellence publiceerde in 2026 een conceptdocument over de identiteit en autorisatie van software en AI-agenten. Hieruit blijkt dat de belangrijkste Amerikaanse standaardisatie-instantie voor cyberbeveiliging werkt aan formele richtlijnen voor cryptografische identiteit van AI-agenten. Organisaties die nu al certificaatgebaseerde agentidentificatie ontwikkelen, lopen vooruit op wat waarschijnlijk een formele aanbeveling zal worden.

ITU-focusgroep: De Internationale Telecommunicatie Unie (ITU) heeft in 2026 een focusgroep opgericht voor vertrouwen en identiteit van AI-agenten, met als mandaat het ontwikkelen van internationale raamwerken voor agentidentiteit en verantwoording. Dit geeft aan dat de identiteit van AI-agenten wordt behandeld als een probleem op internationaal standaardiseringsniveau, en niet slechts als een leverancierspecifieke implementatiekeuze.

Verantwoordingseisen van de EU AI-wetgeving: De EU AI-wetgeving, die vanaf augustus 2024 gefaseerd wordt ingevoerd, vereist dat AI-systemen die als hoog risico worden geclassificeerd, logboeken bijhouden van hun activiteiten die voldoende zijn voor menselijk toezicht en verantwoording achteraf. Voor AI-systemen die autonoom handelen in risicocategorieën (beslissingen over tewerkstelling, kredietbeoordeling, beheer van kritieke infrastructuur) kan de verantwoordingsvereiste het gemakkelijkst worden voldaan door cryptografische toewijzing van de acties van de agent, wat certificaatgebaseerde identiteit mogelijk maakt.

Verwachtingen ten aanzien van AI-governance in de financiële sector: De EBA (Europese Bankautoriteit) en andere toezichthouders in de financiële sector integreren AI-governance in hun richtlijnen voor ICT-risicobeheer. Voor financiële instellingen die AI-agenten gebruiken om handel, kredietbeslissingen, klantenservice of fraudedetectie te automatiseren, omvatten de verwachtingen ten aanzien van AI-governance de controleerbaarheid van geautomatiseerde beslissingen, waarvoor de identiteit van de agent traceerbaar moet zijn.

Hoe encryptieconsultancy kan helpen

• PKI als een service: Encryptie Consulting's PKIaaS-aanbod Biedt de CA-infrastructuur voor AI-agentidentiteit: ACME+EAB voor OIDC-gebaseerde agentcertificaatvoorziening, REST API voor directe integratie met AI-orkestratieplatformen, SPIFFE upstream CA-plugin voor Kubernetes-gebaseerde agentimplementaties en certificaatprofielen ontworpen voor kortstondige, efemere agentidentiteit (15 minuten tot 4 uur geldig). Neem contact met ons op via Encryptie Consulting om de identiteitsarchitectuur van uw AI-agent te bespreken.
• CertSecure Manager: Encryptie Consulting's CertSecure Manager Biedt de machine-identiteitsinventarisatielaag voor AI-agentcertificaten: continue detectie van door PKIaaS uitgegeven agentcertificaten, vervaldatumbewaking met actieve agenttracking, beleidshandhaving voor certificaatvaliditeitsperioden en naamgevingsconventies, en SIEM-integratie die gebeurtenissen in de levenscyclus van agentcertificaten voedt in de beveiligingsmonitoringstack, samen met API-gatewaytoegangslogboeken voor de attributiecorrelatie die in dit bericht wordt beschreven.
• CBOM Secure: Voor organisaties die de cryptografische beveiliging van hun AI-infrastructuur beoordelen voordat ze agentidentificatie op basis van certificaten implementeren, biedt Encryption Consulting de volgende diensten aan. CBOM Secure Biedt cryptografische ontdekking die bestaande statische referenties (API-sleutels, tokens, clientgeheimen) blootlegt die worden gebruikt door AI-agenten en -infrastructuur, waardoor prioritaire migratie van statische referenties naar certificaatgebaseerde identiteit mogelijk wordt.
• PKI-diensten: Voor organisaties die de identiteitsarchitectuur van AI-agenten helemaal vanaf nul ontwerpen, inclusief de configuratie van OIDC-tokenuitwisseling, het ontwerpen van certificaatprofielen voor agentidentiteitskenmerken, mTLS-configuratie voor inferentie-eindpunten en orchestratie-API's, en het ontwerpen van delegatieketens met behulp van RFC 8693 Token Exchange, biedt Encryption Consulting de volgende oplossingen: PKI-diensten Het leveren van architectuuradvies en implementatieondersteuning voor elk onderdeel van het agentidentiteitsprogramma.
• Compliance-adviesdiensten: Voor organisaties in gereguleerde sectoren die agentische AI ​​inzetten (financiële dienstverlening onder DORA, gezondheidszorg onder HIPAA, federale instanties onder FISMA/FedRAMP of EU-entiteiten onder de AI Act), biedt Encryption Consulting de volgende oplossingen: Nalevingsadviesdiensten Breng de identiteitsarchitectuur van AI-agenten in kaart ten opzichte van de toepasselijke wettelijke vereisten voor verantwoording en controleerbaarheid, en produceer een raamwerk voor nalevingsbewijs dat aantoont hoe op certificaten gebaseerde agentidentificatie aan de relevante verplichtingen voldoet.

Conclusie

AI-agenten zijn machines. Ze hebben een machine-identificatie nodig. De technologie voor cryptografische machine-identificatie is al tientallen jaren in de praktijk getest binnen PKI; wat nieuw is, is de toepassing ervan op een klasse machines die sneller, autonomer en belangrijker zijn dan traditionele workloads. Een AI-agent die configuraties wijzigt, betalingen initieert of interactie heeft met kritieke systemen, mag niet minder goed geïdentificeerd zijn dan een webserver of een laptop die is aangesloten op een domein. De identificatie moet juist zorgvuldiger zijn, omdat de gevolgen van een niet-geïdentificeerde of geïmiteerde AI-agent geen 503-fout zijn; het zijn autonome acties die met de verkeerde autorisatie worden uitgevoerd.

PKIaaS biedt de CA-infrastructuur om unieke, kortstondige, verifieerbare identiteiten uit te geven aan AI-agents op de schaal en snelheid die agentische AI-implementaties vereisen. De patronen, OIDC-tokenuitwisseling voor provisioning, SPIFFE/SPIRE voor Kubernetes-gebaseerde agents, mTLS voor agent-naar-service-communicatie, certificaatgebaseerde OAuth voor autorisatiestromen en RFC 8693-tokenuitwisseling voor delegatieketens, zijn allemaal vandaag de dag productieklaar. De uitdaging is om ze te configureren en te integreren met de specifieke AI-orkestratieplatforms en -infrastructuur die de organisatie gebruikt.

Organisaties die nu al, voordat de implementatie van agenten zo groot wordt dat achteraf aanpassen niet meer praktisch is, certificaatgebaseerde identiteitsbeheer voor AI-agenten in hun programma's integreren, beschikken over het auditspoor, de verantwoordingsplicht en de toegangscontroles waar toezichthouders naar streven en die beveiligingsteams uiteindelijk zullen vereisen. Organisaties die wachten tot een wettelijke verplichting dit afdwingt, zullen achteraf een identiteitsinfrastructuur moeten toevoegen aan een reeds geïmplementeerde agentenpopulatie die daar oorspronkelijk niet voor ontworpen was.

Als uw organisatie AI-agenten inzet en een op certificaten gebaseerde identiteitsarchitectuur hiervoor wil ontwerpen, neem dan contact op met Encryption Consulting.

Dit bericht wordt elke zes maanden herzien en wanneer NIST, ITU, de EU AI Act-implementatieregelingen of belangrijke frameworks voor AI-agenten materiële updates publiceren met betrekking tot de vereisten of aanbevelingen voor de identiteit van AI-agenten.

Veelgestelde Vragen / FAQ

Waarom hebben AI-agenten een cryptografische identiteit nodig in plaats van API-sleutels?

API-sleutels zijn statisch, deelbaar, verlopen niet automatisch en bieden geen cryptografisch bewijs van welke specifieke agent ze heeft gebruikt. Een door PKIaaS uitgegeven X.509-certificaat is van korte duur, cryptografisch gekoppeld aan de uitvoeringscontext van de specifieke agent, niet-afwijsbaar en wordt automatisch geroteerd. Een gestolen certificaat is nutteloos na de geldigheidsperiode; een gestolen API-sleutel is bruikbaar totdat deze handmatig wordt geroteerd. Het IBM Cost of Data Breach 2025-rapport toonde aan dat 97% van de organisaties die te maken kregen met inbreuken op AI-modellen geen toegangscontrole voor AI hadden.

Wat is het probleem van de delegatieketen van AI-agenten?

In workflows met meerdere agenten delegeert agent A taken aan agent B, die tools aanroept en transacties initieert. Elke stap moet cryptografisch aantoonbaar zijn en terug te leiden naar een verantwoordelijke principal. Zonder cryptografische delegatieketens kan elke agent elke autorisatie claimen. Certificaatgebaseerde identiteit in combinatie met OAuth 2.0 Token Exchange (RFC 8693), verankerd aan PKIaaS-certificaten, biedt het technische mechanisme voor een verifieerbare delegatieketen waarin de identiteit en autorisatieomvang van elke stap cryptografisch aantoonbaar zijn.

Hoe werkt mTLS voor communicatie tussen AI en services?

mTLS vereist dat zowel de AI-agent als de service certificaten presenteren en verifiëren voordat de verbinding tot stand komt. De agent verifieert het certificaat van de service (waardoor aanroepen naar vervalste eindpunten worden voorkomen) en de service verifieert het certificaat van de agent (waardoor ongeautoriseerde agents op de TLS-laag worden geweigerd). Certificaatgebaseerde OAuth (RFC 8705) breidt dit uit door OAuth-toegangstokens te koppelen aan de certificaatvingerafdruk van de agent, waardoor gestolen toegangstokens nutteloos zijn zonder de bijbehorende privésleutel.

Hoe kortstondig zouden certificaten voor AI-agenten geldig moeten zijn?

Voor tijdelijke agents die voor een enkele taak worden ingezet: 15 minuten tot 4 uur, overeenkomend met de verwachte duur van de taak. Voor permanente agentimplementaties: 24 tot 48 uur met automatische verlenging vóór de vervaldatum. De geldigheidsperiode moet kort genoeg zijn zodat een gecompromitteerd certificaat verloopt voordat een aanvaller er op zinvolle wijze misbruik van kan maken, en lang genoeg zodat de infrastructuur voor automatische verlenging het certificaat betrouwbaar vervangt voordat de agent zonder geldige referenties wordt uitgevoerd.

Wat is de wettelijke status van de vereisten voor de identiteit van AI-agenten?

Het is een opkomend, maar snel ontwikkelend onderwerp. Het NCCoE van NIST publiceerde een conceptdocument voor 2026 over de identiteit en autorisatie van software en AI-agenten. De ITU heeft een focusgroep voor 2026 opgericht over vertrouwen en identiteit van AI-agenten. De EU-wetgeving inzake kunstmatige intelligentie (AI) legt verplichtingen op met betrekking tot verantwoording en controleerbaarheid voor AI-systemen met een hoog risico. Toezichthouders in de financiële sector integreren AI-governance in hun richtlijnen voor ICT-risicobeheer. Certificaatgebaseerde cryptografische identiteit is het meest vol成熟e technische mechanisme om aan deze opkomende eisen op het gebied van verantwoording en toeschrijving te voldoen.