Proxy, Router, Gateway: Drie woorden voor drie verschillende dingen

Deze termen worden door elkaar gebruikt totdat er iets kapotgaat. Ze beschrijven verschillende architecturen met verschillende garanties, en de prijs van het verwarren ervan wordt betaald in beveiligingslekken, mislukte audits en herbouwen die u eigenlijk had moeten voorkomen.

Het terminologieprobleem is een architectuurprobleem

Nu Model Context Protocol de standaardverbinding wordt voor het koppelen van AI-agents aan databronnen en tools, is de infrastructuurterminologie verstrengeld geraakt. Leveranciers, blogposts en interne ontwerprevisies gebruiken “proxy”, “router” en “gateway” door elkaar. Het onderscheid is vervaagd wanneer alles op de laptop van een ontwikkelaar draait, en fataal wanneer u productie-agents gaat uitrollen — omdat de drie woorden structureel verschillende dingen aanduiden, en het verschil pas zichtbaar wordt wanneer een auditor een vraag stelt die een van hen niet kan beantwoorden.

Leenconcepten uit de netwerkwereld bieden het helderste mentale model. Een proxy werkt op L4 — hij stuurt bytes door en interpreteert deze niet. Een router werkt op L7-functionaliteitsverwerking — hij kent de tool, maar kent de principal niet die deze aanroept. Een gateway werkt op L7-beleid — hij kent de tool, de principal, het budget en het auditspoor. Elke laag is strikt capabeler, strikt duurder om uit te voeren en beantwoordt strikt meer vragen over elk verzoek.

Proxy: bytes, niets meer

Een proxy is het eenvoudigste onderdeel in het diagram. Zijn taak is protocolbemiddeling. MCP maakt veelvuldig gebruik van stdio voor lokale uitvoering; een proxy kan een op stdio gebaseerde MCP-server omhullen en deze beschikbaar maken via HTTP/SSE of WebSockets, zodat een externe client deze kan bereiken. Dat is de gehele taak.

Een proxy voert nul interpretatie uit van de payload. Hij ontleedt geen JSON-RPC, begrijpt geen tool-aanroepen en weet niet wat “tool” betekent. Hij stuurt bytes door. Dat maakt hem sub-milliseconde snel en vrijwel gratis in gebruik. Een enkele ontwikkelaar die Claude Desktop verbindt met een MCP-server in een Docker-container op dezelfde machine — dat is een proxy-toepassing. Geen governance, geen status, geen reden voor beide.

De fout is denken dat de proxy zal schalen. Dat zal hij niet. Zodra u meer dan één ontwikkelaar of meer dan één downstream MCP-server hebt, stopt de proxy met het dragen van de belasting en neemt de router het over. Een proxy is geen bouwsteen van een enterprise stack; het is een persoonlijke gemakstool die een gateway intern kan omhullen voor transportaanpassing. Dit behandelen als meer of minder dan dat — het te ingewikkeld bouwen of het onderschatten — levert een architectuur op die slecht veroudert.

Router: functionaliteitsverwerking

Aangezien omgevingen groeien, is het niet langer onderhoudbaar om server-URL's hard te coderen in clients. Een router lost de ontdekking op: in plaats van dat de client weet waar github-mcp-server zich bevindt, verbindt de client met de router en vraagt welke tools beschikbaar zijn. De router onderhoudt een register van downstream-servers en een functionaliteitskaart.

Wanneer het LLM search_repositories aanroept, inspecteert de router de JSON-RPC payload, identificeert de doel-tool en stuurt de aanroep door naar de juiste backend. Het is mechanisch gezien een aggregator met een routingtabel — snel, eenvoudig en een schone abstractie. De meeste interne teams grijpen er een zodra ze meer dan twee MCP-servers hebben, en ze hebben daar geen ongelijk in.

Wat de router niet doet, is de vraag stellen die er in productie het meest toe doet: is de identiteit die deze aanroep doet daadwerkelijk geautoriseerd om deze tool aan te roepen? Hij stuurt op basis van functionaliteit. Hij blokkeert niet op basis van beleid. Het model kan net zo gemakkelijk delete_branch op prod aanroepen als list_issues op een openbare repo. De router zal gehoorzaam beide doorsturen, en het auditlogboek dat hij wel of niet produceert wordt uitsluitend gevormd door de verbinding — niet door wie de verbinding beheerde.

Router is de juiste laag wanneer de agents intern zijn, het netwerk vertrouwd is en de ergste actie ongedaan kan worden gemaakt. De overgang die teams raakt is router → gateway, en dat gebeurt meestal op de dag dat iemand vraagt wie afgelopen dinsdag delete_branch op prod heeft aangeroepen. De router heeft geen antwoord te bieden, omdat hij het nooit heeft geweten.

Gateway: het volledige control plane

Een gateway omvat de proxy en de router en voegt daar een L7 control plane aan toe. Dit is de laag waar enterprise AI-operaties daadwerkelijk plaatsvinden — en de laag waar een beveiligingsbeoordeling zal beginnen, ongeacht of iemand het tijdens het ontwerp zo heeft genoemd.

Een gateway inspecteert elk pakket. Hij integreert met bedrijfsidentiteit (OAuth 2.0, SAML, OIDC) om vast te stellen namens wie de agent handelt. Hij dwingt RBAC op tool-niveau af. Hij voert de schema-sanitisatie uit die MCP-vergiftiging opvangt. Hij houdt tokengebruik bij voor budgettoewijzing. Hij schrijft onbetwistbare logboeken naar externe SIEM's. Het is structureel gezien de plek waar het AI-beleid van de organisatie is gecodeerd — en de enige plek waar de agent van een vertrokken contractor op het juiste moment stopt met werken.

Functionaliteitsmatrix

Dezelfde vergelijking in tabelvorm, voor de beoordelaars van ontwerpdocumenten die de tekst snel scannen. Lees de kolommen; elk van hen beantwoordt een vraag over een verzoek.

Tabel 1 — Functionaliteitsmatrix. De rechterkolom is waar uw auditor naar zal vragen; de middelste kolom is waar uw team als eerste naar zal grijpen; de linkerkolom is wat er op uw laptop draait.

Beslissingskader

Een korte beslissingsboom, geschreven in de volgorde waarin productieteams de vragen daadwerkelijk beantwoorden:

• Gebruik een proxy wanneer u een enkele ontwikkelaar bent die lokale tools verbindt over netwerknamespaces heen — WSL met een Windows-host, host met een Docker-container. De impact is beperkt tot uw eigen machine.
• Gebruik een router wanneer u met een klein team een handvol interne agents beheert die een gecentraliseerd ontdekkingspunt nodig hebben, u iedereen op het netwerk stilzwijgend vertrouwt en de ergste actie van een tool omkeerbaar is.
• Gebruik een gateway wanneer u agents uitrolt naar productie, Claude Code uitrolt voor meer dan tien ontwikkelaars, databanken van welke aard dan ook aanraakt, of werkt onder een compliance-kader dat auditsporen en least-privilege-toegang verplicht stelt.

De overgang waar de meeste teams hinder van ondervinden is router → gateway, en dat gebeurt altijd op hetzelfde moment: iemand stelt een auditvraag die aan identiteit gekoppelde logboeken vereist, en de router heeft geen antwoord omdat de router nooit heeft geweten wie er aanriep. De goedkope oplossing op dat punt is het toevoegen van een gateway. De kostbare oplossing is het herontwerpen van het agentplatform na een beveiligingsincident — wat een deel van de teams uiteindelijk zal doen, omdat de goedkope oplossing onzichtbaar is tot het incident plaatsvindt.

Hoe TrueFoundry de gateway-laag implementeert

TrueFoundry is gebouwd als een gefedereerde gateway. Het control plane (waar beleid wordt opgesteld, modellen worden geregistreerd en observatie plaatsvindt) is gescheiden van het gateway-plane (waar het verkeer stroomt). Het gateway-plane is volledig stateless — elke gateway-pod abonneert zich via NATS op het control plane voor configuratie-updates, en elke controle die het uitvoert vindt plaats in het geheugen op basis van die gesynchroniseerde status. Er is geen single point of failure tussen de agent en de backend. Als het control plane uitvalt, blijven gateways werken met hun laatst bekende configuratie; wanneer het control plane terugkeert, herstelt NATS de synchronisatie. Als laatste beveiliging publiceert het control plane elke 10 minuten de gehele configuratie opnieuw — uiteindelijke consistentie is gegarandeerd, zelfs als een tussentijdse update is gemist.

‍

Het data plane is gebouwd op Hono — een framework afgestemd op de Web Fetch API en geoptimaliseerd voor de edge — en voert alle controle voor snelheidsbeperking, authenticatie en routing uit in het procesgeheugen. Het control plane synchroniseert configuratie via NATS met sub-seconde frequentie; het verzoeks-pad maakt zelf nooit een externe aanroep, tenzij de cache of een op het netwerk gebaseerde beveiligingsbarrière wordt aangeroepen. De structurele eigenschap die ertoe doet is statelessness: een gateway-pod kan op elk moment worden gestopt zonder actieve beleidsbeslissingen te verliezen, omdat er geen actieve beleidsbeslissingen zijn — elke beslissing wordt genomen vanuit het lokale geheugen op basis van configuratie die asynchroon is binnengekomen.

De functionaliteit die de architectuur verbindt is virtuele MCP-servercompositie. De gateway voegt schema's van tientallen downstream MCP-servers samen tot één API-oppervlak, dynamisch afgestemd per aanroeper. Het IAM-token van een frontend-ontwikkelaar levert een andere samengevoegde tool-lijst op dan dat van een platform-engineer, en geen van beiden ziet tools die de ander niet mag gebruiken. Vanuit het perspectief van het model is er één MCP-server. Vanuit het perspectief van het platformteam is er één plek om beleid in te stellen. Vanuit het perspectief van de auditor heeft elke tool-aanroep een trace ID die de beslissing van het model koppelt aan de identiteit van de ontwikkelaar die deze heeft geautoriseerd.

Zelfde client, dezelfde backends, een sterk verschillende tussenlaag. De tussenlaag is het onderdeel dat goed veroudert.

Het diepere kernpunt

Architectuur is grotendeels de praktijk van het kiezen waar grenzen worden gelegd, en de kosten van het verkeerd maken van die keuze worden niet betaald tijdens het ontwerp, maar bij het volgende incident, de volgende audit, de volgende migratie. Het onderscheid tussen proxy/router/gateway is geen terminologieprobleem. Het is de vraag of uw platform een controlepunt heeft op de naad waar bedrijfsidentiteit de agent-lus ontmoet, of dat het een routingtabel heeft waar een controlepunt zou moeten zitten.

De meeste teams ontdekken dit onderscheid op de harde manier. Sommigen ontdekken het tijdens een post-mortem; sommigen tijdens een compliance-beoordeling; sommigen wanneer de agent van een vertrokken contractor een week langer blijft werken dan de bedoeling was. Het moment van ontdekking is in al deze gevallen hetzelfde. De kosten van de ontdekking variëren.

FAQ

Kan ik nu een router uitvoeren en later een gateway toevoegen?

Ja, en de meeste teams doen dit. Het migratiepad is overzichtelijk: de gateway spreekt hetzelfde MCP-wire protocol, dus bestaande clients blijven werken. Wat verandert is de URL waar ze naar wijzen en de auth-header die ze meesturen. Plan de migratie rond twee fasen — zet eerst de gateway op in audit-modus (loggen, geen handhaving) en controleer of de logboeken overeenkomen met de verwachtingen; schakel vervolgens handhaving in per server, beginnend met de MCP-servers met het laagste risico en eindigend met de productie-database.

Hoe gedraagt de gateway zich als het control plane uitvalt?

Gateways blijven verkeer afhandelen op basis van de configuratie die ze het laatst hebben opgehaald, voor onbepaalde tijd. Ze abonneren zich op NATS voor live-updates, en als back-up proberen ze de configuratie opnieuw via HTTP op te halen bij de backend-service van het control plane. Als zowel NATS als de backend uitvallen, blijven bestaande gateway-pods draaien op de laatst bekende configuratie; nieuwe pods die tijdens de storing proberen te starten, zullen de gereedheidscontrole niet doorstaan en geen verkeer ontvangen. Het wordt aanbevolen om meerdere gateway-replica's uit te voeren — de kans dat ze allemaal opnieuw opstarten tijdens een storing van het control plane is de kans waar u tegen moet ontwerpen, en die is klein.

Waarom specifiek Hono? Wat leverde Hono op ten opzichte van Express of Fastify?

Hono is gebouwd op de Web Fetch API en is ontworpen voor edge-runtimes (Cloudflare Workers, Deno, Bun, Node). Het is klein, snel en draait identiek op verschillende runtimes — wat belangrijk is omdat de gateway overdraagbaar moet zijn tussen SaaS, on-prem Kubernetes en van het internet afgeschermde omgevingen met een Squid-proxy. Express heeft een te groot oppervlak; Fastify is prima, maar gebonden aan Node-specificaties. De relevante eigenschap is een constante lage overhead bij hoge gelijktijdigheid, wat Hono betrouwbaar levert.

Is virtuele MCP-compositie een statische samenvoeging, of stemt het dit echt af per aanroeper?

Het stemt dit af per aanroeper. De gateway evalueert de IAM- en ABAC-attributen van de principal bij elke afhandeling van een tools/list tegen het beleidspakket, en geeft een gefilterde verzameling van tool-beschrijvingen uit. Twee ontwikkelaars die binnen enkele seconden na elkaar inloggen, kunnen verschillende tool-lijsten ontvangen van hetzelfde gateway-eindpunt. Het model weet nooit dat er meerdere backends zijn, en weet nooit dat er tools zijn die de huidige aanroeper niet kan bereiken. Dit is ook hoe u schone multi-tenant-implementaties krijgt — dezelfde gateway bedient verschillende tenants met verschillende omgevingen.

Hoe voorkomt de gateway dat de configuratie afwijkt tussen het control plane en de pods?

Drie mechanismen. Configuratie-payloads zijn idempotent — het control plane publiceert de gehele huidige status naar NATS bij elke wijziging, dus het tweemaal ontvangen van hetzelfde bericht heeft geen effect. NATS biedt minstens-één-keer-levering, zodat de gateway elke update minstens één keer zal zien. En als extra zekerheid publiceert het control plane de volledige configuratie elke 10 minuten opnieuw — zelfs als een tussentijdse update is gemist, convergeert de gateway in het ergste geval binnen 10 minuten naar de juiste status. Afwijking is door het ontwerp begrensd.

‍