MCP-gateways zijn niet voldoende: AI-agenten hebben identiteit, autorisatie en bewijs nodig

MCP-gateways zijn overal (en dat is goed)

Het Model Context Protocol (MCP) is in korte tijd de standaardmanier geworden waarop agents de buitenwereld bereiken: het gangbare protocol voor het verbinden van een agent met databases, SaaS-platforms, code runners, betalingssystemen en interne diensten. Als uw agents iets nuttigs doen, doen ze dat vrijwel zeker via MCP.

Het is dan ook niet verwonderlijk dat MCP-gateways zich in hoog tempo verspreiden. Elke infrastructuurleverancier, elk service mesh-bedrijf en een groeiend aantal open-sourceprojecten en start-ups leveren MCP-gatewayoplossingen. En ze bieden echte meerwaarde: gecentraliseerde routing, service discovery, inloggegevensbeheer en basis toegangscontrole voor MCP-serververbindingen.

Dit zijn slechts de basisvereisten. Ze zijn niet het einddoel voor beveiliging.

Als uw onderneming AI-agenten van prototypes naar productie verplaatst, waar ze API's aanroepen, code uitvoeren, gevoelige gegevens opvragen en namens uw bedrijf communiceren met andere agenten, zijn routing en toegangscontrole noodzakelijk, maar lang niet voldoende. De moeilijke beveiligingsproblemen zijn identiteit, autorisatie en bewijs. En MCP-gateways lossen geen van deze problemen op.

De drie hiaten die MCP-gateways openlaten

Implementaties van AI-agenten in ondernemingen moeten drie vragen beantwoorden voordat ze in productie kunnen gaan. MCP-gateways laten alle drie onbeantwoord.

Lacune 1: Identiteit. “Wie is deze agent?”

MCP-gateways authenticeren op verbindingsniveau. Een verzoek komt binnen met een geldige API-sleutel of OAuth-token, de gateway controleert dit aan de hand van een lijst en het verzoek wordt doorgelaten. Dit vertelt u dat de inloggegevens geldig zijn. Het vertelt u niet wie er belt.

In de praktijk werken de meeste AI-agenten met hardgecodeerde API-sleutels of gedeelde serviceaccounttokens. Wanneer Agent A en Agent B beide dezelfde service-inloggegevens gebruiken om een MCP-server te bereiken, ziet de gateway twee identieke bellers. Er is geen mechanisme waarmee de agent zijn identiteit cryptografisch kan bewijzen, geen door een certificaat ondersteunde bewering die een downstream-service onafhankelijk kan verifiëren.

Dit is een probleem dat de wereld van microservices jaren geleden heeft opgelost met SPIFFE en mTLS. Elke service krijgt een verifieerbare, cryptografische identiteit. Wanneer Service A Service B aanroept, weet de ontvangende service precies wie er belt en kan dit bewijzen. AI-agenten die tegenwoordig met frameworks worden geschreven, beschikken nog niet over dit mechanisme. Ze opereren zonder verifieerbare identiteit, en MCP-gateways doen niets om daar verandering in te brengen.

Het verschil in de praktijk is groot. Tegenwoordig komen de meeste agent-aanroepen als volgt aan op een tool-server:

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...

Een token. Mogelijk gedeeld door meerdere agents. Mogelijk van lange duur. Zonder informatie over welke workload het heeft geproduceerd, in welke context het actief was, of het is gewijzigd sinds het voor het laatst is uitgegeven. De toolserver accepteert het of wijst het af. Dat is het hele identiteitsverhaal.

Met SPIFFE-gebaseerde workload-identiteit komt dezelfde oproep binnen met een door een certificaat ondersteunde SVID, een cryptografisch ondertekende bewering die er als volgt uitziet:

spiffe://diagrid.io/ns/payments/fraud-detection-agent

Die URI is geen geheim. Dat hoeft ook niet. Het is een verifieerbare claim die is uitgegeven door het platform, gekoppeld aan de specifieke workload die draait in een specifieke naamruimte in een specifiek vertrouwensdomein, automatisch vernieuwd en aantoonbaar door elke service die hetzelfde vertrouwensdomein vertrouwt. De ontvangende toolserver controleert niet alleen of “deze inloggegevens op mijn toegangslijst staan”. Hij verifieert: welke workload is dit, waar draait deze en is dit de workload die deze oproep zou moeten doen?

Het eerste model beveiligt de inloggegevens. Het tweede model beveiligt de identiteit. Voor AI-agenten die autonoom opereren tussen diensten, databases en betalingssystemen, is dat onderscheid het verschil tussen toegangscontrole en zero trust.

Vanuit het perspectief van standaardisatie wordt het gebruik van SPIFFE voor workload-identiteit actief besproken in de IETF WIMSE-werkgroep en de AAIF Identity & Trust-werkgroep.

Voor een diepere duik in identiteit, lees Agent Identity: The Foundational Layer that AI Is Still Missing

Kloof 2: Autorisatie die verder gaat dan routing. “Wat mag deze agent doen?”

Denk aan een agent met toegang tot een MCP-server met een klantendatabase. De gateway staat de verbinding toe, de agent heeft geldige inloggegevens en de routeringsregel staat het toe. De agent zit midden in een workflow wanneer de LLM, op basis van een dubbelzinnige instructie, een oproep construeert die records verwijdert die aan een breed filter voldoen. Niets in de gateway houdt dit tegen. De routeringsregel zei dat de agent de server kon bereiken. Er werd niets gezegd over wat de agent mocht doen zodra hij daar was.

Dit is de autorisatiekloof die MCP-gateways openlaten. Ze controleren de toegang; welke bellers welke servers kunnen bereiken. Ze controleren niet welk gedrag is toegestaan; welke acties een specifieke agentidentiteit mag uitvoeren, in welke workflowcontexten en onder welke voorwaarden. Voor deterministische software maakt dat onderscheid nauwelijks uit; je kunt het aanroeppatroon vooraf analyseren. Voor AI-agenten, waarvan het gedrag emergent en niet-deterministisch is door het ontwerp, is het het verschil tussen een beveiligingsmodel en de illusie daarvan.

Wat productie vereist, is 'deny-by-default'-autorisatie op workflowniveau: declaratieve beleidsregels die precies specificeren welke agentidentiteiten welke workflows en tools kunnen aanroepen, afgedwongen op de platformlaag, ongeacht wat de LLM besluit te doen. Deze beleidsregels moeten in de infrastructuurconfiguratie staan, eigendom zijn van platform- en beveiligingsteams, onder versiebeheer staan en controleerbaar zijn. Niet in applicatiecode waar ze kunnen worden overgeslagen, overschreven of simpelweg vergeten.

Kloof 3: Bewijs. “Wat heeft deze agent gedaan, en kunnen we dat bewijzen?”

MCP-gateways produceren logs. Logs zijn nuttig. Logs zijn geen bewijs.

De logboekinfrastructuur van ondernemingen is aanzienlijk verbeterd. Moderne SIEM-platforms kunnen logboekpijplijnen manipulatiebestendig maken en met de juiste tools zijn onveranderlijke audittrails haalbaar. Maar zelfs een perfect bewaard logboek beantwoordt de verkeerde vraag. Wanneer een compliance-team vraagt: “Kunt u aantonen dat een mens deze tool-aanroep heeft goedgekeurd voordat de agent deze uitvoerde?”, is een logboekvermelding met de tekst tool: transfer_funds, status: approved, user: alice geen antwoord. Ze bieden geen cryptografische garantie dat de geregistreerde gebeurtenissen daadwerkelijk in de geregistreerde volgorde hebben plaatsgevonden.

In systemen met meerdere agents wordt dit probleem nog groter. Wanneer Agent C een destructieve tool-aanroep uitvoert, was deze dan geautoriseerd door Agent B, die op zijn beurt was geautoriseerd door Agent A, die weer was geactiveerd door een mens? Zonder een ondertekende bewakingsketen die zich over elke agentgrens uitstrekt, is er geen manier om de beslissingsketen te reconstrueren of te verifiëren.

Een ondertekende ketenvermelding is geen logboekrecord. Het is een gestructureerd, cryptografisch verifieerbaar object dat met de workflow meereist. Een vereenvoudigde vermelding ziet er als volgt uit:

{
  "step": "fraud_check_passed",
  "agent": "spiffe://diagrid.io/ns/payments/sa/fraud-detection-agent",
  "timestamp": "2025-04-18T14:23:11Z",
  "result": "approved",
  "handtekening": "eyJhbGciOiJFUzI1NiJ9..."
}

Elke invoer wordt ondertekend door de identiteit die deze heeft geproduceerd. Wanneer de keten een downstream-toolserver bereikt, bevat deze de volledige geschiedenis: wie de workflow heeft geïnitieerd, welke validatiestappen zijn uitgevoerd, of er een menselijke goedkeuring is gegeven en welke agent elke invoer heeft geproduceerd. De toolserver verifieert elke handtekening voordat deze actie onderneemt. Een invoer die niet kan worden geverifieerd wordt geweigerd voordat deze wordt uitgevoerd.

De EU-AI-wet, de opkomende SEC-richtlijnen en de evoluerende SOC2-vereisten komen allemaal uit op een duidelijke verwachting: ondernemingen moeten aantoonbare controle over en verantwoordelijkheid voor hun AI-systemen hebben.

Wat ondernemingen nodig hebben, is een manipulatiebestendig, cryptografisch ondertekend verslag van elke stap in elke agent-workflow. MCP-gateways kennen dit concept niet.

Hoe een AI-ready infrastructuur eruitziet

Om de drie hiaten te dichten zijn drie mogelijkheden nodig die werken op het AI-platformniveau, onder de agent- of applicatiecode en boven het netwerk/de rekenkracht.

Cryptografische agentidentiteit

Elke agent heeft een op SPIFFE gebaseerde cryptografische identiteit nodig, een certificaat dat automatisch door het platform wordt uitgegeven en vernieuwd wordt. Wanneer een agent een tool of een andere agent aanroept, verifieert de ontvangende dienst de identiteit via standaard mTLS. Dit is geen token in een header. Het is een door een certificaat ondersteunde bewering die is geworteld in een vertrouwensketen die elke deelnemer onafhankelijk kan verifiëren. Dezelfde beproefde aanpak die de communicatie tussen microservices beveiligt, toegepast op de unieke uitdagingen van niet-deterministische, autonome agents.

Zero-Trust-workflowautorisatie

Identiteit zonder autorisatie is zinloos. Platform- en beveiligingsteams hebben declaratieve, GitOps-vriendelijke beleidsregels nodig die bepalen welke agentidentiteiten welke workflows en tools kunnen aanroepen. De standaardaanpak moet 'alles weigeren' zijn: alles wat niet expliciet is toegestaan, wordt geblokkeerd. Deze beleidsregels moeten op platformniveau kunnen worden afgedwongen.

Dit is het verschil tussen “deze agent kan deze server bereiken” (wat gateways doen) en “deze specifieke agentidentiteit kan deze specifieke workflow op dit specifieke doel aanroepen, en niets anders” (wat productie vereist).

Policy-as-Code boven ondertekende geschiedenis

Grove regels voor identiteit-naar-workflow zijn noodzakelijk, maar niet voldoende. De echt interessante autorisatievragen zijn contextueel: ging aan deze toolaanroep een fraudedetectiestap vooraf? Heeft een mens deze binnen de laatste 30 seconden goedgekeurd? Is de agent die deze aanroep doet dezelfde als degene die het oorspronkelijke gebruikersverzoek ontving, of is de keten gekaapt?

Deze vragen kunnen niet worden beantwoord op basis van het verzoek alleen. Ze vereisen redenering over de geschiedenis van de workflow die tot de aanroep heeft geleid. Met een cryptografisch ondertekende uitvoeringsgeschiedenis die over elke stap wordt meegestuurd, kan een beleidsengine in de stijl van Open Policy Agent (OPA) Rego (of een andere beleidstaal) toetsen aan de gehele keten op het moment van de beslissing:

allow_tool_call {
    input.history[_].step == "human_approval"
    input.history[_].step == "fraud_check_passed"
    input.history[_].agent == input.calling_agent
}

Het beleid wordt uitgevoerd bij de ontvanger, niet bij de beller. Agenten kunnen geen geschiedenis vervalsen omdat elke vermelding is ondertekend door de identiteit die deze heeft aangemaakt. Dit maakt de workflowgeschiedenis zelf tot een verifieerbare input voor autorisatie, op dezelfde manier waarop OPA al JWT-claims en verzoekcontext voor HTTP-API's evalueert, maar nu uitgebreid van begin tot eind over uitvoeringsketens met meerdere agenten en meerdere tools.

Cryptografische bewakingsketen

Wanneer agents over servicegrenzen heen samenwerken, moet elke stap worden ondertekend. Elke service ondertekent de opgebouwde uitvoeringsgeschiedenis met zijn eigen identiteitscertificaat, waardoor een manipulatiebestendige keten ontstaat. Een downstream-tool controleert niet alleen “heeft deze beller toestemming?”. Het verifieert de volledige geschiedenis: wie de workflow heeft geïnitieerd, welke goedkeuringen hebben plaatsgevonden, welke validatiestappen zijn doorlopen en of elke identiteit in de keten geautoriseerd is.

Dit is geen logboek dat achteraf wordt gecontroleerd. Het is een cryptografisch bewijs dat vóór elke toolaanroep wordt geverifieerd. Het maakt handhavingspatronen mogelijk die met routing alleen onmogelijk zijn: een MCP-tool voor betalingen die weigert een transactie uit te voeren tenzij de ondertekende geschiedenis aantoont dat een fraudedetectieworkflow is doorlopen en een mens de transactie heeft goedgekeurd.

Hoe dit in de praktijk werkt

Dit zijn geen theoretische vereisten. Diagrid Catalyst, het beheerde platform voor het draaien van op Dapr gebaseerde applicaties en AI-agenten in productie, biedt dit alles vandaag de dag al.

MCP als infrastructuur. MCP-serververbindingen worden gedeclareerd als Kubernetes CRD's met verbindingsdetails, inloggegevens en toegangsbereiken. Geen hardgecodeerde verbindingslogica in de applicatiecode. Inloggegevens worden tijdens runtime opgehaald uit secret-opslag en worden nooit blootgesteld aan agentcode.

Duurzame MCP-toolaanroepen. Elke MCP-toolaanroep draait als een workflow binnen de Dapr-sidecar. Als een proces tijdens de aanroep crasht, wordt de uitvoering hervat vanaf het laatste checkpoint. Langlopende toolaanroepen (databasemigraties, externe API-sequenties, code-uitvoering) overleven automatisch proces- en node-uitval.

Middleware-hooks. Voor en na elke toolaanroep maken configureerbare workflow-hooks autorisatie per tool, auditlogging, rate limiting, invoervalidatie en kostenbeheersing mogelijk, zonder de agentcode te wijzigen. Dit zijn zelfstandige workflows die kunnen worden samengesteld en onafhankelijk kunnen worden geïmplementeerd. Hier kunt u OPA of een andere beleidsengine aansluiten om de ondertekende geschiedenis te evalueren voordat een tool daadwerkelijk wordt uitgevoerd.

Declaratief workflowtoegangsbeleid. Een Kubernetes CRD die bepaalt welke app-identiteiten specifieke workflows en activiteiten op een doelapplicatie kunnen starten. Maakt gebruik van SPIFFE/mTLS-gebaseerde identiteit voor verificatie van de aanroeper. Ondersteunt glob-patronen, regels per aanroeper en namespacebrede 'deny-all'-beleidsregels. Wanneer er een beleid bestaat, wordt elke actie die niet expliciet is toegestaan geweigerd.

Verspreiding van ondertekende geschiedenis. Workflows kunnen ervoor kiezen om hun volledige uitvoeringsgeschiedenis door te geven aan onderliggende workflows en activiteiten. Elke identiteit die een workflow raakt, ondertekent de verzamelde geschiedenis met zijn identiteitscertificaat. Downstream-services verifiëren de hele keten voordat ze handelen, en beleidsengines kunnen hierover redeneren.

Human-in-the-loop met bewijs. Agenten kunnen pauzeren voor menselijke goedkeuring via duurzame workflowgebeurtenissen. Wanneer een downstream-tool de ondertekende geschiedenis ontvangt, kan deze cryptografisch verifiëren dat de goedkeuring daadwerkelijk heeft plaatsgevonden.

Stel dat een agent een verzoek tot terugbetaling van een klant verwerkt dat boven een bepaalde drempel ligt. In plaats van de aanvraag direct uit te voeren of te weigeren, pauzeert de workflow en genereert een goedkeuringsgebeurtenis:

Terugbetalingsagent bereikt drempel van $10.000
        │
        ▼
Workflow wordt onderbroken — genereert goedkeuringsverzoek
  — stuurt een Slack-bericht naar het kanaal voor betalingsgoedkeuringen
  — records die nog moeten worden goedgekeurd in de ondertekende geschiedenis
  — stelt een time-out van 30 minuten in
        │
   Menselijke beoordelingen in Slack
        │
        ├── Goedkeurt → workflow wordt hervat
        │             goedkeuringsstap ondertekend en toegevoegd aan de geschiedenis
        │
        └── Weigert / time-out → workflow wordt beëindigd
                              afwijzing vastgelegd in ondertekende geschiedenis
        │
        ▼
Terugbetalingstool ontvangt oproep
  — controleert of de ondertekende geschiedenis de stap human_approval bevat
  — bevestigt dat de tijdstempel van de goedkeuring binnen het beleidsvenster valt
  — bevestigt dat de goedkeurende identiteit een geautoriseerde goedkeurder is
  — voert alleen uit als alle controles zijn geslaagd

De goedkeuring is geen logboekvermelding die achteraf wordt toegevoegd. Het is een ondertekende stap in de uitvoeringsgeschiedenis die de toolserver verifieert voordat deze actie onderneemt.

De vraag die bedrijven zich zouden moeten stellen

De vraag is niet “hebben we een MCP-gateway nodig?” Waarschijnlijk wel, en deze zouden zeker deel moeten uitmaken van uw beheer van inkomende verbindingen. MCP is het protocol, en u hebt infrastructuur nodig om verbindingen met MCP-servers op schaal te beheren, routing uit te voeren en enige snelheidsbeperking toe te passen.

De vraag is: biedt uw MCP-infrastructuur u identiteit, autorisatie en bewijs?

Kan uw AI-platform u precies vertellen welke agent een oproep heeft gedaan, niet welke inloggegevens zijn gebruikt, maar welke cryptografisch verifieerbare identiteit? Kan het zero-trust, deny-by-default-beleid afdwingen met betrekking tot wat elke agent mag doen, beheerd door uw platformteam en afgedwongen ongeacht wat de LLM besluit? Kan het een manipulatiebestendige, ondertekende bewakingsketen produceren die elke stap in elke agent-workflow aantoont, in realtime verifieerbaar door downstream-services voordat ze handelen?

Als het antwoord nee is, beschikt u niet over een beveiligingslaag voor AI-agenten. Dan beschikt u alleen over een router.

En routers zijn niet voldoende.

Duik dieper in Catalyst.

Praat met een expert