De Human Gate: Ontwerpen van MCP Tool Approvals op de Gateway-grens

MCP geeft clients en servers een standaardmanier om tools te ontdekken en aan te roepen. Het standaardiseert bewust geen universele approval-UI of human-in-the-loop-workflow. De 2026-07-28 Tools-specificatie vermeldt dat implementaties vrij zijn om hun interactiemodel te kiezen, terwijl het aanbeveelt dat applicaties een mens in staat stellen om tool-aanroepen te weigeren. TrueFoundry's MCP Tool Approvals bevinden zich in die implementatieruimte: de Gateway kan een overeenkomende tools/call vasthouden, een goedkeuringsverzoek aanmaken, een goedkeurder op de hoogte stellen en een succesvol resultaat retourneren met TrueFoundry-specifieke goedkeuringsmetadata, zodat een compatibele aanroeper het verschil kan zien tussen wachten op goedkeuring en uitvoering van tool mislukt. De technische waarde is niet dat MCP goedkeuring heeft gestandaardiseerd — dat is niet zo — maar dat goedkeuring kan worden afgedwongen op een gedeelde tool-grens, afgestemd op identiteit en tool, en gecorreleerd met het uitvoeringspad zonder een tijdelijke menselijke beslissing om te zetten in permanent autorisatiebeleid.

1. Begin bij de Protocolgrens

Het belangrijkste onderscheid is dat tussen wat MCP standaardiseert en wat de Gateway implementeert. MCP standaardiseert tool-discovery, aanroepen, schema's, resultaten en — in de herziening van 2026-07-28 — rijkere manieren waarop een tool-workflow aanvullende invoer kan vereisen. De richtlijnen van de specificatie voor gebruikersinteractie zijn bewust losser: applicaties moeten het tonen en aanroepen van tools zichtbaar maken en een mens de mogelijkheid geven om bewerkingen te weigeren, maar het protocol verplicht geen specifieke bevestigingsinterface of goedkeuringslevenscyclus. Dat laat ruimte voor een gateway om organisatiebreed beleid op te leggen zonder te doen alsof het beleidsobject deel uitmaakt van MCP zelf.

De gedocumenteerde stroom van TrueFoundry kan worden gelezen als zes stappen. Een tools/call bereikt de MCP Gateway en komt overeen met een goedkeuringsbeleid; de Gateway houdt de aanroep vast in plaats van de stroomafwaartse tool aan te roepen; het maakt het in afwachting zijnde goedkeuringsverzoek aan of hergebruikt het en stelt het geconfigureerde goedkeuringspad op de hoogte; de aanroeper ontvangt een succesvol resultaat waarvan de _meta.approval_status communiceert dat de uitvoering in afwachting is; een mens keurt goed of wijst af; en bij goedkeuring geeft de Gateway de uitvoering vrij volgens de geconfigureerde geldigheid. Herhaalde aanroepen voor dezelfde in afwachting zijnde requester/tool-context kunnen het in afwachting zijnde verzoek hergebruiken in plaats van elke keer een nieuwe goedkeuringsmelding te genereren.

De pauze is een status op implementatieniveau, geen protocolfout. Dat is een goed contract voor de client, omdat een orchestrator die de metadata begrijpt, kan vertakken op "wachten op goedkeuring" in plaats van de tool als niet-beschikbaar te behandelen. Maar de last is expliciet: van clients die de TrueFoundry-metadata niet begrijpen, is het niet gegarandeerd dat ze correct wachten. De MCP-specificatie van 2026-07-28 definieert ook input_required-resultaten voor verzoeken met meerdere round-trips en verplaatst langdurige Tasks naar een extensie; dat zijn gestandaardiseerde MCP-mechanismen met andere netwerksemantiek. De goedkeuringspoort moet daarom worden beschreven als compatibel met een toenemend onderbreekbare MCP-wereld, niet als een MCP Task die door de Gateway is ingevoegd.

De auditkoppeling is correlatie, geen magie. De gedocumenteerde resultaatmetadata geeft het uitvoeringspad een goedkeuringsstatus en verzoek-id die kunnen worden gebruikt om de aanroep te correleren met de goedkeuringsworkflow. Leid hieruit niet af dat elke tool-resultaat-payload zelf de identiteit van de goedkeurder, het tijdstempel van de beslissing, de reden of de geldigheidsduur bevat, tenzij die velden afzonderlijk aanwezig zijn in het goedkeuringsrecord of de trace. "Correleerbaar met een goedkeuringsbeslissing" is de verdedigbare eigenschap; "zelfstandig compliance-record" is dat niet.

2. De Beveiligingssemantiek Zit in de Scope

Over de goedkeuringsfunctie kan het eenvoudigst worden geredeneerd als deze wordt behandeld als een smal autorisatiecontrolepunt in plaats van als een universele veiligheidslaag. Vier eigenschappen zijn van belang.

Ten eerste verandert de geldigheid de betekenis van "goedgekeurd". Bij geldigheid voor één uitvoering is goedkeuring gekoppeld aan de in afwachting zijnde uitvoering en een human-in-the-loop-beslissing. Bij een op tijd gebaseerde toekenning creëert de menselijke beslissing tijdelijke autoriteit voor latere aanroepen van hetzelfde requester + MCP server + tool-tupel totdat het venster verstrijkt. Dat is nuttig wanneer herhaalde bevestiging geen oordeel zou toevoegen, maar het betekent ook dat latere argumentensets kunnen worden uitgevoerd zonder een verse menselijke beoordeling. Hoe gevoeliger voor argumenten of onomkeerbaarder de actie is, des te sterker is het argument voor goedkeuring voor één uitvoering of voor een aanvullend beleid op argumentniveau.

Ten tweede voorkomt requester-scoping de overdracht van goedkeuringen. Een goedkeuring die aan de ene identiteit is verleend, mag niet stilzwijgend een andere identiteit autoriseren, louter omdat beide agents dezelfde server en tool bereiken. Dat maakt de opgeloste identiteit van de requester deel van de beveiligingsgrens, en niet zomaar een auditlabel.

Ten derde is weigering opzettelijk vluchtig. Een weigering antwoordt "nu niet" voor het in afwachting zijnde verzoek. Als een identiteit de tool nooit mag aanroepen, hoort het duurzame antwoord thuis in servertoegang, tool-expositie of een andere permanente beleidslaag. Door die concepten gescheiden te houden, wordt voorkomen dat een wachtrij van eenmalige goedkeuringsbeslissingen per ongeluk een autorisatiedatabase wordt.

Ten vierde vereist beleidsprioriteit nauwkeurige taal. Het matchen van scope en de levensduur van toekenningen zijn verschillende vraagstukken. Een specifieker goedkeuringsconfiguratie bepaalt welk tool-beleid van toepassing is, terwijl de geldigheid indien van toepassing moet worden opgelost in de richting van de meest beperkende levensduur. Samengevat niet beide ideeën in de leus "het meest beperkende beleid wint" zonder te zeggen welke dimensie wordt opgelost.

3. Approval Fatigue Is een Operationele Foutmodus

Menselijke goedkeuring voegt alleen veiligheid toe wanneer de menselijke beslissing informatie bevat die het statische beleid niet heeft. Als het antwoord feitelijk vooraf vaststaat, wordt de poort latentie plus een auditevent — geen oordeel. Het ontwerpdoel is daarom niet "meer goedkeuren"; het is de resterende, contextafhankelijke beslissingen naar mensen sturen en al het andere coderen als beleid.

Begin met het onderbreekbaar maken van een kleine klasse van ingrijpende acties: destructieve mutaties, productiewijzigingen, externe communicatie, dwaze/dure bewerkingen of andere aanroepen waarbij de context het antwoord kan veranderen. Stuur verzoeken naar met name genoemde eigenaren, niet naar een breed publiek. Houd het geldigheidsvenster evenredig met de hoeveelheid autoriteit die een enkele beslissing zou moeten creëren. En behandel het terugvallen op de beheerder (fallback-to-admin) als een operationele uitzondering die moet worden gemonitord, omdat een server zonder verantwoordelijke goedkeurder van een veiligheidscontrole een knelpunt kan maken.

Meet de poort, maar maak onderscheid tussen metrieken die u zou moeten beheren en metrieken waarvan het product momenteel documenteert dat ze ingebouwd zijn. Nuttige goedkeuringsmetrieken zijn onder meer de latentie van aanmaak tot beslissing, het goedkeurings-/weigeringspercentage, de heraanvraagfrequentie na verstrijken, het aandeel onderbroken aanroepen dat gebruikmaakt van goedkeuringen voor één uitvoering versus op tijd gebaseerde toekenningen, en het gedeelte dat via een fallback-beheerder wordt geleid. Het gedocumenteerde Metrics Dashboard van TrueFoundry toont MCP-verzoek-/tool-doorvoer, latentie en fouten; het documenteert momenteel geen eersteklas dashboard voor goedkeuringslatentie, goedkeuringspercentage of vernieuwingspatronen. Als u die specifieke goedkeuringsmetrieken nodig hebt, leidt u ze af uit goedkeuringsrecords of geëxporteerde gebeurtenissen die beschikbaar zijn in uw implementatie, in plaats van ze toe te schrijven aan de generieke MCP Metrics-weergave.

De poort-audit. Beantwoord voor elke onderbroken tool zeven vragen: Waarom is er een mens nodig in plaats van statisch beleid? Is de geldigheid gebaseerd op één uitvoering of op tijd? Indien op tijd gebaseerd, welke latere argumentwijzigingen kunnen plaatsvinden zonder hernieuwde goedkeuring? Welke opgeloste identiteit is eigenaar van de toekenning? Wie is de met name genoemde goedkeurder en wat is de fallback? Kan de aanroepende client de conventie van het in afwachting zijnde resultaat expliciet herkennen en het opnieuw proberen? En als het onderbreken afhangt van MCP-annotaties zoals destructiveHint, wordt de server dan vertrouwd — of heeft de organisatie de tool onafhankelijk geclassificeerd? Controleer vervolgens of de id van het goedkeuringsverzoek kan worden gecorreleerd met de bijbehorende tool-uitvoering en het beslissingsrecord. Het doel is het bewijs van een echte beslissing, niet een groot volume aan "goedgekeurde" gebeurtenissen.

4. Waar de Poort Zich Bevindt — en Wat Deze Niet Vervangt

Een productie-toolpad heeft verschillende controles met verschillende taken nodig. Het register of het toelatingsproces bepaalt welke servers en tools in de omgeving zijn toegestaan. Authenticatie lost de aanroeper op. Toegangsbeheer bepaalt welke tools die aanroeper mag bereiken. Pre-tool guardrails inspecteren of transformeren de aanroep. Tool Approval kan een toegestane aanroep vasthouden voor een menselijke beslissing. De Gateway dwingt die onderbreking af. De stroomafwaartse MCP-server voert het neveneffect uit. Post-tool guardrails inspecteren het resultaat. Traces en goedkeuringsrecords leveren de bewijsketen.

Dit verduidelijkt ook de relatie met de Agent Harness human-in-the-loop. De Harness kan een beheerde agent pauzeren vóór een gevoelige tool-aanroep, tool.approval_required verzenden, de huidige beurt voltooien en dezelfde sessie hervatten wanneer een UserToolApprovalEvent binnenkomt. Gateway Tool Approvals dwingen beleid af op de gedeelde MCP-grens. Beide kunnen de uitvoering van een tool onderbreken; ze verschillen in levenscyclus en plaatsing, niet omdat de ene een generiek "redeneringscontrolepunt" is en de andere de enige tool-poort.

Er zijn grenzen die het waard zijn om duidelijk te vermelden. Goedkeuring vervangt autorisatie niet. Een mens kan nog steeds worden misleid door een vergiftigde tool-beschrijving of gemanipuleerde argumenten, dus toelatingscontrole en controles op argumentniveau blijven noodzakelijk. Tool-annotaties zijn niet betrouwbaar louter omdat ze via MCP binnenkomen. Op tijd gebaseerde toekenningen ruilen herhaalde beoordeling bewust in voor begrensd gemak. Menselijke beschikbaarheid voegt latentie toe en kan een afhankelijkheid voor de betrouwbaarheid worden. En een Gateway-beleid kan geen MCP-verkeer beheren dat de Gateway omzeilt.

De duurzame architecturale claim is daarom smaller dan "de pauze werd een eersteklas burger van het protocol", en sterker omdat deze precies is: MCP standaardiseert het tool-call-substraat en ondersteunt nu rijkere onderbroken workflows; enterprise-goedkeuringssemantiek blijft een implementatie- en beleidskeuze. Een gedeelde Gateway kan die keuze centraal afdwingbaar, identiteitsgebaseerd, tijdsgebonden en auditeerbaar maken.

Referenties

• Primaire MCP-bronnen — MCP 2026-07-28 Tools specification (gebruikersinteractiemodel, input_required-resultaten, tool-annotaties); MCP 2026-07-28 specification release (Tasks-extensie en overzicht van herzieningen).
• TrueFoundry-documentatie — MCP Tool Approvals; MCP Gateway; Agent Harness human-in-the-loop; roles and collaborators; MCP pre/post tool guardrails; Metrics Dashboard.
• Gerelateerde TrueFoundry technische context — MCP registry; tool poisoning defense; task-based access control; authorization propagation; governance and audit.

Productmechanismen in dit artikel worden beschreven op basis van de huidige TrueFoundry-documentatie; protocolclaims zijn gebaseerd op de MCP 2026-07-28-specificatie en officieel releasemateriaal. De semantiek van in afwachting zijnde resultaten en goedkeuringstoekenningen van TrueFoundry zijn conventies op productniveau, geen MCP-standaard goedkeuringsstatussen. De hierboven voorgestelde goedkeuringsspecifieke operationele metrieken zijn aanbevolen metingen, geen claims dat het huidige Metrics Dashboard toegewijde goedkeuringsgrafieken bevat. Productgedrag en documentatie kunnen veranderen; controleer de huidige documentatie voordat u veldnamen of beleidssemantiek als een compatibiliteitscontract beschouwt.

‍