Das Human Gate: Design von MCP-Tool-Freigaben an der Gateway-Schnittstelle

MCP bietet Clients und Servern einen Standard zum Auffinden und Aufrufen von Tools. Es legt jedoch bewusst keine einheitliche Benutzeroberfläche für Freigaben oder einen festen Human-in-the-Loop-Workflow fest. Die 2026-07-28 Tools-Spezifikation besagt, dass Implementierungen ihr Interaktionsmodell frei wählen können, empfiehlt jedoch, dass Anwendungen dem Menschen die Möglichkeit geben, Tool-Aufrufe abzulehnen. Die MCP-Tool-Freigaben von TrueFoundry nutzen genau diesen Spielraum: Das Gateway kann einen passenden tools/callzurückhalten, eine Freigabeanfrage erstellen, einen Genehmiger benachrichtigen und ein erfolgreiches Ergebnis mit TrueFoundry-spezifischen Freigabe-Metadaten zurückgeben, sodass ein kompatibler Aufrufer zwischen wartet auf Freigabe und Tool-Ausführung fehlgeschlagenunterscheiden kann. Der technische Mehrwert liegt nicht darin, dass MCP die Freigabe standardisiert hat – das ist nicht der Fall –, sondern darin, dass die Freigabe an einer gemeinsamen Tool-Schnittstelle erzwungen, auf Identität und Tool begrenzt und mit dem Ausführungspfad korreliert werden kann, ohne eine temporäre menschliche Entscheidung in eine dauerhafte Autorisierungsrichtlinie zu verwandeln.

‍

1. An der Protokollgrenze ansetzen

Die wichtigste Unterscheidung liegt zwischen dem, was MCP standardisiert, und was das Gateway implementiert. MCP standardisiert die Erkennung von Tools, deren Aufruf, Schemata, Ergebnisse und – seit der Revision vom 28.07.2026 – umfangreichere Möglichkeiten für Tool-Workflows, zusätzliche Eingaben anzufordern. Die Vorgaben der Spezifikation zur Benutzerinteraktion sind bewusst flexibel gehalten: Anwendungen sollten die Bereitstellung und den Aufruf von Tools transparent machen und dem Menschen die Möglichkeit geben, Vorgänge abzulehnen. Das Protokoll schreibt jedoch keine spezifische Bestätigungsoberfläche oder einen bestimmten Genehmigungslebenszyklus vor. Dies lässt einem Gateway den Spielraum, unternehmensweite Richtlinien durchzusetzen, ohne dabei vorzugeben, dass diese Richtlinienobjekte Teil von MCP selbst sind.

Der dokumentierte Ablauf von TrueFoundry lässt sich in sechs Schritten zusammenfassen. Ein tools/call erreicht das MCP-Gateway und entspricht einer Genehmigungsrichtlinie; das Gateway hält den Aufruf an, anstatt das nachgelagerte Tool auszuführen; es erstellt oder verwendet eine bestehende ausstehende Genehmigungsanfrage und benachrichtigt den konfigurierten Genehmigungspfad; der Aufrufer erhält ein erfolgreiches Ergebnis, dessen _meta.approval_status signalisiert, dass die Ausführung aussteht; ein Mensch genehmigt oder lehnt ab; und bei Genehmigung gibt das Gateway die Ausführung gemäß der konfigurierten Gültigkeit frei. Wiederholte Aufrufe für denselben Kontext (Anfragender/Tool) können die ausstehende Anfrage wiederverwenden, anstatt jedes Mal eine neue Genehmigungsbenachrichtigung zu generieren.

Die Pause ist ein Status auf Implementierungsebene, kein Protokollfehler. Das ist ein guter Client-Vertrag, da ein Orchestrator, der die Metadaten versteht, bei „Warten auf Genehmigung“ verzweigen kann, anstatt das Tool als nicht verfügbar zu behandeln. Die Last liegt jedoch explizit beim Client: Es gibt keine Garantie, dass Clients, die die TrueFoundry-Metadaten nicht verstehen, korrekt warten. Die MCP-Spezifikation vom 28.07.2026 definiert zudem input_required Ergebnisse für Anfragen mit mehreren Roundtrips und verlagert lang laufende Tasks in eine Erweiterung; dies sind standardisierte MCP-Mechanismen mit anderer Übertragungssemantik. Das Genehmigungs-Gateway sollte daher als kompatibel mit einer zunehmend unterbrechbaren MCP-Weltbeschrieben werden, nicht als ein vom Gateway eingefügter MCP-Task.

Die Audit-Verknüpfung ist Korrelation, keine Magie. Die dokumentierten Ergebnis-Metadaten geben dem Ausführungspfad einen Genehmigungsstatus und eine Anfragenkennung, die verwendet werden können, um den Aufruf mit dem Genehmigungs-Workflow zu korrelieren. Gehen Sie nicht davon aus, dass jedes Tool-Ergebnis-Payload selbst die Identität des Genehmigers, den Zeitstempel der Entscheidung, den Grund oder das Gültigkeitsfenster enthält, es sei denn, diese Felder sind separat im Genehmigungsdatensatz oder Trace vorhanden. „Korrelierbar mit einer Genehmigungsentscheidung“ ist die vertretbare Eigenschaft; „in sich geschlossener Compliance-Datensatz“ ist sie nicht.

2. Die Sicherheitssemantik liegt im Geltungsbereich

Die Genehmigungsfunktion lässt sich am besten nachvollziehen, wenn sie als enger Autorisierungs-Checkpoint und nicht als universelle Sicherheitsebene betrachtet wird. Vier Eigenschaften sind dabei entscheidend.

Erstens verändert die Gültigkeit die Bedeutung von „genehmigt“. Bei der einmaligen Gültigkeit ist die Freigabe an die ausstehende Ausführung gebunden. Bei einer zeitbasierten Gewährung schafft die menschliche Entscheidung eine temporäre Berechtigung für spätere Aufrufe desselben Tupels aus Anforderer, MCP-Server und Tool, bis das Zeitfenster abläuft. Dies ist nützlich, wenn eine wiederholte Bestätigung keinen zusätzlichen Erkenntnisgewinn brächte, bedeutet aber auch, dass spätere Argumente ohne erneute menschliche Prüfung ausgeführt werden können. Je sensibler oder irreversibler eine Aktion ist, desto stärker spricht dies für eine einmalige Freigabe oder eine zusätzliche Richtlinie auf Argumentebene.

Zweitens verhindert die Eingrenzung des Anforderers die Übertragung von Freigaben. Eine für eine Identität erteilte Freigabe sollte nicht stillschweigend eine andere Identität autorisieren, nur weil beide Agenten denselben Server und dasselbe Tool erreichen. Dadurch wird die aufgelöste Identität des Anforderers zu einem Teil der Sicherheitsgrenze und nicht nur zu einem Audit-Label.

Drittens ist eine Ablehnung absichtlich nur von kurzer Dauer. Eine Ablehnung bedeutet bei der anstehenden Anfrage lediglich „nicht jetzt“. Wenn eine Identität ein Tool grundsätzlich niemals aufrufen darf, gehört diese dauerhafte Entscheidung in die Serverzugriffsrechte, die Tool-Freigabe oder eine andere übergeordnete Richtlinienebene. Die Trennung dieser Konzepte verhindert, dass sich eine Warteschlange aus einmaligen Freigabeentscheidungen versehentlich in eine Autorisierungsdatenbank verwandelt.

Viertens erfordert die Richtlinienpriorität eine präzise Formulierung. Der Abgleich des Geltungsbereichs und die Laufzeit der Gewährung sind unterschiedliche Fragestellungen. Eine spezifischere Freigabekonfiguration bestimmt, welche Tool-Richtlinie Anwendung findet, während sich die Gültigkeit bei Überschneidungen an der restriktiveren Laufzeit orientieren sollte. Fassen Sie beide Konzepte nicht unter dem Slogan „die restriktivste Richtlinie gewinnt“ zusammen, ohne zu spezifizieren, welche Dimension dabei jeweils gemeint ist.

‍