AI-agents toegang geven tot vijf soorten systemen, met één aanpak

De meeste teams hebben inmiddels wel een AI-agent draaien die bij interne en externe systemen moet kunnen. Een interne API, een paar externe apps, een API achter een vaste sleutel, een service account, een MCP-server: allemaal anders beveiligd. Zolang elke agent dat zelf regelt, stapelt hij overal aparte inloggegevens op en kun je achteraf niet meer zien welke agent wat deed.

Het antwoord is één aanpak: registreer de agent één keer als eigen identity en koppel elk systeem via de identity provider, zodat de agent de inloggegevens niet meer zelf vasthoudt en de toegang per keer van de provider krijgt. De vijf systemen lijken vijf aparte problemen, maar het is steeds hetzelfde probleem. Hieronder loop je het patroon per systeem langs.

Waarom die losse inloggegevens het echte probleem zijn

Verbindingen tussen agents en resources ontstaan zonder centrale controle. Soms staan de inloggegevens zelfs hardcoded in de code. Daarmee groeit een onbeheerd aanvalsoppervlak. Een statische token die overal verspreid staat, kun je bij een lek niet in één keer centraal intrekken of roteren zonder dat er van alles omvalt. En je kunt achteraf niet aantonen welke agent namens welke gebruiker iets deed op dat moment.

De oplossing is één principe dat je in vrijwel elke situatie kunt toepassen: de agent praat alleen nog met de eigen identity provider (IDP) en krijgt daar 'short-lived' en centraal beheerde tokens en secrets. De IDP is de centrale plek die de losse, statische inloggegevens vervangt door één beleid.

Het patroon dat je vijf keer herhaalt

Voor elk systeem zijn het dezelfde drie stappen. Registreer de agent één keer als eigen identity, met een menselijke eigenaar erbij. In Okta doe je dat in Universal Directory: één plek waar je agents registreert, over elk agent-framework, elke cloud en elke SaaS-omgeving heen, ook je eigen zelfgebouwde agents. Daarna stel je de agent per systeem in bij de IDP en koppel je hem met een passende scope. De agent krijgt dan per keer toegang van de IDP en hoeft niet zelf per gekoppelde resource de credentials te hebben en te onderhouden.

De stappen hieronder volgen telkens dat patroon. Wat verschilt is het type resource waar de agent toegang tot krijgt.

Hoe geef je een agent toegang tot een interne API?

Voor een interne API achter een eigen authorization server gebruik je cross-app access. De authorization server geeft een token uit met strak afgebakende scopes, zodat de agent alleen de API-rechten krijgt die voor één specifieke taak nodig zijn. Cross-app access vervangt de handmatige goedkeuring van de gebruiker door een token exchange. De app die de aanvraag doet haalt een identity assertion op bij de identity provider en wisselt die in voor een access token naar de resource-app. Er komt geen gebruiker aan te pas en er verschijnt geen consent-scherm: de organisatie legt vooraf centraal vast welke acties een AI-agent namens een gebruiker mag uitvoeren en heeft dat consent daarmee al namens de gebruiker gegeven. De agent haalt via de token exchange het juiste access token voor de resource op.

Hoe geef je een agent toegang tot een app zonder cross-app access?

Niet elke app ondersteunt cross-app access. Voor die apps loopt de toegang via een beheerde consent-flow, met Secure Token Storage eronder. De gebruiker geeft één keer toestemming, waarna de eigen IDP de tokens vasthoudt en aan agents uitgeeft wanneer die ze nodig hebben. Op deze manier is er maar een enkele consent van de gebruiker nodig (en niet opnieuw voor elke nieuwe AI-agent) en sla je tokens veilig op. En je ziet precies welke resources een agent mag gebruiken.

Hoe geef je een agent toegang tot een API met een statische sleutel?

Soms is er geen OAuth-token, maar een statische sleutel. Voor dat type bewaar je het secret in Okta Privileged Access. Het secret blijft in de kluis en wordt op aanvraag uitgegeven in plaats van in de code te worden gezet. Het secret-resourcetype geeft dus een sleutel uit de kluis terug, geen OAuth access token. Okta Privileged Access bewaart en roteert die inloggegevens centraal en haalt staande toegang weg. Dat geldt voor service-accounts net zo goed als voor gedeelde en break-glass-accounts.

Hoe geef je een agent toegang via een service account?

Een service account registreer je, net als statische tokens, in een systeem met governance eronder, zoals Okta Privileged Access, niet als een account dat je zomaar deelt of onbeheerd laat. Zo houd je grip op hoe agents privileged access gebruiken. Via dezelfde OAuth-flow krijgen agents dan toegang tot de service account credentials.

Hoe geef je een agent toegang tot een MCP-server?

Een MCP-server breng je net zo onder centraal beheer als elk ander systeem. MCP is de standaard om AI-modellen aan externe tools en databronnen te koppelen, en ondersteunt ook steeds vaker de OAuth-standaard voor authenticatie. De voorkeur gaat dan uit naar cross-app access, maar via Secure Token Storage kunnen tokens van elke autorisatieserver worden opgeslagen. Daarmee beveilig en monitor je de toegang van een agent tot de tools achter MCP net zo consistent als bij elk ander systeem.

Cross-app access zit inmiddels als officiële extensie in het Model Context Protocol, onder de naam Enterprise-Managed Authorization (EMA). Okta is de eerste ondersteunde identity provider, en Claude van Anthropic ondersteunt het al voor connectors als Atlassian, Figma en Linear.

Wat na vijf keer voor elk systeem geldt

Je hebt hetzelfde patroon vijf keer toegepast, dus voor alle vijf gelden dezelfde eigenschappen. Geen losse inloggegevens meer, maar toegang die per keer van de identity provider komt en staande toegang vervangt: alleen uitgegeven voor wat de agent nodig heeft en alleen zolang hij het nodig heeft. Bij OAuth is dat een short-lived token, bij een vaste sleutel een secret dat in de kluis blijft. Dat is precies wat NIST onder least privilege verstaat

De controle die je daarbovenop krijgt, geldt ook voor elk systeem. Je haalt agents door dezelfde certificeringsworkflows als je andere systemen, zodat eigenaren en managers samen met de securityteams toegang kunnen reviewen en intrekken, met een volledig auditspoor. Gaat een agent op hol, dan kun je hem met één handeling deactiveren: je kill switch, met één audit trail over alle systemen. Elke tool-aanroep en toegangspoging wordt vastgelegd, net als elke autorisatiebeslissing. Die telemetrie stuur je door naar je SIEM.

Je herkent het patroon één keer en hergebruikt het, in plaats van vijf aparte silo's met inloggegevens op te tuigen. Elk onderdeel is terug te voeren op open standaarden, zodat je geen lock-in op identity-niveau oploopt.

Werk je aan agent-toegang in je eigen omgeving? We kijken graag een keer met je mee.