Human-in-the-Loop für MCP: TrueFoundry vs. Kong

Human-in-the-Loop (HITL) für MCP ist eine Gateway-Richtlinie, die ausgewählte Tool-Aufrufe pausiert, bis sie von einer autorisierten Person genehmigt oder abgelehnt werden. So können Unternehmen ihren KI-Agenten echte Autonomie verleihen, ohne dass jede irreversible Aktion zu einem unkontrollierten Risiko wird.

‍

Authentifizierung belegt die Identität des Agenten. Autorisierung legt fest, was er aufrufen darf. HITL beantwortet die entscheidende Frage, die beide anderen nicht klären können: Soll diese spezifische Aktion jetzt wirklich ausgeführt werden? Ohne HITL kann ein einziger autorisierter Fehler zu einem P1-Vorfall eskalieren, den sofortigen Entzug sämtlicher Schreibrechte für Agenten nach sich ziehen und das gesamte Agenten-Programm zum Stillstand bringen.

‍

Kurz gefasst

Der Unterschied zwischen TrueFoundry und Kong liegt darin, wo die menschliche Freigabe stattfindet. Kong fungiert als zustandsloses API-Gateway: Es bewertet jeden MCP-Tool-Aufruf und autorisiert oder verweigert ihn synchron, ohne den für das Pausieren und Fortsetzen einer Anfrage erforderlichen Workflow-Status zu speichern. TrueFoundry hingegen kann einen Tool-Aufruf am Gateway halten, zuständige Genehmiger benachrichtigen und eine zeitlich begrenzte, zweckgebundene Freigabe erteilen. Unternehmen, die Kong einsetzen, müssen diesen Workflow für menschliche Freigaben selbst entwickeln und betreiben.

Warum Human-in-the-Loop so wichtig ist

Wenn Berechtigungen nicht ausreichen

Stellen Sie sich ein Plattform-Team im Finanzsektor vor. Die Agenten greifen nur über ein MCP-Gateway auf interne Systeme zu. Identitätsmanagement, RBAC und Audit-Logging sind bereits implementiert. Ein Bereinigungs-Agent hat Zugriff auf Kubernetes, Cloud-Konten und Slack – einschließlich eines destruktiven Datenbank-Tools.

‍

Geben Sie diesem Agenten nun einen plausiblen Auftrag zum Quartalsende: „Bereinige nicht genutzte Infrastruktur.“ Das Risiko wird deutlich, wenn man den Weg von der Berechtigung bis zur Konsequenz verfolgt.

‍

‍

Abb. 01 · Eine Identität und ein Gateway autorisieren beide Pfade. Der Unterschied liegt nicht im Zugriff, sondern in der Konsequenz.

‍

Der Agent beginnt mit harmlosen Aufgaben: Pods auflisten, inaktive Deployments skalieren und Datenbanken inventarisieren. Dann findet er db-fin-rpt-01, das seit 34 Tagen nicht mehr genutzt wurde. Die Heuristik stuft es als veraltet ein, also ruft er delete_database auf.

‍

Der Aufruf ist gültig, authentifiziert, autorisiert und protokolliert. Genau das ist das Problem: Jede herkömmliche Kontrolle prüft lediglich, ob der Aufruf zulässig ist, aber niemand fragt, ob diese irreversible Aktion zum jetzigen Zeitpunkt sinnvoll ist.

Was passiert, wenn HITL fehlt

Sobald der Aufruf ausgeführt wurde, ist der technische Fehler behebbar. Der Vertrauensverlust in die Autonomie des Agenten jedoch nicht.

‍

‍

Abb. 02 · Ein gültiger Löschvorgang wird von unsichtbar zu dringend und endet mit einer Sperre des Schreibzugriffs für den Agenten.

‍

Aus der Sicht der technischen Leitung ist die Lektion nicht, dass dem Agenten Kontrollen fehlten – er hatte alle. Das Versagen lag in der fehlenden Entscheidung zwischen Zulassen und Ablehnen. Eine kurze Freigabe vor delete_database hätte sowohl den P1-Vorfall zum Quartalsende als auch den späteren Rückzug auf schreibgeschützte Agenten verhindern können.

HITL schafft diesen dritten Weg. Routineabfragen und reversible Änderungen laufen weiterhin in Maschinengeschwindigkeit; Löschen, Bezahlen, Senden und Bereitstellen warten auf einen namentlich genannten Menschen. Das Beispiel wird damit zu einem Gateway-Richtlinienproblem und nicht zu einer Wiederherstellungslogik, die jedes Agenten-Team neu erfinden muss.

‍

Wie TrueFoundry HITL implementiert

TrueFoundry macht aus diesem dritten Weg eine erstklassige MCP-Gateway-Richtlinie. Plattform-Teams definieren einmalig, welche Tools eine Genehmigung erfordern, und die Regel gilt dann für alle Agenten, Clients und Frameworks hinweg.

Anhalten, benachrichtigen, entscheiden

Wenden Sie dies auf db-fin-rpt-01 an: Wenn der Agent delete_database aufruft, hält das Gateway die Anfrage vor der Ausführung an, benachrichtigt einen zuständigen Genehmiger und sendet eine Antwort über eine ausstehende Genehmigung zurück, die der Agent sicher erneut versuchen kann. Eine Genehmigung erstellt eine zeitlich begrenzte Freigabe, die auf den Anfragenden, den Server und das Tool beschränkt ist.

‍

‍

Abb. 03 · Der Aufruf pausiert am Gateway und wird erst nach einer begrenzten Genehmigung fortgesetzt oder bleibt mit einer protokol lierten Begründung blockiert.

‍

Da der Genehmigungsstatus am Gateway verwaltet wird, müssen Anwendungsteams nicht für jeden Agenten Pausen-, Fortsetzungs-, Benachrichtigungs-, Ablehnungs- und Audit-Logiken neu implementieren. Nur Mandantenadministratoren und designierte MCP-Server-Genehmiger können Entscheidungen treffen.

‍

Für das Plattform-Team bleibt die Einrichtung eine reine Richtlinienkonfiguration: Server und Tools auswählen, Gültigkeitszeitraum festlegen, Benachrichtigungskanal wählen und speichern. Bei sich überschneidenden Regeln gilt die restriktivste Richtlinie. Genau an dieser Workflow-Grenze beginnt der Vergleich mit Kong.

Was bei Kong fehlt

Die MCP-Kontrollen von Kong authentifizieren Agenten, setzen Tool-ACLs durch und erlauben oder verweigern Aufrufe. Sie unterstützen jedoch keinen nativen Genehmigungs-Workflow, der einen ansonsten zulässigen Tool-Aufruf zurückhalten kann, bis eine menschliche Entscheidung vorliegt.

‍

Das ist die fehlende Ebene. HITL ist zustandsbehaftet: Das Gateway muss eine ausstehende Anfrage speichern, autorisierte Genehmiger benachrichtigen, die Entscheidung protokollieren und eine begrenzte, zeitlich befristete Freigabe erteilen. Eine binäre Ja/Nein-Entscheidung pro Anfrage kann diesen Workflow allein nicht abbilden.

‍

Warum dies zu einem Plattform-Problem wird

• Doppelter Entwicklungsaufwand: Jedes Agenten-Team muss selbst Mechanismen für das Anhalten und Fortsetzen von Prozessen, die Weiterleitung an Genehmiger, Wiederholungsversuche, Timeouts, den Umgang mit Ablehnungen und Audit-Protokolle implementieren.
• Richtlinien-Abweichungen: Jede Implementierung trifft eigene Entscheidungen darüber, welche Tools beschränkt sind, wer genehmigen darf und wie lange eine Genehmigung gültig ist. Plattform-Teams verlieren so einen einheitlichen, durchsetzbaren Standard.
• Operative Last: Die Zentralisierung in einem separaten Dienst bedeutet weiterhin die Verantwortung für ein neues internes Produkt, inklusive Verfügbarkeit, Mandantenfähigkeit, RBAC, Idempotenz, Fehlerbehandlung bei Benachrichtigungen, Upgrades und On-Call-Bereitschaft.
• Fragmentierte Nachweise: Genehmigungen und Ablehnungen sind über Agenten-Dienste und Chat-Kanäle verstreut, was die Analyse von Vorfällen und die Zusammenstellung von Compliance-Nachweisen verlangsamt und fehleranfälliger macht.
• Unternehmensauswirkungen: Teams verzögern entweder den Einsatz von Agenten mit Schreibrechten oder greifen auf pauschale Lesezugriffe zurück. Beides verringert die Entwicklungsgeschwindigkeit und den Nutzen von Agenten-Investitionen.

TrueFoundry vs. Kong: HITL-Vergleich

Diese Kosten resultieren alle aus derselben architektonischen Grenze: Kong steuert die Anfrage, während das Unternehmen den Genehmigungs-Lebenszyklus darum herum aufbauen muss. Der folgende Vergleich macht diese Grenze deutlich.

‍

Funktion

TrueFoundry

Kong

Native MCP HITL-Schleuse

Hält den Tool-Aufruf vor der Ausführung an

Kein nativer Hold-and-Approve-Workflow dokumentiert

Genehmigungs-Workflow

Namentlich genannte Genehmiger; Slack, PagerDuty, Teams, E-Mail

Muss außerhalb des Gateways erstellt werden

Genehmigungserteilung

Durch Anfragenden, Server und Tool begrenzt und zeitlich befristet

Muss separat entworfen und gespeichert werden

Framework-Abdeckung

Einheitliche Gateway-Richtlinie für alle MCP-Clients

Agenten-spezifische Integration oder ein benutzerdefinierter gemeinsamer Dienst

Audit-Modell

Zentraler Nachweis über Genehmigungen und Ablehnungen

Nachweise fragmentiert über Agenten und Kanäle hinweg

Auswirkungen auf das Unternehmen

Einheitliche Kontrolle ohne Änderung des Agenten-Codes

Doppelter Entwicklungsaufwand, Richtlinienabweichungen und operativer Mehraufwand

Der 10-Minuten-Bewertungstest

Die Feature-Tabelle lässt sich auf einen einzigen Live-Beschaffungstest reduzieren. Fragen Sie jeden Anbieter: „Ein autorisierter Agent fordert eine irreversible Aktion auf einem MCP an. Zeigen Sie mir die menschliche Genehmigung, die Richtlinie, die sie ausgelöst hat, und den resultierenden Audit-Trail.“

‍

Wenn die Demo von benutzerdefiniertem Workflow-Code in jedem Agenten abhängt, ist die Genehmigung keine Plattformfunktion, sondern technische Schuld.

‍

Demo buchen und sichern Sie Ihren riskantesten Tool-Aufruf an einem Nachmittag ab oder erkunden Sie die Agent Gateway und MCP Gateway Dokumentation.

‍