MCP Tool-goedkeuringen uitgelegd: Van afwachtende aanroep tot begrensde menselijke beslissing

Een human-in-the-loop-controle is alleen nuttig wanneer het systeem precies behoudt wat er is voorgesteld, wat er is goedgekeurd, hoe lang het recht geldig is en wat er daadwerkelijk is uitgevoerd.

Goedkeuring is een statusovergang, geen modaal dialoogvenster

Menselijke goedkeuring wordt vaak getekend als een ruit tussen een agent en een tool. Die weergave laat de lastige onderdelen weg. Welke exacte operatie staat te wachten? Welke mens is gemachtigd om te beslissen? Geldt de goedkeuring voor één aanroep of voor een reeks toekomstige aanroepen? Wat gebeurt er als de argumenten of de bedrijfsstatus veranderen? Hoe onderscheidt de aanroeper een status "in behandeling" van een succesvol tool-resultaat?

Een productie-goedkeuringsmechanisme moet een voorstel bewaren, de uitvoering onderbreken vóór het neveneffect optreedt, een beslissingsrecord aanmaken, de scope en levensduur van het verkregen recht definiëren en voldoende status tonen zodat de agent of applicatie veilig kan doorgaan. Het moet ook gescheiden blijven van autorisatie: een mens kan een risicobeslissing goedkeuren, maar het stroomafwaartse systeem bepaalt nog steeds of de geauthenticeerde actor de actie mag uitvoeren.

De tool bevindt zich voorbij de uitvoeringscontrole, dus noch een verzoek in behandeling, noch een melding aan een beoordelaar kan worden aangezien voor een neveneffect. Verlopen en weigering brengen het systeem terug naar een niet-uitvoerende status in plaats van stilzwijgend toekomstige toegang te verlenen.

Hoe TrueFoundry MCP-goedkeuringsbeleid werkt

TrueFoundry documenteert goedkeuringsbeleid voor MCP tool-aanroepen die via de MCP Gateway worden gerouteerd. Een beleid komt overeen met een server- en tool-scope. Wanneer een beveiligde tools/call binnenkomt, maakt de gateway een in behandeling zijnd verzoek aan (of hergebruikt dit) voor dezelfde tool en requester, voert de tool niet uit en informeert de aangewezen goedkeurders. De aanroeper ontvangt een JSON-RPC-resultaat waarvan de metadata aangeeft dat de goedkeuring in behandeling is.

Een goedkeurder kan het verzoek toestaan of weigeren en optioneel een reden opgeven. Zodra het is toegestaan, kunnen aanroepen van die requester naar die server en tool worden uitgevoerd binnen de geconfigureerde geldigheid. Het tool-resultaat bevat goedkeuringsmetadata. Wanneer het recht verloopt, maakt de volgende aanroep een nieuw verzoek aan. Een weigering wordt vastgelegd voor dat specifieke verzoek, maar is geen permanente intrekking van de toegang; een latere aanroep kan een nieuw goedkeuringsverzoek starten.

Dit laatste gedrag wordt snel verkeerd geïnterpreteerd. Goedkeuringsbeleid bepaalt of een normaal toegankelijke tool op een bepaald moment menselijke instemming nodig heeft. Permanente weigering hoort thuis bij toegangsbeheer: verwijder de toegang van de requester of schakel de tool uit. Het herhaaldelijk gebruiken van een weigering als een informeel autorisatiebeleid belast beoordelaars en creëert ruis in de audit-logs.

Scope en geldigheid zijn verschillende dimensies

Een beleid kan gericht zijn op specifieke tools, op tools die door de MCP server als destructief zijn gemarkeerd, of op alle tools op een server. Wanneer scopes elkaar overlappen, geeft de gedocumenteerde prioriteit de voorkeur aan de meest specifieke match: specifiek vóór destructief vóór alles. Geldigheid kan gebaseerd zijn op een aantal uitvoeringen (één keer) van een aanroep of op tijd (een geconfigureerd aantal minuten). Wanneer meerdere beleidsregels van toepassing zijn, wint de meest restrictieve geldigheid.

Het uiteindelijke recht is beperkt tot de requester plus de specifieke MCP server en tool. Het wordt niet gedeeld tussen gebruikers. Weergave van het verzoek in behandeling bevat de tool-argumenten, wat beoordelaars nuttige context geeft. De openbare documentatie vermeldt echter niet dat het recht een hash van essentiële argumenten of een versie van de bedrijfsstatus cryptografisch bindt. Applicaties met een hoge impact moeten die binding zelf toevoegen.

Zo is de goedkeuring van een terugbetalings-tool niet noodzakelijkerwijs een goedkeuring van elk terugbetalingsbedrag, elke bestelling, elke bestemming of elke reden die tijdens een tijdsbestek zou kunnen worden doorgegeven. Als die velden de risicobeslissing veranderen, moet de applicatie de beslissing van de beoordelaar daaraan binden en een nieuwe beslissing vereisen na een materiële wijziging.

De gekoppelde keten scheidt het gedocumenteerde gateway-recht — requester, server, tool en geldigheid — van de aanbevolen applicatiebinding. Bedrag, ontvanger, bronversie en operatie-identiteit vereisen afzonderlijke handhaving wanneer ze de risicobeslissing wezenlijk veranderen.

Ontwerp een goedkeuringsenvelop

In behandeling betekent geen mislukking — en geen succes

Zolang de goedkeuring in behandeling is, retourneert de MCP Gateway een succesvolle JSON-RPC-envelop met tekstuele inhoud die de aanroeper instrueert om te wachten, waarbij isError op false staat en de goedkeuringsmetadata op 'in behandeling' (pending). Dat succes op transportniveau betekent alleen dat de gateway het verzoek heeft verwerkt. Het betekent niet dat de tool is uitgevoerd.

Clients moeten de goedkeuringsmetadata controleren en de status 'in behandeling' als een afzonderlijke status behandelen. Als ze alleen naar transportfouten kijken, kunnen ze het model vertellen dat de tool is geslaagd of het wachtbericht terugkoppelen als gewone tool-output. Herhaalde aanroepen van dezelfde requester naar dezelfde tool hergebruiken het verzoek in behandeling, wat notificatiespam vermindert, maar aanroepers moeten nog steeds wachten op een beslissing in plaats van continue aanroepen te blijven doen (polling/spinning).

Na goedkeuring wordt het resultaat doorgegeven met de metadata status 'goedgekeurd'. De applicatie moet dat resultaat correleren met het oorspronkelijke voorstel en de stroomafwaartse operatie. Het goedkeuringsbewijs beantwoordt de vraag: "Is deze menselijke beslissing vastgelegd onder dit gateway-beleid?" Het 'system of record' beantwoordt de vraag: "Welk effect is definitief doorgevoerd?"

Gateway-goedkeuringen en TrueForge-controlepunten zijn gerelateerd, maar niet identiek

TrueForge ondersteunt ook onderbrekingen tijdens agent-turns voor tools die zijn geconfigureerd om goedkeuring te vereisen. Een onderbroken turn zendt een 'approval-required'-event uit en wordt afgerond met de vereiste acties. De client zoekt de oorspronkelijke tool-aanroep op, verzamelt de beslissing van de beoordelaar en maakt een nieuwe turn aan met een 'toestaan'- of 'weigeren'-respons.

Dat is een orchestratie-controlepunt binnen de TrueForge-sessie. MCP Gateway-goedkeuring is een gateway-beleid dat wordt toegepast op gerouteerde MCP-aanroepen, ongeacht welke compatibele client ze heeft gemaakt. Een organisatie kan een van beide of beide gebruiken. Als beide dezelfde operatie beveiligen, definieer dan de beoogde volgorde en gebruikerservaring, zodat beoordelaars niet hetzelfde risico twee keer goedkeuren zonder toegevoegde waarde.

Een veelvoorkomend patroon is het gebruiken van TrueForge-controlepunten voor taakspecifieke interactie — de agent heeft bevestiging nodig voor deze voorgestelde actie — en MCP Gateway-goedkeuring voor een gedeeld beleid rondom een gevoelige tool. De applicatie voert nog steeds bedrijfsautorisatie en statusvalidatie uit direct vóór de daadwerkelijke wijziging.

De sequentie waarborgt vier claims: de harness legt het taakcontrolepunt vast, de gateway legt het verleende goedkeuringsrecht vast, de applicatie autoriseert de huidige bedrijfsstatus en het gezaghebbende systeem legt vast wat er definitief is doorgevoerd.

Een praktijkvoorbeeld: wijziging in een productie-database

Een agent stelt een migratie voor met behulp van een tool die als destructief is gemarkeerd. Het gateway-beleid komt overeen met de destructieve scope en maakt een verzoek in behandeling aan. De beoordelaar ziet de tool, requester, argumenten, het beleid en de gevraagde geldigheid. Ze staan één uitvoering toe.

Voordat de databasedienst de migratie uitvoert, verifieert deze of het geauthenticeerde subject en de agent gemachtigd zijn voor de doelomgeving, controleert of de migratie-hash overeenkomt met het beoordeelde voorstel, bevestigt dat de schemaversie niet is gewijzigd en legt een operatie-ID vast. Als een van de materiële invoergegevens afwijkt, gaat de actie terug naar beoordeling. Als er bij de uitvoering een timeout optreedt, raadpleegt de dienst het migratierecord voordat er een nieuwe poging wordt gedaan.

De op aantal gebaseerde geldigheid van de gateway voorkomt dat het recht een permanente toestemming wordt. De argument-hash en statuscontrole voorkomen dat een geldig recht een andere operatie autoriseert. De database blijft bepalend voor de vraag of de migratie definitief is doorgevoerd. Elke laag doet een specifieke claim en levert bewijs voor de volgende.

Ergonomie van beoordelingen maakt deel uit van de veiligheid

Een technisch correcte controle kan alsnog mislukken als het beoordelaars aan context ontbreekt of als ze te veel verzoeken met een lage waarde ontvangen. De beoordelingsinterface moet de nadruk leggen op de velden die het risico veranderen: actor, doel, actie, diff, bedrag, bestemming, dataclassificatie, huidige status, omkeerbaarheid en verwachte uitkomst. Gegenereerde tekst kan samenvatten, maar de materiële velden moeten afkomstig zijn uit gestructureerde records.

Routeer verzoeken naar goedkeurders die de bron begrijpen, niet naar een generieke wachtrij. Stel timeouts en escalatiepaden in. Meet de goedkeuringslatentie, het weigeringspercentage, het afhaakpercentage, herhaalde verzoeken, fouten na goedkeuring en terugdraaiingen. Een dalend weigeringspercentage kan duiden op betere voorstellen — of op blindelings goedkeuren — dus combineer workflow-statistieken met steekproefgewijze controle van de besluitkwaliteit.

Fouttesten voor goedkeuringssystemen

• Wijzig een materieel argument na goedkeuring en verifieer dat de applicatie opnieuw om autorisatie of een nieuwe goedkeuring vraagt.
• Probeer het recht van een andere requester te gebruiken.
• Pas het beleid voor specifieke tools, destructieve tools en alle tools gelijktijdig toe; verifieer de prioriteit en restrictieve geldigheid.
• Weiger een verzoek, doe opnieuw een aanroep en verifieer dat het nieuwe verzoek in behandeling correct wordt begrepen in plaats van behandeld als een permanente weigering.
• Verwijder de toegang tot de tool terwijl een verzoek in behandeling is; verifieer dat goedkeuring de ingetrokken autorisatie niet kan herstellen.
• Retourneer een JSON-RPC-resultaat met de status 'in behandeling' naar verschillende clients; verifieer dat geen van deze het succes op transportniveau interpreteert als de uitvoering van de tool.
• Simuleer een timeout na een stroomafwaartse commit; verifieer dat operatiereconciliatie een dubbele uitvoering voorkomt.

Definieer het verbruik en de escalatie van rechten

Een op aantal gebaseerd recht voor "één keer" klinkt eenvoudig, maar een productiesysteem moet nog steeds definiëren wat het verbruikt. De veiligste interpretatie is één geïdentificeerde uitvoering van de goedgekeurde operatie, niet de eerste de beste syntactisch geldige aanroep die toevallig dezelfde tool bereikt. Gelijktijdige aanroepers, automatische herhaalpogingen en parallelle agent-threads kunnen anders een race-conditie veroorzaken om het recht te gebruiken.

Op tijd gebaseerde rechten hebben aanvullende voorwaarden nodig. Als de requester de toegang verliest, de tool wordt uitgeschakeld, het beleid verandert, het doel een risicodrempel overschrijdt of de status van de bron wezenlijk verandert, moet de applicatie de eerdere beslissing als verouderd behandelen, zelfs als de geldigheidsduur bij de gateway nog actief is. Gateway-toegang en bedrijfsautorisatie moeten op het moment van uitvoering opnieuw worden geëvalueerd.

Escalatie moet ook expliciet zijn. Een verzoek dat voor de deadline geen beslissing ontvangt, kan verlopen, worden gerouteerd naar een alternatieve gekwalificeerde beoordelaar of de taak gepauzeerd laten. Het mag niet standaard worden goedgekeurd omdat de agent staat te wachten. Noodprocedures moeten gebruikmaken van beperktere mogelijkheden, een kortere geldigheid, sterker bewijsmateriaal en een beoordeling achteraf, in plaats van het besluitvormingsrecord volledig te omzeilen.

Tot slot moet het aanpassen van het beleid worden gescheiden van de prestaties van de beoordelaar. Een hoog volume aan goedkeuringen kan erop wijzen dat een tool te breed is ingesteld, een drempelwaarde te laag is of dat de workflow de verkeerde beslissingen delegeert. De duurzame oplossing kan een veiliger tool-contract of betere autorisatie zijn — niet simpelweg het toevoegen van meer beoordelaars.

Leg vast welke regel het verzoek heeft aangemaakt en welke regel de uitvoering heeft toegestaan. Zonder beide versies kunnen onderzoekers achteraf niet vaststellen of de menselijke beslissing, de beleidsconfiguratie of de latere applicatiestatus de uitkomst verklaart.

De operationele regel

Human-in-the-loop moet meer betekenen dan alleen "iemand heeft op goedkeuren geklikt". Een verdedigbaar mechanisme identificeert de operatie in behandeling, de beoordelaar, de beslissing, het beleid, de scope, de geldigheid, de uitvoeringspoging en het definitief doorgevoerde effect. Het maakt ook duidelijk welke onderdelen door het platform worden afgedwongen en welke onder de verantwoordelijkheid van de applicatie blijven vallen.

TrueFoundry MCP Gateway biedt een gedeelde goedkeuringsinterface voor gerouteerde tools, terwijl TrueForge een agent-workflow rond een specifiek voorstel kan pauzeren en hervatten. Samen kunnen ze beslissingen controleerbaar maken. Ze veranderen een goedkeuring niet automatisch in een bedrijfsautorisatie of een gegarandeerde eenmalige uitvoering (exactly-once execution) — en door dat duidelijk te benoemen, wordt de architectuur alleen maar sterker.

Referenties

1. TrueFoundry — MCP Tool Approvals.
2. TrueFoundry — MCP Gateway Overview.
3. TrueForge — Use an Agent.
4. TrueForge — SDK Concepts.

Redactionele verantwoording. Dit artikel weerspiegelt de technische interpretatie van TrueFoundry van de geciteerde openbare materialen per 17 september 2026. Productmogelijkheden zijn beperkt tot de gekoppelde documentatie. Voorbeelden en standaardinstellingen dienen ter illustratie; ze vormen geen juridisch advies, audit-oordeel, onafhankelijke benchmark of garantie voor beveiliging, veiligheid of naleving van regelgeving.

‍