Human in the Loop voor MCP: TrueFoundry vs Kong

Human in the Loop voor MCP: TrueFoundry vs Kong

Human in the loop (HITL) voor MCP is een gateway-policy die geselecteerde toolcalls pauzeert totdat een aangewezen persoon deze goedkeurt of weigert. Het stelt organisaties in staat om AI-agents echte autonomie te geven zonder dat elke onomkeerbare actie verandert in een onbeheersbaar risico.

Authenticatie bewijst wie de agent is. Autorisatie bewijst wat deze mag aanroepen. HITL beantwoordt de uiteindelijke vraag die geen van beide kan beantwoorden: moet deze specifieke actie nu plaatsvinden? Zonder HITL kan één geautoriseerde fout veranderen in een P1-incident, wat kan leiden tot het algeheel intrekken van de schrijfaccess voor agents en het stilleggen van het bredere agent-programma.

TL;DR

Het verschil tussen TrueFoundry en Kong komt neer op de plaats waar menselijke goedkeuring plaatsvindt. Kong werkt als een stateless API gateway: het evalueert elke MCP-toolcall en autoriseert of weigert deze synchroon, zonder de workflow-status te behouden die nodig is om een request te pauzeren en te hervatten. TrueFoundry kan een toolcall vasthouden bij de gateway, goedgekeurde bevoegden op de hoogte stellen en een bevoegde, tijdelijke toestemming verlenen. Bedrijven die Kong gebruiken, moeten die workflow voor menselijke goedkeuring zelf bouwen en beheren.

Waarom human in the loop belangrijk is

Wanneer permissies niet voldoende zijn

Stel je een platformteam voor in de financiële dienstverlening. Hun agents bereiken interne systemen alleen via een MCP gateway. Identiteit, RBAC en audit logging zijn al ingericht. Een opruim-agent heeft toegang tot Kubernetes, cloud-accounts en Slack, inclusief een destructieve database-tool.

Geef die agent nu een redelijke prompt aan het einde van het kwartaal: "Ruim ongebruikte infrastructuur op." Het risico wordt zichtbaar wanneer je het verzoek volgt van permissie tot consequentie.

‍Fig. 01 · Één identiteit en één gateway autoriseren beide paden. Het verschil is niet de toegang; het is de consequentie.

De agent begint met onschadelijk werk: pods oplisten, ongebruikte deployments schalen en databases inventariseren. Vervolgens vindt hij db-fin-rpt-01, die al 34 dagen niet is gebruikt. De heuristiek zegt verouderd, dus roept hij delete_database aan.

De call is geldig, geauthenticeerd, geautoriseerd en gelogd. Dat is precies het probleem: elke conventionele controle beantwoordt of de call is toegestaan, terwijl geen enkele controle vraagt of deze onomkeerbare actie op dit moment logisch is.

Wat er gebeurt als HITL ontbreekt

Zodra de call wordt uitgevoerd, is de technische storing te herstellen. Het verlies van vertrouwen in agent-autonomie is dat niet.

Fig. 02 · Een geldige verwijdering verandert van onzichtbaar naar urgent en eindigt met een freeze op schrijftoegang voor agents.

Vanuit het perspectief van de VP Engineering is de les niet dat de agent geen controles had—hij had ze allemaal. Het probleem was het ontbreken van de beslissing tussen toestaan en weigeren. Een korte goedkeuring vóór delete_database had zowel het P1-incident aan het einde van het kwartaal als de latere terugval naar read-only agents kunnen voorkomen.

Human-in-the-loop (HITL) creëert dat derde pad. Routinematige leesopdrachten en omkeerbare wijzigingen gaan door op machinesnelheid; verwijderen, betalen, verzenden en deployen wachten op een aangewezen persoon. Het voorbeeld verandert zo in een gateway-policy-vraagstuk, in plaats van een herstellogica die elk agent-team opnieuw moet uitvinden.

Hoe TrueFoundry HITL implementeert

TrueFoundry maakt van dat derde pad een primair onderdeel van de MCP gateway-policy. Platformteams definiëren eenmalig welke tools goedkeuring vereisen, en de regel geldt voor alle agents, clients en frameworks.

Vasthouden, melden, beslissen

Pas het toe op db-fin-rpt-01: wanneer de agent delete_database aanroept, houdt de gateway het verzoek vast vóór de uitvoering, stelt een bevoegde goedkeurder op de hoogte en retourneert een melding dat de goedkeuring in behandeling is, zodat de agent het verzoek veilig opnieuw kan proberen. Een goedkeuring creëert een tijdelijke toestemming die specifiek is afgestemd op de aanvrager, de server en de tool.

‍ 03 · De call pauzeert bij de gateway en wordt pas hervat na een specifieke goedkeuring, of blijft geblokkeerd met een vastgelegde reden.

Omdat de goedkeuringsstatus zich op de gateway bevindt, hoeven applicatieteams pauzeer-, hervattings-, notificatie-, afwijzings- en auditlogica niet voor elke agent opnieuw te implementeren. Alleen tenant-admins en aangewezen MCP Server Approvers kunnen beslissen.

Voor het platformteam blijft de instelling beperkt tot beleidsconfiguratie: selecteer de server en tools, stel het geldigheidsvenster in, kies een notificatiekanaal en sla op. Wanneer regels elkaar overlappen, wint het meest restrictieve beleid. Die werkstroomgrens is waar de vergelijking met Kong begint.

Wat er ontbreekt in Kong

Kong's MCP-bedieningselementen authenticeren agents, dwingen tool-ACL's af en meenemen of weigeren aanroepen. Ze ondersteunen geen natieve approval-workflow die een anderszins toegestane tool-aanroep kan vasthouden terwijl een mens beslist.

Dat is de ontbrekende laag. HITL is statusvol (stateful): de gateway moet een in behandeling zijnde aanvraag bewaren, geautoriseerde goedkeurders op de hoogte stellen, de beslissing vastleggen en een beperkte, verlopende autorisatie afgeven. Een binaire allow/deny-beslissing per aanvraag kan die workflow niet op zichzelf bieden.

Waarom dit een platformprobleem wordt

• Dubbel werk voor engineering: elk agent-team moet status voor pauzeren en hervatten, routing naar goedkeurders, retries, timeouts, afhandelingslogica voor weigeringen en audit-events implementeren.
• Policy drift: elke implementatie maakt andere keuzes over welke tools worden afgeschermd, wie kan goedkeuren en hoe lang een goedkeuring geldig blijft. Platformteams verliezen één afdwingbare standaard.
• Operationele last: het centraliseren hiervan in een afzonderlijke service betekent nog steeds het beheren van een nieuw intern product, inclusief beschikbaarheid, tenancy, RBAC, idempotentie, notificatiefouten, upgrades en piketdiensten (on-call).
• Gecentraliseerd bewijs ontbreekt: goedkeuringen en afwijzingen zijn verspreid over agent-services en chatkanalen, wat incidentanalyses en de verzameling van compliance-bewijslast trager en minder betrouwbaar maakt.
• Enterprise-resultaat: teams stellen agents met schrijfrechten uit of vallen terug op algemene read-only toegang. Beide verminderen de ontwikkelsnelheid en het rendement op agent-investeringen.

TrueFoundry vs Kong: HITL-vergelijking

Deze kosten vloeien allemaal voort uit dezelfde architectonische grens: Kong beheert het request, terwijl de enterprise de goedkeuringslifecycle eromheen moet bouwen. De onderstaande vergelijking maakt die grens expliciet.

De evaluatietest van 10 minuten

De functietabel laat zich terugbrengen tot één live procurement-test. Vraag elke vendor: "Een geautoriseerde agent vraagt een onomkeerbare actie aan op een MCP. Laat mij de menselijke goedkeuring zien, de policy die deze heeft getriggerd, en het resulterende audit trail."

Als de demo afhankelijk is van custom workflow-code in elke agent, is goedkeuring geen platformfunctionaliteit; het is application debt.

Boek een demo en beveilig je eigen meest risicovolle tool call in één middag, of verken de Agent Gateway en MCP Gateway documentatie.