AI Agent Identiteit: AI Agents Beveiligen en Beheren

AI agents kunnen meer dan alleen antwoorden genereren. Ze kunnen databases raadplegen, tickets aanmaken, API's aanroepen, records bijwerken en coördineren met andere agents om een taak te voltooien. Maar naarmate deze systemen toegang krijgen tot enterprise-bronnen, wordt één beveiligingsvraag moeilijker te negeren: hoe weet u welke agent een actie heeft uitgevoerd, op wiens verzoek deze handelde en of deze daarvoor de juiste machtiging had?

De meeste authenticatiesystemen zijn ontworpen voor menselijke gebruikers en toepassingen. AI agents passen in geen van beide categorieën. Een agent kan autonoom handelen, tijdens runtime tools kiezen en meerdere bewerkingen uitvoeren namens verschillende gebruikers. Als u een agent de inloggegevens van een menselijke gebruiker of een gedeeld serviceaccount geeft, wordt het moeilijk om die acties te traceren en te controleren.

Dit is waar AI agent identiteit om de hoek komt kijken. Het geeft elke geregistreerde agent een verifieerbare identiteit, waardoor beveiligingsteams de agent kunnen authenticeren, de machtigingen ervan kunnen definiëren en de acties ervan kunnen traceren zonder de persoon of service achter een verzoek uit het oog te verliezen.

Deze gids legt uit wat AI agent identiteit is, hoe het verschilt van traditionele niet-menselijke identiteiten en hoe u het kunt implementeren in enterprise AI-systemen.

Beveilig elke AI agent met TrueFoundry

Geef elke agent een verifieerbare identiteit, dwing toegangsbeleid af en behoud zichtbaarheid in AI-workflows

Boek een demo

Wat Is AI Agent Identiteit?

AI agent identiteit is de verifieerbare credential die een geregistreerde agent presenteert bij elke aanroep die hij doet. Het beantwoordt een vraag die tokens alleen niet kunnen beantwoorden: niet "is er een geldige credential gepresenteerd", maar "welke agent belt er, en voor wie handelt deze op dit moment."

TrueFoundry herkent al twee soorten principals, en een agent-identiteit is een derde.

De cruciale grens is delegatie. Een virtueel account kan alleen als zichzelf handelen, dus als u er een richt op een MCP server, ziet elke aanroep er hetzelfde uit, ongeacht wie de prompt gaf. Een agent-identiteit kan namens iemand anders handelen, dus een enkele geregistreerde agent die honderden mensen bedient, doet nog steeds aanroepen die toewijsbaar blijven aan de persoon voor wie het verzoek is, terwijl deze herkenbaar blijft als de agent. Dat is de eigenschap die agent-verkeer auditeerbaar maakt.

Hoe Verschilt Agent Identiteit van Menselijke en Service Identiteit?

Menselijke identiteit, service-identiteit en agent-identiteit dienen verschillende doelen, zelfs wanneer ze binnen dezelfde workflow interactie hebben.

• Menselijke identiteit stelt vast wie een verzoek heeft geïnitieerd. Het is gekoppeld aan een persoon en diens toegewezen machtigingen.
• Service-identiteit stelt vast welke toepassing of service een verzoek doet. Het wordt veel gebruikt voor communicatie van toepassing tot toepassing.
• Agent-identiteit stelt vast welke AI agent een verzoek uitvoert en ondersteunt delegatie wanneer de agent handelt namens een gebruiker of service.

Denk aan een werknemer die een AI agent vraagt om een productieprobleem te onderzoeken. De agent raadpleegt een interne database, haalt een Jira-ticket op en bereidt een voorgestelde oplossing voor. De identiteit van de werknemer stelt vast wie de taak heeft geïnitieerd. De identiteit van de agent stelt vast welke agent de tool-calls heeft uitgevoerd. De delegatiecontext verbindt die acties met het verzoek van de werknemer.

Zonder deze scheiding kunnen logs alleen de werknemer of een gedeeld serviceaccount identificeren, waardoor beveiligingsteams geen betrouwbare manier hebben om de agent te onderscheiden die verantwoordelijk is voor een actie.

Wat Bevat een AI Agent Identiteit?

Een AI agent identiteit heeft meer nodig dan alleen een naam of ID. Het moet voldoende informatie bieden om de identiteit van de agent vast te stellen, te bepalen of deze toegang heeft tot een bron en verantwoording te behouden over gedelegeerde verzoeken.

Afhankelijk van de identiteitsimplementatie kan dit het volgende omvatten:

• Agent identifier: Een stabiele ID die de aanroeper koppelt aan een geregistreerde agent.
• Authenticatie-inloggegevens: Een verifieerbaar token of andere credential die de identiteit van de agent vaststelt.
• Eigendoms- en registratiemetadata: Informatie over het doel, de eigenaar en de lifecycle van de agent.
• Toegangsmachtigingen: Beleid dat definieert tot welke modellen, tools, API's of gegevens de agent toegang heeft.
• Delegatiecontext: Informatie die de gebruiker of service identificeert namens wie de agent handelt, indien van toepassing.
• Auditcontext: Claims en verzoekmetadata die helpen acties terug te voeren op de agent en het oorspronkelijke verzoek.

Niet elke implementatie bevat al deze velden in hetzelfde token. Sommige informatie kan zich in het agent registry bevinden of worden verstrekt via een afzonderlijk autorisatiemechanisme.

De belangrijke vereiste is dat authenticatie en autorisatie samenwerken. Een geldige credential stelt de identiteit vast; het verleent niet automatisch toegang tot elke bron. Het systeem moet ook de machtigingen van de agent controleren en, wanneer delegatie in het spel is, de autoriteit die gekoppeld is aan het oorspronkelijke verzoek.

Waarom Elke Agent Zijn Eigen Identiteit Nodig Heeft

Het geven van een unieke identiteit aan elke agent is de beslissing die het gehele governance-model ontgrendelt.

• Toewijzing. De ontvanger van een aanroep kan zien of de aanroeper een mens, een service of een specifieke agent is. Acties worden achteraf bewijsbaar, wat is wat een audit daadwerkelijk vereist.
• Beleid per agent. Eén persoon stelt veel agents aan, en deze zouden niet allemaal het volledige bereik van die persoon moeten erven. Jane's support-copilot die Jira leest en haar engineering-agent die erin schrijft, zijn verschillende principals, hoewel ze beiden voor Jane handelen. Met unieke identiteiten kunt u de scope per agent afbakenen.
• Geen anonieme agents. Als een agent een tool alleen kan bereiken door een geregistreerde identiteit te presenteren, wordt registratie het handhavingspunt. U krijgt gratis een organisatiebreed overzicht, en u kunt één problematische agent intrekken zonder de rest te raken.

Dat laatste punt is de stille winst. Zodra identiteit vereist is om te handelen, is het register geen documentatie meer, maar het controlepunt dat elke andere controle mogelijk maakt.

Hoe Werkt AI Agent Identiteit?

AI agent identiteit werkt via een reeks stappen die vaststellen welke agent een verzoek doet, de identiteit ervan verifiëren, bepalen waartoe deze toegang heeft en de acties traceren die deze uitvoert. Deze stappen verbinden identiteit met toegangscontrole gedurende de gehele workflow van een agent.

Identificatie

Identificatie wijst aan elke geregistreerde agent een unieke identiteit toe. Deze identiteit verbindt de agent met zijn registratiedetails, eigenaar en beoogde doel. Wanneer een verzoek een beschermde bron bereikt, kan het systeem deze identifier gebruiken om te bepalen welke agent de aanroep doet.

Authenticatie

Authenticatie verifieert dat de agent is wie hij beweert te zijn. Afhankelijk van de implementatie kan de agent een ondertekend token of een andere ondersteunde credential presenteren. Het ontvangende systeem valideert de credential en controleert relevante claims, zoals uitgever en doelgroep, voordat het verzoek wordt geaccepteerd.

Autorisatie

Autorisatie bepaalt wat de geauthenticeerde agent mag doen. Beleid kan de toegang beperken tot specifieke modellen, API's, MCP-servers, tools of gegevens. Een geldige identiteit verleent niet automatisch toestemming; het systeem moet de gevraagde actie toetsen aan de toepasselijke toegangsregels.

Delegatie

Delegatie stelt een agent in staat om te handelen namens een gebruiker of een andere service zonder zijn eigen identiteit te verliezen. Het systeem beoordeelt de autoriteit van de agent samen met de gedelegeerde context om te bepalen of de gevraagde actie is toegestaan. Dit helpt de verantwoording te behouden wanneer één agent meerdere gebruikers bedient.

Audit en Handhaving

Audit en handhaving zorgen ervoor dat identiteits- en toegangsbeleid gedurende de gehele workflow van toepassing zijn. Gateways kunnen verzoeken valideren, machtigingen afdwingen en relevante activiteiten vastleggen. Auditlogs moeten acties koppelen aan de agent en, indien beschikbaar, de initiërende gebruiker. Beveiligingsteams kunnen deze gegevens gebruiken om incidenten te onderzoeken, toegang te beoordelen en gecompromitteerde identiteiten in te trekken.

Wat Zijn de Beveiligingsrisico's van AI Agent Identiteit?

AI agents gebruiken enterprise-inloggegevens om toegang te krijgen tot tools, API's en gevoelige gegevens. Zonder de juiste identiteitscontroles kunnen ze machtigingen misbruiken, kwaadaardige instructies opvolgen of werken zonder toezicht.

Overmatige machtigingen (Over-privileged access)

Agents kunnen bredere machtigingen of langlopende API-sleutels ontvangen dan hun taken vereisen. Bij een inbreuk kunnen deze inloggegevens gevoelige systemen blootstellen.

Hoe deze risico's te verminderen: Pas least-privilege toegang toe, beperk inloggegevens tot specifieke bronnen, gebruik kortstondige tokens waar dit wordt ondersteund en beoordeel machtigingen regelmatig.

Geërfde machtigingen

Agents die gebruikmaken van gedeelde serviceaccounts of menselijke inloggegevens kunnen overmatige toegang erven. Dit maakt het ook moeilijker om te identificeren welke agent een actie heeft uitgevoerd.

Hoe deze risico's te verminderen: Wijs aan elke agent een unieke identiteit toe. Evalueer de machtigingen van de agent afzonderlijk van de machtigingen van de gebruiker en beperk gedelegeerde toegang tot wat de taak vereist.

Prompt injection en confused deputy

Kwaadaardige instructies die verborgen zijn in e-mails, documenten of webpagina's kunnen geauthenticeerde agents misleiden om hun legitieme machtigingen te misbruiken voor het uitvoeren van onbevoegde acties.

Hoe deze risico's te verminderen: Behandel externe inhoud als niet-vertrouwd, valideer tool-calls, dwing autorisatie af buiten het model en vereis menselijke goedkeuring voor gevoelige bewerkingen.

Verweesde en shadow agents

Vergeten of niet-goedgekeurde agents kunnen actieve inloggegevens behouden nadat hun oorspronkelijke doel is beëindigd, waardoor enterprise-bronnen blootgesteld blijven zonder duidelijk eigenaarschap of toezicht.

Hoe deze risico's te verminderen: Onderhoud een centraal agent registry, wijs duidelijk eigenaarschap toe, beoordeel inactieve agents regelmatig en trek inloggegevens in wanneer agents buiten gebruik worden gesteld.

Identiteitspoofing en misbruik tussen agents

Zwakke authenticatie tussen agents kan ervoor zorgen dat onbevoegde agents zich voordoen als vertrouwde workloads of interfereren met gedelegeerde taken, wat mogelijk gegevens blootlegt eller onbevoegde bewerkingen activeert.

Hoe deze risico's te verminderen: Authenticeer elke agent met verifieerbare inloggegevens, valideer token-claims en autoriseer verzoeken van agent tot agent voordat toegang tot tools of bronnen wordt verleend.

Gedragsverandering (Behavioral drift)

Het gedrag van een agent kan veranderen naarmate zijn instructies, tools of omgeving evolueren. Zonder runtime-monitoring kan hij acties uitvoeren buiten zijn beoogde rol terwijl hij geldige inloggegevens gebruikt.

Hoe deze risico's te verminderen: Monitor tool-calls en toegangspatronen, geef waarschuwingen bij ongebruikelijke activiteit, beoordeel machtigingswijzigingen en dwing een vast autorisatiebeleid af, ongeacht de beslissingen van de agent.

Agent Identiteit, MCP en Agent-tot-Agent Communicatie

AI agents vertrouwen op tools en andere agents om taken te voltooien, wat identiteitsverificatie bij elke verbinding belangrijk maakt. Het Model Context Protocol (MCP) standaardiseert hoe agents verbinding maken met externe tools en databronnen, terwijl agent-tot-agent communicatie agents in staat stelt werk aan elkaar te delegeren.

In beide gevallen helpt identiteit vast te stellen wie een verzoek doet en of die aanroeper gemachtigd is om de gevraagde actie uit te voeren.

Met MCP maakt een agent verbinding met een MCP-server om toegang te krijgen tot tools, bronnen of prompts. Authenticatie identificeert de aanroeper, terwijl autorisatie bepaalt welke bewerkingen deze mag uitvoeren. Een MCP gateway kan dit beleid centraal afdwingen, wat helpt voorkomen dat ongeregistreerde agents toegang krijgen tot beschermde tools.

Agent-tot-agent communicatie introduceert een extra delegatielaag. Wanneer de ene agent de andere vraagt om een taak uit te voeren, moet de ontvangende agent de identiteit van de aanroepende agent verifiëren en de machtigingen controleren die aan het verzoek zijn gekoppeld. Wanneer bij de taak een gebruiker betrokken is, moet het systeem die delegatiecontext behouden in plaats van de toegang van de eerste agent te behandelen als onbeperkte autoriteit.

Een veilige implementatie moet elke deelnemer authenticeren, inloggegevens en machtigingen bij elke vertrouwensgrens valideren en auditrecords bijhouden voor gedelegeerde acties. Hiermee kunnen teams activiteiten traceren via MCP tool-calls en workflows met meerdere agents, zonder te vertrouwen op gedeelde inloggegevens of een agent blindelings te vertrouwen omdat een andere agent deze heeft aangeroepen.

Hoe Ondersteunt Agent Identiteit Zero Trust Security?

Zero trust security volgt een eenvoudig principe: vertrouw een verzoek nooit uitsluitend omdat het afkomstig is van een intern systeem of een geauthenticeerde gebruiker. Elk verzoek moet worden geverifieerd en geautoriseerd. AI agent identiteit past dit principe toe op autonome agents die toegang zoeken tot enterprise-tools, API's en gegevens.

Een unieke identiteit voor elke agent helpt zero trust op verschillende manieren af te dwingen:

• Verifieer elke agent: Authenticeer de agent voordat deze toegang krijgt tot beschermde bronnen, ongeacht waar deze draait.
• Dwing least privilege af: Verleen alleen toegang tot de tools, gegevens en acties die vereist zijn voor de taak van de agent.
• Valideer gedelegeerde toegang: Controleer zowel de identiteit van de agent als de autoriteit van de gebruiker of service waarvoor deze handelt.
• Monitor activiteit continu: Traceer tool-calls, toegangspatronen en machtigingswijzigingen om verdacht gedrag te identificeren.
• Trek toegang in wanneer nodig: Schakel gecompromitteerde of buiten gebruik gestelde agents uit zonder niet-gerelateerde identiteiten te verstoren.

Een AI agent kan bijvoorbeeld geautoriseerd zijn om Jira-tickets te lezen, maar niet om ze te verwijderen. Zelfs als de agent een geldige identiteit heeft, moet een verzoek om een ticket te verwijderen worden geweigerd, tenzij de machtigingen die actie expliciet toestaan.

Met agent-identiteit en handhaving op gateway-niveau kunnen organisaties zero-trust-beleid consistent toepassen op AI agents, MCP-servers en verbonden enterprise-services.

Welke Standaarden Worden Gebruikt als Leidraad voor AI Agent Identiteitsbeheer?

Er is momenteel geen enkele standaard die elk aspect van agent-identiteit, delegatie, autorisatie en auditing dekt.

De belangrijkste standaarden en frameworks zijn onder meer:

• OAuth 2.0 en OpenID Connect (OIDC): OAuth ondersteunt gedelegeerde toegang tot API's, terwijl OIDC een authenticatielaag biedt. Samen helpen ze bij het vaststellen van identiteits- en autorisatiecontext in agent-workflows.
• SPIFFE/SPIRE: SPIFFE definieert een framework voor het toewijzen van verifieerbare identiteiten aan workloads in verschillende omgevingen. SPIRE implementeert SPIFFE en kan workload-credentials uitgeven, wat agents helpt te authenticeren bij andere services zonder te vertrouwen op langlopende statische geheimen.
• NIST AI Risk Management Framework (AI RMF): Dit vrijwillige framework helpt organisaties AI-risico's te identificeren, te beoordelen en te beheren. Het biedt bredere governance-richtlijnen die agent-identiteit en toegangscontroles aanvullen.
• NIST Software and AI Agent Identity and Authorization initiatief: NIST onderzoekt op standaarden gebaseerde benaderingen voor het identificeren van agents, het beheren van hun identiteiten en het autoriseren van hun acties. Dit werk richt zich op uitdagingen zoals delegatie, verantwoording en veilige toegang tot enterprise-bronnen.

Krijg AI agent-toegang onder controle

Beheer agent-identiteiten, beveilig MCP tool-toegang en pas gecentraliseerde autorisatie toe met TrueFoundry.

Boek een demo

Hoe TrueFoundry Agent-identiteit Uitgeeft en Beheert

Op TrueFoundry is een agent-identiteit geen los object dat u aanmaakt en achteraf toevoegt. Het is een stap bij het registreren van de agent, dus de identiteit en de agent zijn één-op-één gekoppeld. Registreer de agent en zijn identiteit ontstaat. Verwijder de agent en de identiteit verdwijnt mee.

Waar de credential vandaan komt

Tijdens de registratie kiest u hoe de agent bewijst wie hij is:

• Ondersteund door TrueFoundry. TrueFoundry geeft het token van de agent uit en ondertekent dit. Dit is de eenvoudigste optie en de juiste standaard voor agents die u zelf bouwt en beheert.
• Ondersteund door een identity provider. De agent authenticeert met een token van uw eigen provider, zoals Okta, Microsoft Entra, een willekeurige OIDC-provider of een SPIFFE- en SPIRE-endpoint. U koppelt specifieke claimwaarden aan de agent, zodat een inkomend token naar die agent verwijst. Dit pad maakt On-Behalf-Of (OBO) delegatie mogelijk, zodat de agent een gebruiker kan meenemen door de keten.

De identiteit betekent in beide gevallen hetzelfde. Alleen de uitgever verschilt, en u kunt uitgevers per agent mixen binnen één tenant.

TrueFoundry als de identity broker

Wanneer uw identity provider nog geen agent-identiteitsfunctionaliteit heeft, kan TrueFoundry alle drie de rollen van het control plane op zich nemen. Het geeft de identiteit van elke agent uit, autoriseert elke aanroep bij de Agent Gateway en MCP Gateway, en genereert met token-exchange een scoped credential voor elke hop. Uw enterprise SSO blijft doen wat het al deed: het authenticeren van menselijke gebruikers. Bij een aanroep presenteert de agent zijn eigen identiteit naast die van de gebruiker, zodat beide tegelijkertijd zichtbaar zijn:

De agent haalt zijn eigen token op uit het register (de actie Get Token op de agent), op dezelfde manier als een virtueel account dat doet.

Voor wie een agent mag handelen

Delegatie is niet onbegrensd. De scope wordt bepaald door de medewerkers (collaborators) van de agent, ingesteld bij de stap Access Control van de registratie. Dezelfde lijst die bepaalt wie de agent mag aanroepen, bepaalt ook voor wie de agent mag handelen.

Een Agent Manager kan de agent bewerken. Agent Access kan de agent aanroepen en er kan namens diegene gehandeld worden. Een Owner team, afzonderlijk ingesteld, blijft verantwoordelijk voor de agent van aanmaak tot uitfasering. Die toewijzingen vormen de gedefinieerde autoriteit van de agent: voor welke mensen deze mag handelen en welke MCP-servers en modellen deze kan bereiken.

Waarom Agent-registratie een Handhavingspunt is

De reden om agents op één plek te registreren is niet overzichtelijkheid. Het is dat de gateways elke aanroeper weigeren die geen geregistreerde identiteit presenteert, waardoor het Agent Registry tevens dient als handhavingspunt. Niets handelt anoniem en de inventaris is per definitie compleet.

Elke vermelding in het register bevat vier zaken: een verifieerbare identiteit, een verantwoordelijke eigenaar, een gedefinieerde autoriteit (de tools, modellen en mensen die het mag bereiken of voor wie het mag handelen) en een lifecycle die credential-rotatie en een deprovisioning-pad omvat. Waar de agent ook op gebouwd is — Bedrock, Vertex AI, LangGraph, een aangepaste HTTP-service of een copilot die is ingebouwd in een SaaS-product — hij valt onder governance door geregistreerd te worden, zonder dat er iets verplaatst of herschreven hoeft te worden.

Omdat identiteit vereist is om te handelen, is intrekking zeer gericht. Trek de identiteit van één agent in en hij stopt direct met het bereiken van elk model en elke MCP-server, terwijl elke andere agent blijft draaien. Dat is de noodknop die een gedeeld serviceaccount u nooit kan bieden.

Hoe Werken Agent-identiteiten en Virtuele Accounts Samen?

Agents handelen zelden alleen. De toepassingen en services eromheen hebben nog steeds machine-identiteiten nodig, en dat is waar virtuele accounts voor zijn. Een virtueel account is een niet-menselijke identiteit die een toepassing of service aanneemt om bronnen te bereiken, met een token dat u automatisch kunt roteren, waarvoor u rotatiewaarschuwingen kunt instellen en dat u kunt synchroniseren met uw secret manager. Het advies is om één virtueel account per toepassing aan te maken en dit te beperken tot de minimale machtigingen die het nodig heeft.

Samen levert dit een schone scheiding van principals op: mensen authenticeren via uw SSO, services en apps dragen virtuele accounts die zijn afgestemd op least privilege, en agents dragen hun eigen agent-identiteiten die voor die mensen en services kunnen handelen zonder ooit de toewijsbaarheid te verliezen. Toegangsbeslissingen worden in alle drie de gevallen afgedwongen bij de gateway, en elke aanroep wordt door AI agent guardrails gecontroleerd op wat deze daadwerkelijk bevat.

Opmerking: Agent Identiteit op TrueFoundry bevindt zich momenteel in bèta, en via de gateway uitgegeven token-exchange per hop wordt uitgerold. Het gedrag kan veranderen naarmate de functie volwassen wordt.

Beveilig, Beheer en Controleer AI Agents

Een agent is geen persoon en het is geen statische service, dus hij zou niet de credentials van een van beide moeten lenen. Geef elke agent zijn eigen AI agent identity en drie moeilijke problemen worden direct eenvoudiger: u kunt elke actie attribueren, elke agent onafhankelijk van de menselijke gebruiker scopen, en één enkele rogue agent intrekken zonder downtime voor de rest. Op TrueFoundry wordt die identiteit aangemaakt bij registratie en afgedwongen bij de gateway, waardoor non-human identity verandert van een spreadsheet met gedeelde sleutels in echte infrastructuur.

Bekijk hoe TrueFoundry agent identity uitgeeft en beheert over al uw models, tools en agents vanuit één control plane. Boek vandaag nog een demo.