Als elke tool een server is: waar MCP-gateways werkelijk beleid afdwingen

Veldnotities agentplatform, vier van acht. Notitie drie eindigde met toolmediatie als een van de vijf beslissingen die frameworks aan jou overlaten. Deze notitie gaat over het onderdeel waar de meeste teams naar grijpen om dat gat te vullen.

De vraag

Het Model Context Protocol deed iets nuttigs en iets gevaarlijks tegelijk. Nuttig: elke tool die een agent kan gebruiken, spreekt nu één protocol, dus je kunt één ding vóór alle tools zetten. Gevaarlijk: elke tool is nu een server, bereikbaar over een netwerk, vaak gehost door iemand anders, en het model mag hem ontdekken en aanroepen.

De vraag voor een governed platform is dus: als we een gateway tussen de agent en elke tool zetten, welke van de vijf governancebeslissingen neemt die gateway dan werkelijk? Identiteit en delegatie, beleidshandhaving, goedkeuringsbinding, toolmediatie, bewijs. Het eerlijke antwoord is anderhalf.

Wat ik las

Voor het platform heb ik acht MCP-gateways en tool-routers beoordeeld, van de Kubernetes-native referentiegateway van een cloudleverancier, via een op Envoy gebaseerd control plane dat inmiddels een foundation-project is, tot gehoste integratieplatforms die duizenden SaaS-acties ontsluiten, en kleine open-source routers. Van de open-source exemplaren heb ik de code statisch gelezen, omdat documentatie en implementatie vaker van elkaar afweken dan ik had verwacht. Niets hiervan is gebouwd of gedraaid; de bevindingen komen uit lezen.

Vier ideeën overleefden het lezen en gingen mijn eigen ontwerp in.

Vier ideeën die het waard zijn

Autorisatie op toolniveau als declaratief beleid. De op Envoy gebaseerde gateway evalueert een expressie over de tokenclaims van de aanroeper, de request headers, de backend, de toolnaam en de toolargumenten, in de gateway, voordat de aanroep enige server bereikt. Daarmee verhuist “mag deze principal deze tool met deze argumenten aanroepen” uit elke afzonderlijke server naar één beleidsbestand dat je kunt reviewen. Het is het belangrijkste patroon uit de hele set, omdat het de enige plek in de keten is waar de beslissing wordt genomen door iets dat noch het model, noch de tool is.

Stuur alleen door wat elke backend declareert. Hetzelfde project bouwt per backend een vers upstream-verzoek en stuurt alleen de headers door die die backend expliciet opsomt. De identiteit van de gebruiker waaiert alleen uit naar servers binnen de vertrouwensgrens. De meeste gateways doen standaard het tegenovergestelde: ze geven het inkomende token door, zodat elke toolserver een plek wordt waar je credentials kunnen lekken.

Progressieve ontdekking in plaats van een platte toollijst. Twee van de gehoste platforms bieden een handvol meta-tools: discover, describe, execute. Het model laadt alleen de schema’s die het nodig heeft. Dit is evenzeer een governancepatroon als een truc voor het contextvenster: een model dat een tool niet kan zien, kan niet worden verleid hem aan te roepen.

Instanties per eindgebruiker met gedelegeerde rechten. De betere integratieplatforms modelleren elke eindgebruiker als principal met eigen opgeslagen toestemmingen, zodat één deployment handelt met ieders eigen rechten in plaats van met één gedeeld serviceaccount. Voor een gemeente is dit niet optioneel. Een agent die aan de zaak van een inwoner werkt, moet handelen als de casemedewerker, niet als “het platform”.

Wat een gateway niet kan

Hier is de helft. Een gateway zit op het pad van een tool call. Hij kan de aanroep autoriseren, de toollijst filteren, credentials strippen en injecteren, de uitwisseling loggen en een egress-allow-list afdwingen voor waar de tool naartoe mag. Dat is toolmediatie, goed gedaan, en een stukje identiteit.

Hij kan geen goedkeuring binden aan een planrevisie, want hij ziet het plan nooit. Hij kan geen beleid afdwingen op modelaanroepen, tenzij hij ook vóór het model staat, wat één van de acht doet en de rest niet. Hij weet niet wat een run is, dus zijn log is een lijst van aanroepen, geen bewijs van een beslissing. En hij kan de toolserver zelf niet betrouwbaar maken: een gateway vóór een server die shellcommando’s in zijn eigen proces draait, heeft de deur bestuurd en de kamer open gelaten.

Wat me brengt bij wat ik vond toen ik de code las.

Een gateway voor een onveilige toolserver is een uitstekend slot op een deur in een muur die er niet is.

Wat de code zei

Ik noem de projecten voor dit deel niet bij naam, omdat sommige problemen nog niet waren opgelost toen ik ze las en dat een zaak is voor hun maintainers, niet voor een blog.

In twee van de open-source gateways gaf de ingebouwde authenticatie geldige tokens aan iedereen die erom vroeg. In één accepteerde het endpoint voor het herladen van de configuratie niet-geauthenticeerde verzoeken. In een andere konden templates die verzoeken vormgeven de omgeving van de gateway lezen, waar de secrets leven. In één accepteerde de helper die een authenticatiefout afhandelde, credentials als argument dat door het model werd aangeleverd. In één faalden autorisatiefouten open: als het beleid niet geëvalueerd kon worden, ging de aanroep door. Verschillende hiervan waren opgelost op de main branch en in geen enkele release, zodat een team dat de laatste tag installeert, de fout meelevert.

Niets hiervan was exotisch. Het waren de klassieke fouten van snel geschreven infrastructuurcode, in onderdelen waarvan het hele doel is om het controlepunt te zijn. De les is niet “open source is onveilig”. De les is dat een gateway een beveiligingscomponent is en als zodanig beoordeeld moet worden, met dezelfde strengheid als een reverse proxy of een identity provider, en niet moet worden ingevoerd omdat het juiste protocol in de naam staat en het aantal sterren gezond is.

De beslissing die ik nam

De gateway is een ingekocht onderdeel, geen deel van de ruggengraat. Hij implementeert toolmediatie onder contracten die de ruggengraat bezit: de allow-list per use case, het egress-beleid, de identiteit die hij mag doorsturen en het bewijs dat hij moet afgeven. Als de gateway faalt, faalt de run fail-closed. Als de gateway wordt vervangen, verandert er niets in het beleids- of bewijsmodel.

Ik heb ook besloten dat de modelgateway en de toolgateway verschillende problemen zijn met verschillende faalwijzen, en heb de verleiding van één doos voor beide weerstaan. De modelroute is een gekwalificeerd, vastgepind contract met juridische en doorgiftebesluiten eraan, zoals notitie twee beschreef. Een toolroute is een autorisatiebeslissing op een verzoek. Ze delen telemetrie. Ze delen geen policy engine.

Wat ik nog niet kan bewijzen

Dezelfde beoordeling: prototype, en in dit geval dunner. Mijn lezing was statisch. Ik heb de acht gateways niet onder belasting gedraaid, niet gefuzzd en niet herlezen na hun volgende releases. Sommige van de bovenstaande fouten zijn waarschijnlijk opgelost tegen de tijd dat je dit leest; er zijn waarschijnlijk nieuwe bijgekomen. De patronen zijn duurzaam, de details niet.

Wat je hiermee doet

Staat er een MCP-gateway in je diagram, vraag dan om drie dingen voordat hij in de buurt van een zaakdossier komt. Het beleidsbestand waarin de autorisatie per tool leeft, en wie wijzigingen daarin reviewt. De lijst met headers die elke backend ontvangt, en waarom. En de datum van de laatste beveiligingsreview van de gateway zelf, los van de tools erachter. Is het antwoord op de derde “het is open source, veel mensen kijken ernaar”, dan heb je je antwoord.

Volgende notitie: durable execution. Waarom “een run” de eenheid van governance moet zijn, en wat Temporal, DBOS en Restate met gemeenten te maken hebben.

Moss gaf Jen ooit het Internet in een klein zwart doosje met een lampje erop. Sommige gateways die ik las worden op dezelfde manier geleverd: het doosje is echt, het lampje brandt, en het etiket is het enige veilige onderdeel.

Verwijzingen

De knipogen en citaten in dit stuk, met hun herkomst:

• The IT Crowd, “The Speech” (2008): Moss and Roy hand Jen “the Internet”, a small black box with a blinking light.