Claude-connectors nu centraal via Okta te beheren: één keer instellen, medewerkers erven toegang

Tot nu toe was het aansluiten van AI-connectors op Claude een rommelig klusje. Elke medewerker koppelde zelf zijn Asana, zijn Figma of zijn Atlassian aan de AI, klikte door losse toestemmingsschermen heen, en je IT-beheer had geen overzicht van wie waar bij kon. Sinds 18 juni kan dat anders. Anthropic en Okta hebben Enterprise-Managed Authorization uitgebracht: een uitbreiding op het Model Context Protocol (MCP) die het beheer van AI-connectors centraal bij de beheerder neerlegt in plaats van bij de individuele medewerker.

Wat er precies is aangekondigd

MCP is de open standaard waarmee een AI-assistent als Claude verbinding maakt met externe tools en databronnen. De nieuwe Enterprise-Managed Authorization (EMA) is nu een stabiel onderdeel van die standaard, waarmee organisaties de toegang tot MCP-servers centraal kunnen inrichten via hun eigen identity provider. Het principe is kort samen te vatten als “authorize once, inherit everywhere”: een beheerder zet een connector één keer aan voor de organisatie, en medewerkers krijgen hem automatisch, afgebakend tot de groepen en rollen die ze in het bedrijf toch al hebben.

Okta is de eerste identity provider die dit ondersteunt, via zijn Cross App Access-protocol (XAA). Anthropic noemt Okta zijn eerste partner; bij de beta die nu loopt zijn klanten als Ramp, Webflow en HubSpot betrokken. Belangrijk: EMA is een open extensie van MCP, geen Okta-exclusiviteit. Andere identity providers kunnen hetzelfde mechanisme implementeren.

Hoe het technisch werkt

De oude situatie was er een van losse toestemming per medewerker: iedereen koppelde elke server handmatig, beveiligingsteams misten centrale controle, en zakelijke en privé-accounts liepen door elkaar. EMA vervangt dat door een token-uitwisseling die meelift op je gewone inlog. Tijdens single sign-on geeft je identity provider een speciaal token af (een Identity Assertion JWT Authorization Grant, ID-JAG), dat de MCP-server inwisselt voor een toegangstoken. De per-server toestemmingsschermen verdwijnen daarmee.

De governance-winst zit in de keerzijde: als een medewerker uit dienst gaat of zijn rol verandert, vervalt zijn toegang tot de AI-connectors meteen samen met zijn andere bedrijfsapplicaties. Geen losse koppelingen meer die blijven hangen nadat iemand vertrokken is. Aaron Parecki, Director of Identity Standards bij Okta, vat het doel zo samen: “By embedding the Cross App Access protocol into MCP as the Enterprise-Managed Authorization extension, we turn identity into a centralized governance plane.”

Welke tools en clients meedoen

Aan de client-kant ondersteunen Claude, Claude Code en Cowork de extensie, net als Visual Studio Code. Aan de server-kant doen Asana, Atlassian, Canva, Figma, Granola, Linear en Supabase al mee, en Slack is bezig met implementeren. Dat is precies de set tools waar veel teams hun werk in doen, dus de praktische reikwijdte is meteen breed. Draai je een eigen databack-end, dan is het relevant dat ook een platform als Supabase als open-source backend met Postgres en authenticatie tot de eerste ondersteunende servers hoort.

Wat dit betekent voor jouw bedrijf

Dit raakt iedereen die Claude serieus inzet, van een team van vijf tot een divisie van een groot bedrijf. De kern is grip. Shadow-AI, waarbij medewerkers zelf van alles aan een AI-assistent hangen zonder dat iemand het overziet, is een van de grootste zorgen rond agentische AI. Met centrale inrichting bepaal je vooraf welke connectors zijn toegestaan en wie ze krijgt, en je sluit ze in één handeling weer af bij vertrek. Dat sluit aan bij de bredere beweging om AI-agenten een eigen, beheersbare identiteit te geven, zoals Estland dat AI-agenten een eigen digitale identiteit en aansprakelijkheidskader toekent.

Tegelijk is centrale toegang maar de helft van het verhaal. Weten wat een agent met die toegang dóét, blijft een aparte opgave: AI-agents auditklaar houden met logging, budgetten en kill-switches is het sluitstuk dat je naast deze provisioning-laag nodig hebt. Mijn advies: behandel AI-connectors vanaf nu als gewone bedrijfsapplicaties, met dezelfde toegangsregels, dezelfde offboarding en hetzelfde toezicht. Dat het via een open standaard kan en niet via een dichtgetimmerd platform van één leverancier, maakt die keuze een stuk makkelijker te verdedigen.