De MCP-server als security boundary

Wat doet dit experiment?

Een MCP-server wordt makkelijk gezien als een onschuldige connector: een laagje tussen de AI-agent en een onderliggend systeem. Maar dat laagje geeft een niet-deterministische agent toegang tot mail, documenten, tickets, databases, Git en cloud resources. Een opdracht als “vat dit kwartaal samen” kan resulteren in een keten van acties — databases bevragen, een document ophalen, een ticket aanmaken — die niet vooraf is voorgeschreven, maar voortkomt uit de redenering van de agent. Dat maakt de MCP-server geen connector maar een security boundary.

Dit experiment onderzoekt wat het betekent om die boundary serieus te nemen. De centrale vraag: hoe richt je toegang in voor een handelende AI-agent, in een wereld waarin Identity & Access Management is ontworpen rond twee aannames die hier niet meer kloppen — dat een identiteit óf een mens is óf een vaste service, en dat wie inlogt ook degene is namens wie gehandeld wordt?

We werken toe naar een verkennend raamwerk dat we voorlopig Agent Access Management (AAM) noemen: agent-identiteiten, delegaties, policies, approvals, audit trails, MCP discovery en tool governance als samenhangend geheel.

Aanpak

We ontleden het probleem langs vier vragen die steeds scherper worden:

• Authentication — wie roept de MCP-server aan? De MCP-specificatie heeft zich in een jaar tijd ontwikkeld van statische API-keys naar OAuth 2.1, met de MCP-server als resource server en tokenuitgifte bij een externe identity provider (Okta, Auth0, Keycloak, Entra). We brengen in kaart wat dit in de praktijk betekent: PKCE, scoped en kortlevende tokens, en het expliciete verbod om tokens door te geven aan upstream API’s.
• Authorization — namens wie mag de agent handelen? Authenticatie zegt alleen dát er een geldige aanroeper is, niet wat die mag. De moeilijkheid bij MCP is dat de autorisatiecontext meerdere grenzen moet overleven: gebruiker → AI-host → MCP-client → MCP-server(s) → backend. Elke hop moet de context bewaren, credential-lekkage voorkomen en zelfstandig controleerbaar zijn.
• Constrained delegation — het grijze gebied. Onze werkterm voor de situatie waarin een agent deels namens de gebruiker handelt, maar níét dezelfde rechten zou moeten erven. Een mens mag alle 200 klantdossiers inzien; moet de agent die “even iets opzoekt” dat ook mogen? We verkennen mechanismen om delegatie te beperken tot een smallere, doel-gebonden subset van de rechten van de gebruiker — in plaats van rechten één-op-één over te nemen.
• Agent accounts — de agent als volwaardig teamlid? Wanneer geef je een agent een eigen identiteit met eigen rechten, los van een menselijke gebruiker, en wat zijn de gevolgen voor lifecycle, eigenaarschap en aansprakelijkheid?

Vanuit die vier vragen schetsen we de bouwstenen van AAM en confronteren we ze met bestaande standaarden. We kijken specifiek naar de rol van CIBA (Client-Initiated Backchannel Authentication) als patroon voor approvals: de agent initieert een actie, maar de daadwerkelijke goedkeuring loopt out-of-band naar het toestel van de mens die verantwoordelijk blijft — een “human in the loop” die niet in de promptflow zit. Ook recentere spec-ontwikkelingen (Enterprise-Managed Authorization, Client ID Metadata Documents) nemen we mee voor zover ze het delegatie- en governancevraagstuk raken.

Het onderzoek blijft praktisch: niet “wat zegt de spec”, maar “wat zou een consultant bij een klant moeten regelen voordat een agent productiesystemen raakt”.

Bevindingen tot nu toe

Een eerste verkenning levert een aantal observaties op:

• De huidige MCP-autorisatiemodellen lossen authentication grotendeels op, maar laten delegation — het grijze gebied — grotendeels open en aan implementaties over. Dit is precies waar het risico bij klanten zit.
• Klassieke IAM gaat uit van een principal die bewust en deterministisch handelt. Een agent plant en koppelt tool-aanroepen aan elkaar op basis van redenering; daardoor is “de actie die de gebruiker autoriseerde” zelden gelijk aan “de acties die de agent uitvoert”.
• Audit trails zijn bij agents geen bijzaak maar de kern: zonder herleidbare koppeling tussen menselijke opdracht, agent-identiteit, gebruikte delegatie en uitgevoerde tool-aanroep is verantwoording achteraf zeer lastig.
• AAM is waarschijnlijk geen nieuw product maar een samenstel van bestaande bouwstenen (IdP, policies, approvals, logging) toegepast op een nieuw type principal — mits we de aannames van IAM expliciet herijken.

Volgende stappen

• Een referentie-architectuur uitwerken voor één concrete keten: gebruiker → agent → MCP-server → systeem, met expliciete delegatie en audit.
• Half delegation hands-on beproeven: een proof-of-concept waarin een agent een bewust beperkte subset van de rechten van een gebruiker krijgt.
• Een CIBA-gebaseerde approval-flow nabouwen in een geïsoleerde omgeving.
• Een praktische checklist opstellen voor consultants: wat moet geregeld zijn voordat een agent in een klantomgeving toegang krijgt tot productiesystemen.
• De AAM-bouwstenen toetsen tegen de laatste MCP-spec-revisies en tegen het bestaande VX-whitepaper over verantwoord AI-gebruik.