MCP heeft een stabiele "Enterprise-Managed Authorization"-specificatie gepubliceerd; de andere concepten voor machine-to-machine-identiteit — waaronder een OAuth client-credentials-concept en twee open voorstellen — zijn nog niet afgerond. Voor iedereen die autonome agenten probeert te draaien met het Model Context Protocol, betekent dit dat het huidige protocol een menselijke gebruiker kan verifiëren, maar geen direct bruikbare manier biedt om te bewijzen dat een onbeheerd proces is wie het beweert te zijn.

Waarom de roadmap belangrijk is

De roadmap van het Model Context Protocol (MCP) noemt agent-identiteit en beveiliging als een van de hoogste prioriteiten. Vier items stonden gepland voor release: een mensgerichte browserflow, een OAuth client-credentials-flow voor services, een op DPoP gebaseerde tokenbinding en een mechanisme voor workload-identity federation. Alleen de eerste — Enterprise-Managed Authorization — heeft de status 'stabiel' bereikt.

Wat de stabiele specificatie feitelijk doet

Enterprise-Managed Authorization stelt IT-beheerders in staat om servertoegang te verlenen vanuit één centraal console, in plaats van dat elke werknemer elke verbinding moet goedkeuren. De flow maakt gebruik van een browser-redirect en een gebruikerslogin, zodat een persoon achter een laptop kan authenticeren en de server vervolgens de sessie van die gebruiker vertrouwt.

De beperking is overduidelijk: het proces vereist een mens achter een toetsenbord. Een agent die 's nachts draait, gegevens verwerkt of reageert op meldingen, heeft niemand om op een login-knop te klikken. Daarom kan elke implementatie die afhankelijk is van onbeheerde agenten geen gebruik maken van de enige specificatie die MCP momenteel garandeert.

De conceptopties en hun nadelen

Twee concept-extensies hebben als doel om agenten een eigen identiteit te geven:

  • SEP-1932 (DPoP) – koppelt tokens aan een publiek-private sleutelpaar, waardoor gestolen tokens nutteloos worden.
  • SEP-1933 (Workload Identity Federation) – stelt agenten in staat om identiteiten over te nemen die al zijn voorzien in cloudplatforms.

Beide bestaan als open pull requests; geen van beide is nog samengevoegd met de officiële specificatie. In de tussentijd is de enige andere gedocumenteerde optie een OAuth client-credentials-flow die vooraf geregistreerde secrets vereist. Het opslaan van deze secrets op een plek waar een agent ze kan lezen, creëert een klassiek aanvalsoppervlak: als het secret lekt, kan elke aanvaller zich voordoen als de agent.

Praktische stappen voor productie vandaag

Omdat het protocol nog geen native agent-identiteit biedt, kunnen teams agenten alsnog beveiligen door het identiteitsbeheer buiten MCP te plaatsen:

  1. Verleen verifieerbare identiteiten op de workload-laag. Systemen zoals SPIRE genereren kortstondige certificaten die gekoppeld zijn aan de trust root van de host, waardoor statische secrets worden geëlimineerd.
  2. Beëindig credentials bij een gateway. Een front-end service houdt de API-sleutel of het token vast en stuurt verzoeken door namens de agent, waardoor het secret buiten de runtime-omgeving blijft.
  3. Autoriseer op basis van de geverifieerde identiteit, niet de inhoud van het token. Scheid authenticatie (wie roept aan) van autorisatie (wat ze mogen doen), zodat beleid kan worden afgedwongen, zelfs als de authenticatiemethode verandert.

Waar u op moet letten

De twee open pull requests – DPoP-binding en workload-identity federation – zijn de enige wegen naar een echte machine-to-machine-identiteitsstandaard binnen MCP. Als de community deze samenvoegt, zullen agenten in staat zijn om het bezit van een privésleutel te bewijzen of cloud-uitgegeven identiteiten over te nemen zonder secrets bloot te leggen. Tot die tijd moet elke productie-implementatie vertrouwen op externe identiteitsframeworks of het risico van statische credentials accepteren.

De conclusie is duidelijk: MCP kan momenteel de persoon achter een verzoek authenticeren, maar het authenticeert nog niet de software die het verzoek doet. Teams die beveiligde autonome agenten nodig hebben, moeten niet wachten tot de specificatie er is; ze moeten vandaag de dag identiteit opbouwen op de workload-laag en de lopende DPoP- en federatievoorstellen in de gaten houden.