Het beheer van AI-agenten begint met de identiteit van de machine. 

De manier waarop bedrijven over AI praten is het afgelopen jaar veranderd. Vroeger ging de zorg vooral over wat een model zou kunnen zeggen, of het zou hallucineren, een geheim zou lekken of iets aanstootgevends zou genereren. Nu gaat het erom wat een model kán doen. AI-agenten zijn de demo-omgeving ontgroeid en in productie genomen, waar ze API's aanroepen, databases bevragen, geld overmaken en tickets indienen, waarbij ze de ene actie aan de andere koppelen met weinig menselijk toezicht. AI-agentgovernance is het proces van het toekennen, beperken, observeren en intrekken van wat een autonome agent mag doen. Machine-identiteit, een verifieerbare, cryptografisch verankerde authenticatie voor elke agent, is het controlepunt dat dit afdwingbaar maakt.

Die verandering is belangrijk omdat een agent die kan handelen, toestemming nodig heeft om te handelen, en toestemming is in de eerste plaats een identiteitsprobleem. Deze handleiding beschrijft waarom identiteit, en niet de prompt- of model-laag, de kern vormt van agentgovernance, waar governance momenteel tekortschiet, en hoe PKI-, beveiligings-, platform- en compliance-teams dit kunnen opbouwen op basis van een certificaatgestuurde machine-identiteit.

Key Takeaways

• Een AI-agent gedraagt ​​zich als een geprivilegieerde workload, niet als een chatbot: hij beschikt over inloggegevens, doet geauthenticeerde verzoeken en heeft daadwerkelijke toegang. Daarom moet governance beginnen op het niveau van de identiteit, niet op het niveau van de prompt.
• Gartner voorspelt dat tegen eind 2026 ongeveer 40% van de bedrijfsapplicaties AI-agents voor specifieke taken zullen bevatten, tegenover minder dan 5% in 2025. Microsoft meldt dat er alleen al met Copilot Studio meer dan een miljoen agents zijn gemaakt.
• De meeste agent-identiteiten die tegenwoordig in productie zijn, worden ondersteund door SPIFFE- of X.509-certificaten. Dit betekent dat de explosieve groei van machine-identiteiten ook een probleem vormt voor het beheer van de certificaatlevenscyclus, precies op het moment dat de geldigheidsperioden van openbare TLS-certificaten dalen tot ongeveer 47 dagen.
• 51% van de organisaties geeft aan geen duidelijk eigenaarschap te hebben over hun AI-identiteiten, en slechts 18% van de beveiligingsmanagers heeft er alle vertrouwen in dat hun identiteitssystemen überhaupt met agent-identiteiten overweg kunnen.
• De PKI-, beveiligings-, platform- en compliance-teams zijn elk verantwoordelijk voor een specifieke actie; de ​​onderstaande matrix met verantwoordelijkheden en acties en de beslissingstabel geven precies aan wat en wie verantwoordelijk is.

Ga direct naar: Samenvatting | Identiteit als controlepunt | De data achter de urgentie | Beslissingstabel | Eigenaar/Actie-matrix | Wat te doen? | Veelgestelde vragen

Samenvatting voor de teams PKI, Beveiliging, Platform en Compliance

Als u een van deze functies leidt, is dit de beslissing die in dit artikel wordt ondersteund, samen met een handige checklist om deze in de praktijk te brengen.

• PKI-teams: Beschouw elke AI-agent als een door certificaten ondersteunde workload-identiteit en ontwerp de CA-capaciteit voor een factor tien hogere uitgiftevolumes.
• Beveiligingsteams: Elimineer het gebruik van geleende en gedeelde inloggegevens voor agenten en handhaaf het principe van minimale bevoegdheden en just-in-time toegang voor elke agentidentiteit.
• Platform-/DevSecOps-teams: Automatiseer de uitgifte, rotatie en intrekking van agentidentiteiten via SPIFFE/SPIRE of een vergelijkbaar platform voor de levenscyclus van certificaten; handmatige processen kunnen de snelle groei van het aantal agents niet bijbenen.
• Nalevingsteams: Bevestig dat elke agentactie kan worden toegeschreven aan een vastgestelde identiteit en, voor workflows met meerdere agenten, aan de volledige delegatieketen terug naar een mens.

Waarom identiteit het werkelijke controlepunt is

Het is vanuit een beveiligingsperspectief belangrijk om precies te definiëren wat een AI-agent nu eigenlijk is. Zonder de termen over redeneren en autonomie blijft er een stuk software over dat inloggegevens bewaart, geauthenticeerde verzoeken doet en privileges uitoefent op echte systemen. Met andere woorden, het gedraagt ​​zich veel meer als een geprivilegieerde workload dan als een chatbot.

Die herinterpretatie is de kern van de zaak. Zodra je accepteert dat een agent een niet-menselijke actor is die toegang uitoefent, wordt de vraag naar governance vertrouwd: wie is dit, wat mag het aanraken en kun je bewijzen wat het heeft gedaan?

Identiteit vormt het natuurlijke knelpunt voor alle drie. Authenticatie bepaalt wie de agent is, autorisatie definieert waartoe deze toegang heeft, en een aan de identiteit gekoppeld auditspoor registreert wat de agent daadwerkelijk heeft gedaan. Als je een agent op een andere manier beheert, zie je het verkeer voorbijstromen zonder een actie te kunnen koppelen aan een verantwoordelijke identiteit, en zonder die koppeling is er geen sprake van governance, alleen van observatie achteraf.

Er is een diepere reden waarom identiteit het controlepunt moet zijn in plaats van de applicatie. Autorisatie die zich binnen de app bevindt, is precies wat een gecompromitteerde of via prompts geïnjecteerde agent kan omzeilen, omdat de agent de applicatie is. Een geldige authenticatie en een geautoriseerde sessie garanderen niet langer een veilige uitkomst. Door de beslissing te verplaatsen naar de identiteitslaag, naar wat deze agent is en wat deze mag doen, komt de handhaving op een plek waar een gemanipuleerde prompt geen toegang toe heeft.

Dit is precies de reden waarom de OWASP Top 10 voor agenttoepassingen, die in december 2025 werd gepubliceerd als de eerste formele taxonomie van agentspecifieke risico's, identiteits- en privilegemisbruik opneemt in de hoofdcategorieën, naast doelkaping en regelrechte malafide agenten. Het patroon dat deze risico's gemeen hebben, is dat een agent iets doet wat hij nooit had mogen doen, omdat de onderliggende identiteits- en toegangsstructuur te breed, te veel geleend of te slecht gecontroleerd was om dit te voorkomen.

Het schaalprobleem: wanneer machines in de meerderheid zijn ten opzichte van mensen.

Dit is de ongemakkelijke achtergrond. Machine-identiteiten zijn al vele malen talrijker dan menselijke identiteiten, volgens sommige schattingen meer dan 80 tegen 1 binnen een organisatie, en AI-agenten gooien olie op het vuur dat al brandde. De exacte verhouding varieert per omgeving en methodologie, maar de richting is onmiskenbaar, en een groot deel van die identiteiten heeft toegang tot gevoelige of bevoorrechte gegevens waar nooit een mens toezicht op zal houden.

Dat volume zou beheersbaar zijn als de identiteiten goed gereguleerd waren, maar dat is over het algemeen niet het geval. Recent onderzoek in de sector wees uit dat 51% van de organisaties geen duidelijke eigenaar heeft van hun AI-identiteiten, wat betekent dat meer dan de helft zelfs niet kan zeggen wie verantwoordelijk is voor een bepaalde agent of authenticatiegegevens. En in een enquête uit eind 2025 had slechts 18% van de beveiligingsmanagers er veel vertrouwen in dat hun bestaande identiteitssystemen überhaupt agentidentiteiten aankonden.

Het patroon is consistent: organisaties implementeren autonome software veel sneller dan dat ze de identiteitsstructuur ontwikkelen om die software te beheren.

De data die de urgentie onderbouwen

Agentidentiteit is geen losstaand probleem van certificaatlevenscyclusbeheer, maar een snelgroeiend onderdeel ervan. De meeste frameworks voor agentidentiteit, waaronder SPIFFE/SPIRE en het eigen agentidentiteitsmodel van Google Cloud, baseren hun vertrouwen op kortstondige X.509-certificaten. Dat betekent dat elke nieuwe agent, achter de marketingpraatjes, een nieuwe certificaatgebruiker is, precies op het moment dat de geldigheid van openbare TLS-certificaten het snelst afneemt.

• 45% van de bedrijven ondervond het afgelopen jaar serviceonderbrekingen als gevolg van een certificaatgerelateerd incident, en 37.5% kon een storing specifiek herleiden tot een verlopen certificaat., volgens DigiCert's Trust Pulse-enquête, gepubliceerd op 2 juli 2025.
• De maximale geldigheidsduur van openbare TLS-servers wordt gefaseerd verhoogd naar 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029., bevestigd door de stemming SC-081v3 van het CA/Browser Forum en Sectigo's Analyse van 14 april 2025 van hetzelfde schema.
• Geschatte groei van de voorraad certificaten: Als de adoptie van agents het door Gartner voorspelde traject volgt naar 40% van de bedrijfsapplicaties tegen eind 2026, en zelfs maar een fractie van die agents een eigen X.509-ondersteunde identiteit heeft met een vernieuwingscyclus van 47 dagen, dan zou een middelgrote organisatie die momenteel een paar duizend certificaten beheert, haar jaarlijkse certificaatbeheer binnen enkele jaren met een factor tien kunnen zien toenemen. Dit komt niet door de groei van TLS-gebruik door mensen, maar alleen door de uitgifte van agent-identiteiten.
• Geen van deze cijfers beschrijft specifiek AI-agenten, maar samen schetsen ze de omgeving waarin agentidentiteit terechtkomt: een certificaatlevenscyclus die al onder druk staat door kortere geldigheidsperioden en op het punt staat een nieuwe en veel grotere groep niet-menselijke identiteiten te absorberen.

Waar agentgovernance faalt

Als je de machine-identiteit voor agents wilt herstellen, is het handig om te weten waar het vaak misgaat. Een aantal foutpatronen komen steeds weer terug.

Geleende en gedeelde inloggegevens

Omdat er vaak geen eenvoudige manier is om een ​​agent een eigen identiteit te geven, kiezen teams voor de gemakkelijkste weg en geven ze de agent de inloggegevens van een mens of een gedeeld toegangstoken. De agent gedraagt ​​zich dan alsof hij die persoon is, erft alle machtigingen en draagt ​​geen enkele verantwoordelijkheid. Op het moment dat dit gebeurt, misleidt uw auditlogboek u: de logboeken tonen iets dat een mens heeft gedaan, terwijl het in werkelijkheid door een autonoom proces is gedaan, en elk onderzoek achteraf begint vanuit een onjuiste veronderstelling.

Geen eigenaar, geen levenscyclus.

Menselijke identiteiten hebben een natuurlijke levenscyclus omdat ze verbonden zijn aan een echt persoon en een vastomlijnd systeem van identiteitsprocessen: toegang wordt verleend wanneer dat nodig is, rolveranderingen worden beoordeeld en toegang wordt ingetrokken zodra de persoon die niet langer nodig heeft. Niet-menselijke identiteiten hebben zo'n ankerpunt niet.

Ze worden aangemaakt door ontwikkelaars, automatisering of andere agenten, en ze overleven doorgaans het project dat hun bestaan ​​rechtvaardigde. Zonder eigenaar en een gedefinieerde levenscyclus hopen agent-identiteiten zich stilletjes op, behouden ze hun toegang voor onbepaalde tijd en worden het verweesde inloggegevens die niemand zich herinnert, maar die aanvallers maar al te graag vinden.

Buitensporige privileges en de geleidelijke toename van privileges.

Agenten krijgen vaak te veel bevoegdheden, simpelweg omdat brede machtigingen ervoor zorgen dat ze meteen aan de slag kunnen. Een agent carte blanche geven om zelf de beste oplossing voor een probleem te vinden, creëert in feite een insider die met één enkele kwaadaardige aanwijzing kan worden aangestuurd. In de praktijk hebben de meeste machine-identiteiten uiteindelijk meer privileges dan nodig, en in agentsystemen stapelt dit overschot zich op doordat agenten tools aan elkaar koppelen en stilletjes hun bereik vergroten.

Verbroken delegatieketens

Moderne agentworkflows omvatten zelden één enkele actor. Een coördinerende agent delegeert aan een subagent, die op zijn beurt delegeert aan een andere, waarbij elk potentieel handelt namens een mens die het hele proces heeft opgestart. Wanneer er iets misgaat, moet die delegatieketen helemaal terug worden gereconstrueerd tot de menselijke opdrachtgever die de opdracht heeft gegeven. Standaard tokenmechanismen zijn nooit ontworpen om die traceerbaarheid te behouden, waardoor de verantwoordelijkheid ergens halverwege de keten verdwijnt. Als je niet kunt achterhalen wie deze agent heeft gedelegeerd, op wiens gezag en voor welke taak, heb je in feite helemaal geen governance.

Beslissingstabel: Het juiste antwoord vinden bij lacunes in het bestuur van agenten

Gebruik deze checklist om een ​​veelvoorkomend probleem met de identificatie van agenten te koppelen aan de aanbevolen actie, de operationele verantwoordelijke en het verwachte resultaat.

Use Case	Aanbeveling	Operationeel eigenaar	Verwacht resultaat
Agent die gebruikmaakt van de geleende inloggegevens van een mens.	Verstrek de agent een eigen identiteit die is ondersteund door SPIFFE/X.509.	Platform-/DevSecOps-team	Handelingen die toerekenbaar zijn aan de daadwerkelijke dader, niet aan een menselijke tussenpersoon.
Agentidentiteit zonder toegewezen eigenaar	Een eigenaar en een gedefinieerde levenscyclus zijn vereist tijdens het inrichten.	PKI-team	Er zijn geen achtergebleven agentgegevens die na afloop van het project bewaard zijn gebleven.
Agent overgeprovisioneerd met brede toegang	Beperk machtigingen tot specifieke resources en taken; pas het zero trust-principe toe.	Beveiligingsteam	Een gecompromitteerde prompt blijft een op zichzelf staande fout, geen systeeminbreuk.
Multi-agent delegatieketen	Voer een verifieerbare delegatielijn terug tot de menselijke oorsprong.	Beveiligingsteam met goedkeuring van de compliance-afdeling.	Elke actie is traceerbaar naar wie deze heeft geautoriseerd en waarom.
Het aantal agenten groeit sneller dan het aantal handmatige uitgiften.	Automatiseer de uitgifte, rotatie en intrekking van certificaten.	Platform-/DevSecOps-team	De identiteitslevenscyclus houdt gelijke tred met de wildgroei aan agents, zonder handmatige knelpunten.
Audit of onderzoek door toezichthouder naar handelingen van agenten	Zorg voor continue, identiteitsgerichte monitoring en registratie.	Complianceteam	Controleerbaar bewijsmateriaal dat gereed is voordat een toezichthouder erom vraagt.

Het bouwen van een bestuursmodel gebaseerd op machine-identiteit.

Het goede nieuws is dat dit allemaal geen volledig nieuwe beveiligingsoplossingen vereist. De identiteitsdiscipline die de toegang van mensen en de communicatie tussen machines de afgelopen twee decennia heeft versterkt, kan naadloos worden toegepast op agents zodra je ze als volwaardige identiteiten beschouwt. Een paar prioriteiten zijn het belangrijkst.

Ontdek de agenten waarvan je niet wist dat je ze had.

Voordat je een agent kunt beheren, moet je weten dat hij bestaat, en dat is lastiger dan het lijkt. Agents worden aangemaakt binnen SaaS-platforms, cloudservices, ontwikkelaarstools en code-assistenten, vaak zonder dat er ooit aan beveiliging wordt gedacht. Dit is het probleem van schaduw-AI: een populatie van ongecontroleerde agents die stilletjes toegang vergaren zonder dat iemand een lijst bijhoudt.

De eerste praktische stap richting governance is daarom het ontdekken van certificaten : het opbouwen en continu bijwerken van een inventaris van elke agent in uw omgeving, samen met de details die relevant zijn voor risicobeheer, zoals wie de eigenaar is, welke referenties de agent heeft, op welke modellen en tools de agent vertrouwt en wat de agent kan bereiken. Het principe is eenvoudig: u kunt niet controleren, monitoren of intrekken wat u niet kunt zien, dus zichtbaarheid moet voorop staan.

Geef elke agent een eigen, verifieerbare identiteit.

De allerbelangrijkste stap is om te stoppen met het lenen van identiteiten door agents en ze in plaats daarvan hun eigen identiteit te laten toekennen. De identiteit van een agent moet cryptografisch verifieerbaar zijn, gekoppeld aan de workload en de locatie waar deze wordt uitgevoerd, en van korte duur zijn in plaats van een lang bewaard geheim in een configuratiebestand. Dit is precies het probleem dat de SPIFFE-standaard en de SPIRE-implementatie ervan beogen op te lossen. Het is belangrijk om te weten wat een SPIFFE-identiteitsdocument in feite is: in de meeste implementaties is het een kortstondig X.509-certificaat.

Het agentidentiteitsmodel van Google Cloud volgt hetzelfde patroon: toegangstokens worden gekoppeld aan de unieke X.509-certificaten van een agent, waardoor het veel moeilijker is om een ​​gestolen token opnieuw te gebruiken. Met andere woorden, de basis voor een betrouwbare agentidentiteit is dezelfde infrastructuur voor openbare sleutels die al die tijd de basis vormde voor machinevertrouwen, en elk certificaat dat de infrastructuur nu uitgeeft, valt onder dezelfde geldigheidsduur van 47 dagen als de rest van uw certificaten.

Beheer de volledige levenscyclus

Een identiteit die u niet kunt buiten gebruik stellen, is een risico dat zich in de toekomst zal manifesteren. Agentidentiteiten vereisen dezelfde levenscycluscontroles als elke andere gevoelige referentie: provisioning die vastlegt wie de identiteit bezit en waarom deze bestaat, geautomatiseerde rotatie zodat referenties nooit lang statisch blijven, en betrouwbare intrekking zodra een agent buiten gebruik wordt gesteld of zich misdraagt.

Omdat deze inloggegevens van korte duur zijn en in grote aantallen voorkomen, is handmatig beheer simpelweg geen optie. Automatisering is hier geen luxe, maar een vereiste; de ​​enige manier om het aanmaken, rouleren en intrekken van inloggegevens gelijke tred te laten houden met de groeiende populatie agents.

Handhaaf het principe van minimale bevoegdheden en nul vertrouwen.

Elke agent moet de meest beperkte set machtigingen krijgen die nodig is om zijn werk te doen, beperkt tot specifieke resources en idealiter tot specifieke taken. Door daar bovenop zero-trust -principes toe te passen, krijgt geen enkel verzoek zomaar een vrijbrief omdat het afkomstig is van een reeds geauthenticeerde agent; elke actie wordt op het moment dat deze plaatsvindt beoordeeld op identiteit, reikwijdte en beleid.

Het doel is om niet langer te vragen wie er in het vorige kwartaal toegang had, maar om continu te kunnen antwoorden wat deze agent op dit moment mag doen en waarom. Wanneer je identiteitsverificatie als laatste verdedigingslinie beschouwt, blijft één enkele fout in de toegangscontrole een incident op zich, in plaats van uit te monden in een systeemwijde inbreuk.

In de praktijk leent het principe van minimale bevoegdheden voor agents een aantal mechanismen van beheer van geprivilegieerde toegang. Just-in-time provisioning verleent verhoogde toegang alleen op het moment dat deze daadwerkelijk nodig is en trekt deze daarna weer in, in plaats van permanente bevoegdheden te behouden. De meest gevoelige acties kunnen worden afgeschermd door menselijke goedkeuring of een extra authenticatiestap. Het is ook nuttig om de mogelijkheid te behouden een agent onmiddellijk te schorsen of uit te schakelen als het gedrag ervan afwijkend wordt, zodat een gekaapte agent kan worden gestopt voordat deze blijvende schade aanricht.

Continue monitoring en het traceerbaar houden van de keten.

Governance is geen eenmalige configuratie; het is continu toezicht. Realtime monitoring van agentactiviteit stelt u in staat subtiele signalen op te vangen voordat ze escaleren. Voor agents zijn de signalen die de moeite waard zijn om in de gaten te houden vrij specifiek: een agent die resources probeert te gebruiken die buiten zijn normale takenpakket vallen, een poging om zijn eigen privileges te verhogen, of een actie die simpelweg niet overeenkomt met de taak die hij geacht wordt uit te voeren.

Net zo belangrijk is dat elke actie herleidbaar moet zijn tot een vastgestelde identiteit en, bij workflows met meerdere agenten, tot de volledige delegatieketen die teruggaat naar een mens. Die traceerbaarheid zorgt ervoor dat een stapel logbestanden daadwerkelijk iets wordt waar je verantwoording voor kunt afleggen wanneer een toezichthouder, een auditor of een incidentresponder erom vraagt.

Houd je aan de normen, niet alleen aan de hype.

Het governance-landschap ontwikkelt zich snel. Naast de OWASP Top 10 voor agentische applicaties lanceerde NIST in februari 2026 zijn AI Agent Standards Initiative, en het National Cybersecurity Center of Excellence publiceerde een conceptdocument over de identiteit en autorisatie van AI-agenten. Dit is een duidelijk signaal dat agentidentiteit een formeel standaardiseringsvraagstuk aan het worden is.

De regelgeving ontwikkelt zich parallel, met de verplichtingen voor risicovolle AI-systemen in de EU-wetgeving en diverse nationale AI-wetten die tot 2026 van kracht worden. Tegelijkertijd bieden frameworks zoals het NIST AI Risk Management Framework organisaties een gestructureerde manier om te documenteren hoe hun agents worden beheerd. De conclusie is simpel: het bouwen van agentgovernance op basis van verifieerbare machine-identiteit is niet langer alleen goede beveiliging, het is de houding die auditors en toezichthouders van u verwachten.

Eigenaar- en actiematrix per team

Team	Verantwoordelijkheid	Belangrijkste actie
PKI-team	Beschikt over de capaciteit om certificaten uit te geven voor agentidentiteiten.	Het model voorspelt het verwachte volume aan agentgestuurde certificaten ten opzichte van de huidige capaciteit van de CA en CLM.
Beveiligingsteam	Heeft expertise in het principe van minimale bevoegdheden, het bewaren van referenties en het waarborgen van integriteit bij delegatie.	Schrap geleende referenties en eis verifieerbare delegatieketens.
Platform-/DevSecOps-team	Beheert de geautomatiseerde identiteitslevenscyclus van agenten.	Integreer SPIFFE/SPIRE of een vergelijkbaar platform in de agentprovisioning-pipelines.
Complianceteam	Beschikt over controlebewijsmateriaal voor acties van agenten.	Bevestig dat elke agentactie resulteert in een identiteit en een delegatieketen.

Wat te doen Volgende

• PKI-teams: De verwachte toename in het aantal uitgegeven certificaten als gevolg van de groei van agentidentiteiten vóór de 100-dagen TLS-validiteitsfase in maart 2027 verhoogt de belasting.
• Beveiligingsteams: Controleer of er in de productieomgeving nog steeds agenten zijn die gebruikmaken van geleende menselijke inloggegevens of een gedeeld token.
• Platformteams: Test dit kwartaal de geautomatiseerde, op certificaten gebaseerde identiteitsverstrekking voor uw medewerker met de hoogste bevoegdheden.
• Nalevingsteams: Controleer of uw auditkader de identiteits- en delegatielogboeken van agenten al als bewijsmateriaal accepteert, of meld deze lacune nu.

Hoe kan Encryption Consulting u helpen?

Als de identiteit van een agent uiteindelijk gebaseerd is op certificaten en PKI, dan vormt de manier waarop u die machine-identiteitslaag beheert de basis van uw gehele agentbeheerstrategie. Dit is precies waar CertSecure Manager van Encryption Consulting van pas komt. CertSecure Manager is een leveranciersneutrale oplossing voor certificaatlevenscyclusbeheer die de ontdekking, automatisering, inschrijving, beleidshandhaving en integraties in uw omgeving centraliseert.

Het voorkomt storingen door middel van geautomatiseerde verlengingen, versterkt de naleving van regelgeving, stroomlijnt IT-processen en verenigt het beheer van openbare en particuliere certificeringsinstanties via één geautomatiseerd en schaalbaar platform.

Naarmate AI-agenten het aantal machine-identiteiten dat u moet beheren vermenigvuldigen, bieden de geautomatiseerde detectie, robuuste op rollen gebaseerde toegangscontrole en continue zichtbaarheid van certificaatbewerkingen van CertSecure Manager u het levenscyclusbeheer en de handhaving van het principe van minimale bevoegdheden die agentomgevingen vereisen. Zo blijven de cryptografische identiteiten waarvan uw agenten afhankelijk zijn actueel, afgebakend en traceerbaar, in plaats van onoverzichtelijk te worden.

Om de bescherming verder uit te breiden, breidt CBOM Secure de detectie uit van certificaten naar uw volledige cryptografische landschap van algoritmen, sleutels en protocollen. Dit resulteert in een cryptografische materiaallijst die compliance ondersteunt en u voorbereidt op de post-kwantumtransitie die volgt op deze schaal van identiteitsgroei. Onze CBOM: van inventaris tot intelligentie- handleiding beschrijft hoe u die inventaris kunt omzetten in een doorlopend programma voor crypto-flexibiliteit. Omdat de identiteitskeuzes die u vandaag maakt voor agenten ook na de kwantumtransitie van invloed zijn, helpen ons PQC Center of Excellence en het 9-fasen PQC-gereedheidsplan u bij het plannen van crypto-flexibiliteit voor de certificaatinfrastructuur waar uw agenten van afhankelijk zullen zijn.

Gerelateerde artikelen van Encryption Consulting

• Het juiste moment om een ​​MVO-plan op te stellen Dit omvat de certificaataanvraagstap waar elke SPIFFE/X.509-ondersteunde agentidentiteit van afhankelijk is.
• Het automatiseren van certificaatbeheer in Azure Key Vault Dit omvat de orchestratielaag die nodig is om het grote volume aan agentgestuurde certificaten te verwerken.
• Een certificaatinschrijvingsprocedure kiezen: ACME vs. EST vs. SCEP vs. CMP Dit omvat de geautomatiseerde inschrijvingsprotocollen die de uitgifte van certificaten op schaal mogelijk maken voor agentenpopulaties.
• Handleiding voor de migratie van post-kwantumcryptografie (9 fasen) schetst de routekaart voor crypto-flexibiliteit die de groei van machine-identiteit volgt.

Conclusie

AI-agenten zijn werkelijk transformatief en de productiviteitswinst is zo reëel dat geen enkele voorzichtigheid hun acceptatie zal vertragen. Dat maakt het des te belangrijker om helder te kijken naar wat er nodig is om ze te besturen. De verleiding is groot om besturing te zien als een kwestie van betere aanwijzingen en slimmere vangrails op modelniveau. Hoe nuttig die ook zijn, ze staan ​​los van een fundamentelere vraag: of elke agent een verifieerbare identiteit heeft, een passende toegangsomvang en een traceerbaar spoor achter alles wat hij doet.

Beantwoord die vraag goed, en de rest van uw governanceprogramma heeft een solide basis om op voort te bouwen. Sla die vraag over omdat de agents werken en de deadline nadert, en u stilletjes het grootste onbeheerde aanvalsoppervlak creëert dat uw organisatie ooit heeft gehad, één overbevoorrechte, eigenaarloze, nooit geroteerde identiteit tegelijk.

Agenten als volwaardige identiteiten behandelen, hun vertrouwen verankeren in een goed beheerde PKI, hun levenscyclus automatiseren en ze onderwerpen aan het principe van minimale bevoegdheden en continu toezicht, is geen eenmalig project maar een voortdurende verbintenis. Het is het verschil tussen het waarmaken van de beloften van agentische AI ​​en erdoor ten onder gaan. In een omgeving waar niet-menselijke identiteiten mensen al vele malen in aantal overtreffen, is machine-identiteit geen bijzaak in AI-governance. Het is de basis waarop alles rust en waar het allemaal begint.

Deze richtlijnen worden elke zes maanden herzien voor altijd actuele uitlegdocumenten zoals deze, en onmiddellijk wanneer het CA/Browser Forum, NIST of een belangrijk AI-platform wijzigingen aanbrengt in de vereisten van deze processen.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie van AI Agent Governance Starts With Machine Identity?

AI-agenten gedragen zich als geprivilegieerde workloads, niet als chatbots, dus effectief beheer moet verankerd zijn op het identiteitsniveau in plaats van het promptniveau. Door elke agent een eigen, verifieerbare, certificaatondersteunde identiteit te geven, met minimale bevoegdheden, geautomatiseerd levenscyclusbeheer en een traceerbare delegatieketen, wordt beheer afdwingbaar in plaats van een utopie.

Waarom is dit belangrijk voor het beheer van de levenscyclus van certificaten?

De meeste frameworks voor agentidentiteit, waaronder SPIFFE/SPIRE en het agentidentiteitsmodel van Google Cloud, worden ondersteund door kortstondige X.509-certificaten. Naarmate het gebruik van agents toeneemt richting de door Gartner voorspelde 40% van de bedrijfsapplicaties tegen eind 2026, neemt de last van de uitgifte en verlenging van certificaten snel toe. Dit komt precies op het moment dat het CA/Browser Forum de maximale geldigheidsduur van openbare TLS-certificaten tegen 2029 terugbrengt tot 47 dagen.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen?

PKI-teams zijn verantwoordelijk voor de uitgifte van certificaten voor agentidentiteiten; beveiligingsteams zijn verantwoordelijk voor het principe van minimale bevoegdheden, de beveiliging van inloggegevens en de integriteit van delegaties; platform- en DevSecOps-teams zijn verantwoordelijk voor het automatiseren van de levenscyclus van agentidentiteiten; en compliance-teams zijn verantwoordelijk voor het bevestigen dat elke agentactie resulteert in een identiteits- en delegatieketen. De bovenstaande matrix met verantwoordelijkheden en acties geeft een gedetailleerde uitleg per team.

Welke risico's nemen toe als de agentidentiteit handmatig wordt beheerd?

Het handmatig beheren van agentidentiteiten leidt tot geleende of gedeelde referenties die de verantwoordelijkheid wegnemen, tot agentidentiteiten zonder eigenaar of levenscyclus, tot buitensporige permanente privileges die door één enkele gecompromitteerde prompt kunnen worden misbruikt, en tot verbroken delegatieketens waardoor het onmogelijk is een actie te herleiden naar de persoon die deze heeft geautoriseerd. Uit het Trust Pulse Survey van DigiCert bleek dat 37.5% van de certificaatgerelateerde storingen rechtstreeks te wijten was aan een verlopen certificaat, een risico dat toeneemt naarmate het aantal agentgestuurde certificaten groeit.

Hoe vermindert automatisering het risico op uitval van agentidentiteit en certificaten?

Het automatiseren van de uitgifte, rotatie en intrekking van certificaatgebaseerde agentidentiteiten via SPIFFE/SPIRE of een vergelijkbaar platform voor de certificaatlevenscyclus, elimineert de handmatige stap die er het meest waarschijnlijk toe leidt dat een referentie veroudert of een agentcertificaat ongemerkt verloopt. Omdat agentidentiteiten een korte levensduur hebben en in grote aantallen voorkomen, zorgt automatisering ervoor dat de verlenging actueel blijft in plaats van een bron van storingen te worden.

Welke statistieken moeten teams bijhouden na de implementatie?

Houd het percentage agent-identiteiten bij met een gedocumenteerde eigenaar, het aantal agents dat nog steeds geleende of gedeelde referenties gebruikt, het aantal agent-gebaseerde certificaten onder geautomatiseerd lifecyclemanagement, delegatieketens die volledig terug te voeren zijn op een menselijke principal, en certificaatgerelateerde incidenten waarbij een agent-identiteit betrokken is. Rapporteer deze gegevens elk kwartaal naarmate de adoptie van agents toeneemt.

Hoe hangt dit samen met de 47-daagse TLS-certificaatgereedheid?

Het schema van het CA/Browser Forum verkort de maximale geldigheidsduur van openbare TLS-certificaten tot 200 dagen op 15 maart 2026, 100 dagen op 15 maart 2027 en 47 dagen op 15 maart 2029. Omdat de meeste agent-identiteitsframeworks X.509-certificaten ondersteunen, geldt dezelfde vernieuwingsfrequentie van 47 dagen die van toepassing is op web-TLS ook voor elke agent-identiteit die op certificaten is gebaseerd. Dit maakt geautomatiseerde uitgifte en vernieuwing een vereiste voor agentbeheer op grote schaal, en niet slechts een extraatje voor certificaatbeheer.

Hoe moet dit worden aangepakt in multi-cloud- of hybride PKI-omgevingen?

Standaardiseer de uitgifte van agentidentiteiten op een CA-onafhankelijk certificaatlevenscyclusplatform, zoals CertSecure Manager, zodat agents die in meerdere clouds, on-premises infrastructuur en hybride PKI's draaien, allemaal hun identiteit ontvangen via hetzelfde beleid, dezelfde algoritmen en hetzelfde auditspoor. Dit voorkomt dat het beheer van agentidentiteiten afzonderlijk voor elke cloudprovider of interne CA moet worden herontworpen.