OpenAI Secure MCP Tunnels: Funktionsweise (Leitfaden 2026)

Am 27. Mai 2026 hat OpenAI den Secure MCP Tunnel veröffentlicht. Das Versprechen ist klein und spezifisch: Halten Sie Ihren MCP-Server privat und ermöglichen Sie dennoch den Zugriff durch die Produkte von OpenAI. Der offizielle Leitfaden und das Client-Repository sind vollständig im Quellenverzeichnis am Ende dieses Artikels aufgeführt, sodass Sie die Primärdokumentation nach dem Walkthrough lesen können.

1. TL;DR

Verwenden Sie den Secure MCP Tunnel, wenn Sie einen MCP-Server auf einem Laptop, einer VM, einem Kubernetes-Cluster oder in einem privaten Netzwerk betreiben und möchten, dass ChatGPT, Codex, die Responses API oder AgentKit diesen nutzen können, ohne ihn öffentlich zugänglich zu machen. Sie führen einen kleinen Daemon namens tunnel-client neben dem Server aus. Er baut eine Verbindung zu OpenAI über HTTPS auf, fragt per Long-Polling nach Aufgaben, leitet jede Anfrage an Ihren Server weiter und sendet die Antwort zurück. Keine eingehenden Ports, keine öffentliche URL, kein ngrok.

Überspringen Sie dies, wenn Ihr MCP-Server bereits sicher öffentlich erreichbar ist (verwenden Sie einfach das normale gehostete MCP-Tool mit einer server_url), oder wenn Sie nicht bereit sind, MCP-Datenverkehr über einen von OpenAI gehosteten Endpunkt zu leiten. Und lesen Sie den Sicherheitsabschnitt zweimal: Der Tunnel entfernt Netzwerk- und Anmeldedaten-Exponierung, nicht Prompt-Injection- oder Tool-Poisoning-Risiko. Das sind unterschiedliche Probleme.

2. Was es ist

Hier ist die Definition direkt aus der Dokumentation, die es wert ist, wörtlich zitiert zu werden, da KI-Suchmaschinen sie direkt übernehmen:

“Secure MCP Tunnel ermöglicht es Ihnen, private MCP-Server mit unterstützten OpenAI-Produkten zu verbinden, ohne eingehende Firewall-Ports zu öffnen oder diese Server dem öffentlichen Internet auszusetzen.”

Und der Tunnel selbst, eine Ebene tiefer: “Ein MCP-Tunnel ist eine reine Outbound-Verbindung von einem Host innerhalb Ihres Netzwerks zu einem von OpenAI gehosteten MCP-Endpunkt.” Dieses eine Wort — outbound-only — ist das gesamte Design. Ihr Netzwerk akzeptiert niemals eine Verbindung von OpenAI. Es baut sie immer nur selbst auf.

MCP (Model Context Protocol) ist der offene Standard, der es einem KI-Modell ermöglicht, externe Tools über JSON-RPC aufzurufen. Ein normales gehostetes MCP-Tool benötigt einen öffentlichen server_url — OpenAIs eigene Beispiele verweisen auf Dinge wie https://mcp.stripe.com. Secure MCP Tunnel entfernt diese Anforderung. Der Server kann auf localhostbleiben.

3. Warum es existiert

Zuvor bedeutete die Verbindung eines privaten MCP servers mit einem gehosteten Modell eine von drei unangenehmen Entscheidungen. Jede davon hat einen Fehlermodus, den ein Sicherheitsteam blockieren würde.

1. Öffentlich zugänglich machen. Den MCP server unter einer öffentlichen URL mit TLS und Authentifizierung bereitstellen. Jetzt besitzen Sie eine neue, dem Internet zugewandte Angriffsfläche, und versehentlich exponierte MCP server sind ein dokumentiertes reales Problem.
2. Tunneln mit ngrok oder Cloudflare Tunnel. Funktioniert, ist aber ein Reverse Proxy für allgemeine Zwecke. Quick Tunnels wurden “nicht als Sicherheitsgrenzen konzipiert” — standardmäßig offenes CORS, keine Pfadfilterung, kein MCP-Verständnis.
3. Öffnen Sie eine eingehende Firewall-Regel. Die Option, die Ihr Sicherheitsteam am seltensten genehmigt und die eine Entwicklermaschine überhaupt nicht bieten kann.

Die Antwort von Secure MCP Tunnel ist die Umkehrung der Verbindung. Die Dokumentation drückt es klar aus: Der Tunnelzugriff “folgt dem bestehenden Organisations- und Workspace-Kontext, anstatt einen separaten öffentlichen Eingangspfad einzuführen.” Sie richten keine neue Eingangstür ein. Sie lassen einen Daemon, den Sie kontrollieren, durch die Tür nach außen greifen, die Sie bereits haben.

4. Mentales Modell: Die benannten Komponenten

Fünf Komponenten tragen die gesamte Funktion. Lernen Sie diese Namen, und die Dokumentation lässt sich in einem Durchgang lesen.

Der Datenfluss ist eine Polling-Schleife, kein persistenter Socket, den OpenAI in Ihr Netzwerk offen hält. Lesen Sie es von oben nach unten:

        OpenAI cloud                         Your network (trust boundary)
 ┌─────────────────────────┐          ┌──────────────────────────────────────┐
 │ ChatGPT / Codex /        │          │                                        │
 │ Responses API / AgentKit │          │   tunnel-client (daemon)               │
 │           │              │          │        │            │                  │
 │           v              │          │        │            v                  │
 │  OpenAI-hosted tunnel    │  <====== │  (1) outbound HTTPS long-poll          │
 │  endpoint  (queues work) │          │      GET /v1/tunnel/{id}/poll          │
 │           │              │  ======> │  (2) queued JSON-RPC request           │
 │           ^              │          │        │                               │
 │           │              │          │        v                               │
 │  (4) response returns    │  <====== │  (3) forward to private MCP server     │
 │      to the product      │          │      (stdio command or HTTP URL)       │
 └─────────────────────────┘          │        │                               │
                                       │        v                               │
                                       │   Private MCP server (localhost / VPC) │
                                       └──────────────────────────────────────┘
   The MCP server never has a public listener. Every arrow your network draws
   is OUTBOUND. OpenAI never initiates a connection into your boundary.

Wichtige Erkenntnis: Das Polling-Design ist der entscheidende Punkt. Ein Daemon, der nur ausgehende Verbindungen aufbaut, ist etwas, das eine Firewall und ein Sicherheitsprüfer tatsächlich nachvollziehen können. Ein persistenter eingehender Socket ist das nicht.

5. Kleinstes End-to-End-Beispiel

Dies ist der kanonische Quickstart aus der Dokumentation, wortgetreu. Er setzt voraus, dass Sie bereits einen Tunnel in den Platform Tunnel-Einstellungen erstellt haben und über dessen tunnel_idverfügen. Er richtet den Tunnel auf ein lokales stdio MCP server — ein Python-Skript, das über einen Befehl gestartet wird.

export CONTROL_PLANE_API_KEY="sk-..."

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-stdio \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-command "python /path/to/server.py"

tunnel-client doctor --profile local-stdio --explain
tunnel-client run --profile local-stdio

Drei Befehle erledigen die Arbeit. init schreibt ein benanntes Profil aus einem Beispiel. doctor --explain überprüft das Profil und teilt dir mit, warum etwas nicht einwandfrei funktioniert, bevor du dich darauf verlässt. run startet die Polling-Schleife des Daemons. Halte run am Leben, während du den Connector erstellst und testest — die Dokumentation besagt ausdrücklich: „Connector-Discovery und MCP tool calls hängen vom laufenden Client ab.“

Wenn dein MCP server HTTP anstelle von stdio verwendet, tausche ein Flag aus — verwende --mcp-server-url anstelle von --mcp-command:

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-http \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-server-url https://mcp.internal.example.com/mcp

Bestätige dann, dass der Daemon tatsächlich fehlerfrei läuft, bevor du ChatGPT verwendest. tunnel-client stellt Operator-Endpunkte und eine Loopback-Admin-UI genau dafür bereit:

curl -fsS http://127.0.0.1:8080/healthz   # process is up
curl -fsS http://127.0.0.1:8080/readyz    # connected and polling
open    http://127.0.0.1:8080/ui          # local admin UI (loopback-only)

6. Detaillierter Einblick in die einzelnen Komponenten

6.1 Der Request-Lebenszyklus

Die Dokumentation beschreibt die Schleife in fünf Schritten. Ein Produkt sendet einen MCP request an den von OpenAI gehosteten Endpunkt. Der Endpunkt stellt ihn in die Warteschlange. tunnel-client fragt per long-poll nach anstehenden Aufgaben, leitet jeden JSON-RPC request an deinen privaten MCP server weiter und sendet die Antwort über denselben Tunnel zurück. Wenn ein Connector gestreamte Ergebnisse anfordert, kann der Pfad zwischenzeitliche server-sent events weiterleiten, sodass Streaming-Tools weiterhin funktionieren. Der Punkt der Netzwerk-Initiierung bleibt immer innerhalb deiner Sicherheitsgrenze.

Wichtige Erkenntnis: „long-poll, dann nur das weiterleiten, was du verarbeiten kannst“ sorgt für ein natürliches Backpressure. Dein Server wird nie von einer „thundering herd“ von OpenAI überrollt — der Client zieht die Arbeit in seinem eigenen Tempo.

6.2 tunnel-client und Profile

tunnel-client ist ein Go-Binary, Open Source unter openai/tunnel-client. The docs are firm about distribution: get it from the Platform download link or the latest public release, and “keep your runbook pointed at the latest-release URL instead of hard-coding a specific release URL.” It is not on npm or PyPI. A Profil ist eine benannte Konfiguration (die local-stdio oben), sodass ein Host mehrere Tunnel mit unterschiedlichen Einstellungen ausführen kann. Sie können auch alles über Umgebungsvariablen und Flags steuern, wobei die Priorität flags > env vars > YAML > defaults.

Empfehlung: Verwenden Sie Profile statt einer Flut von Flags. Ein eingechecktes profiles/ Verzeichnis mit Secrets, die als env:VARNAME oder file:/path referenziert werden, macht den Unterschied zwischen einem reproduzierbaren Deployment und einer einmaligen Lösung, die nicht neu erstellt werden kann.

6.3 Wo man es ausführt

Führen Sie tunnel-client innerhalb derselben Vertrauensgrenze aus, die bereits den MCP Server erreichen kann. Die Dokumentation nennt drei Muster:

• Kubernetes Sidecar — führen Sie es neben dem MCP Server in einem Pod aus und verbinden Sie sich über localhost.
• Dediziertes Kubernetes Deployment — führen Sie es separat aus, wenn der Server bereits über einen privaten Service erreichbar ist.
• VM oder systemd Service — führen Sie es auf einem Host aus, der den Server über ein privates Netzwerk erreichen kann.

Empfehlung: Das Sidecar ist die sauberste Standardlösung. Gleicher Pod, localhost hop, ein Lebenszyklus. Greifen Sie nur dann auf die dedizierte Bereitstellung zurück, wenn sich mehrere Workloads einen MCP-Dienst teilen.

6.4 Berechtigungen und Identität

Der Tunnel-Zugriff nutzt Ihren bestehenden Organisations- und Workspace-Kontext. Drei Berechtigungsatome steuern den Zugriff und entsprechen realen Rollen:

Der Runtime-API-Key, den tunnel-client ausführt, benötigt Read + Use. Eine separate Manager-Identität benötigt Read + Manage um Tunnel-Metadaten zu erstellen oder zu bearbeiten. Halten Sie diese getrennt — der Daemon sollte niemals Erstellungs-/Löschrechte besitzen.

Wichtige Empfehlung: Das Prinzip der geringsten Rechte (Least Privilege) ist integriert, also nutzen Sie es. Der langlebige Daemon erhält Use, ein Mensch oder ein CI-Job erhält Manage, und beide teilen sich niemals einen Key.

6.5 Harpoon: Allowlisted HTTP-Callouts

Über MCP hinaus, tunnel-client liefert einen eingebetteten MCP server namens Harpoon der eine kleine Auswahl privater REST-Endpunkte nach Label bereitstellt, mit begrenzten Request- und Response-Größen. Er dient dazu, eine Handvoll interner Dienste zu erreichen, ohne diese öffentlich zugänglich zu machen. Die Dokumentation zieht hier eine klare Grenze: „Harpoon ist kein Allzweck-Proxy: Aufrufer können keine beliebigen Hosts wählen, und Requests sind auf die vom Kunden konfigurierten Ziele und Methoden beschränkt.“

Subjektives Fazit: Harpoon ist ein Skalpell, kein VPN. Wenn Sie feststellen, dass Sie damit „irgendetwas Internes“ erreichen wollen, sind Sie darüber hinausgewachsen und sollten stattdessen einen richtigen MCP server bereitstellen.

6.6 OAuth durch den Tunnel

Wenn Ihr MCP server OAuth verwendet, gibt es einen Fallstrick, der Sie einen Nachmittag kosten wird, wenn Sie ihn übersehen. OAuth Discovery kann durch den Tunnel geleitet werden, und der Tunnel bewahrt die Metadaten des Upstream-Autorisierungsservers für browserbasierte Abläufe. Aber, um es mit den Worten der Dokumentation zu sagen: „Der Autorisierungsserver selbst wird nicht automatisch getunnelt. Wenn er weder aus dem öffentlichen Internet noch vom tunnel-client Host

Subjektives Fazit: Tunneln Sie den MCP server, aber stellen Sie sicher, dass der OAuth-Autorisierungsserver von dort aus erreichbar ist, wo Browser und Client laufen. Ein erreichbarer MCP server mit einem unerreichbaren Auth-Server führt zu einem stillen, verwirrenden Fehler.

7. Was wir falsch eingeschätzt haben

Vier Annahmen haben uns beim ersten Durchlauf Probleme bereitet. Es sind genau die Dinge, die der Marketing-Slogan einen glauben lässt.

Wir nahmen an, „privat“ bedeute, dass die Daten niemals OpenAI berühren. Das bedeutet es nicht. Die Adresse Ihres Servers und die Anmeldedaten bleiben zwar lokal, aber die MCP Request- und Response-Payloads werden dennoch über den gehosteten Endpunkt von OpenAI übertragen, genau wie bei jedem anderen gehosteten Tool-Aufruf. Der Tunnel verbirgt zwar, wo Ihr Server steht; er hält den Tool-Traffic jedoch nicht von der Plattform von OpenAI fern. Wenn eine Payload zu sensibel ist, um sie an ein gehostetes Modell zu senden, ändert ein Tunnel daran nichts.

Wir nahmen an, es sei „OpenAI's ngrok“. Er ist absichtlich eingeschränkter. ngrok leitet beliebigen Traffic an einen Port weiter. Der Tunnel leitet MCP JSON-RPC an Ihren MCP server weiter, plus streng erlaubten HTTP-Traffic via Harpoon. Diese Einschränkung ist ein Feature, kein fehlendes Merkmal.

Wir haben nach npm install. Es gibt keine. tunnel-client ist eine heruntergeladene Binärdatei oder ein Go-Build openai/tunnel-client. Wir haben zehn Minuten damit verschwendet, anzunehmen, dass es ein Paket gibt, weil jedes andere OpenAI SDK eines hat.

Wir gingen davon aus, dass ein Tunnel das gesamte Setup „sicher“ macht. Er sichert den Netzwerkpfad. Er bewirkt jedoch nichts gegen einen bösartigen oder

8. Falsche vs. richtige Muster

9. Häufige Fehler (aus der Dokumentation)

Diese stammen direkt aus den offiziellen Fehlerbehebungs- und Konfigurationshinweisen, wobei die Ursache direkt neben dem Symptom aufgeführt ist.

• Tunnel in ChatGPT nicht sichtbar. Ursache: Der Tunnel ist nicht mit dem Ziel-Workspace verknüpft oder dem Connector-Operator fehlt die Berechtigung „Tunnels Use“. Korrigieren Sie den Workspace-Bereich und die Berechtigung.
• Connector-Discovery oder Tool-Aufrufe schlagen fehl. Ursache: tunnel-client run Gestoppt. Discovery und Aufrufe hängen vom laufenden Client ab. Starten Sie ihn neu und führen Sie ihn erneut aus. doctor --explain.
• Sie können einen Tunnel zwar sehen, aber nicht bearbeiten. Ursache: Der Operator hat zwar „Tunnels Read“, aber nicht „Manage“. Erteilen Sie der Identität, die Metadaten bearbeitet, die Berechtigung „Manage“.
• OAuth schlägt fehl, obwohl der MCP Server erreichbar ist. Ursache: Der Autorisierungsserver ist nicht getunnelt und ist weder aus dem öffentlichen Internet noch vom Client-Host aus erreichbar. Sorgen Sie dafür, dass der Auth-Server erreichbar ist.
• Anfragen über den Tunnel schlagen sporadisch fehl. Ursache: Der Client ist nicht verbunden. Wenn tunnel-client gerade die Verbindung wiederherstellt, schlagen Anfragen fehl, bis er wieder bereit ist. Überwachen Sie /readyz und /metrics.

10. Hinweise zu Leistung, Skalierung und Kosten

Zuerst die ehrlichen Zahlen: OpenAI veröffentlicht keine tunnel-spezifischen Latenz- oder Durchsatzwerte, und es gibt keinen dokumentierten Tunnel-Preis. Was die Docs und das Repo dir jedoch bieten, sind die Stellschrauben, mit denen du das Verhalten steuern kannst.

• Long-Poll-Timing. Der Client nutzt Long-Polling für Aufgaben; das Poll-Fenster und ein Limit für ausstehende Anfragen sind konfigurierbar. Optimiere diese Werte, um das Verhältnis zwischen Leerlaufverbindungen und Abruflatenz auszubalancieren.
• Verbindungs-TTL. Das MCP-Verbindungsfenster ist begrenzt (der Standardwert im Repo liegt im Minutenbereich). Ein Tool, das länger läuft als dieses Fenster, muss den Fortschritt streamen oder rechtzeitig fertig werden, da es sonst unterbrochen wird.
• Backpressure gibt es kostenlos dazu. Da der Client Aufgaben abruft, anstatt sie per Push zu empfangen, verlangsamt ein langsamer MCP-Server seinen eigenen Durchsatz, anstatt unter Last zusammenzubrechen. Du skalierst, indem du mehr Clients oder einen leistungsfähigeren Server einsetzt, nicht durch das Abfangen einer Datenflut.
• Kosten. Für das gehostete MCP-Tool gibt OpenAI generell an, dass du nur für die Token zahlst, die beim Importieren von Tool-Definitionen oder beim Ausführen von Tool-Calls verbraucht werden, ohne zusätzliche Gebühr pro Aufruf. Eine tunnel-spezifische Gebühr ist in den Docs nicht spezifiziert — prüfe dies in den Platform-Einstellungen, bevor du davon ausgehst, dass es bei hoher Skalierung kostenlos ist.

11. Für wen dies geeignet ist (und für wen nicht)

12. Community-Signal

Die Ankündigung stammte vom Entwickler-Account von OpenAI und wurde von Greg Brockman mit der Formulierung „bring-your-own MCP servers“ verstärkt.

Diese Architektur ist nicht exklusiv für OpenAI. Anthropic hat bereits Wochen zuvor ein funktional ähnliches MCP-Tunnel-Muster veröffentlicht, und die Sicherheitsmodells — das Verlagern von Zugangsdaten an den Perimeter bedeutet, dass ein durch Prompt-Injection kompromittierter Agent keine Token stehlen kann — und skeptisch gegenüber dem Lock-in-Effekt.

Die kritische Gegenstimme ist es wert, zitiert zu werden. Die wichtigste Kritik in diesem Thread bringt den Kompromiss klar auf den Punkt:

„Du kontrollierst nicht die Schleife. Du kontrollierst die Grenze. Ob sich dieser Handel für dich auszahlt, hängt davon ab, wie sehr du [dem Anbieter] beim Betrieb der Schleife vertraust und wie viel Vendor-Lock-in du in Kauf nehmen kannst.“
— r/mcp, zum Tunnel-Architekturmuster

Andere im selben Thread stellten die offensichtliche Frage: „Was hindert das lokale Zertifikat daran, geleakt oder gestohlen zu werden?“ und merkten an, dass die Verlagerung des Risikos von Tokens auf die Verfügbarkeit des Anbieters dieses zwar verschiebt, aber nicht beseitigt. Das sind berechtigte Einwände. Ein Tunnel ist ein Kompromiss: weniger Netzwerkexposition, dafür eine stärkere Abhängigkeit von einer von OpenAI gehosteten Steuerungsebene.

Unsere Einschätzung

Secure MCP Tunnel ist ein Schritt in einer größeren Entwicklung: Die großen Modellanbieter wetteifern darum,

Secure MCP Tunnel is one move in a larger shift: the major model vendors are racing to make Ihre privaten Tools nutzbar durch deren gehostete Agents ohne dass Sie irgendetwas offenlegen müssen. Anthropic hat es getan. OpenAI hat es getan. Das gemeinsame Muster — nur ausgehend, Anmeldedaten am Perimeter, vom Anbieter ausgeführte Schleife — entwickelt sich zum Standard-Unternehmensmodell für Agent-Konnektivität. Erwarten Sie, dass Google und andere dasselbe Grundkonzept unter anderen Namen veröffentlichen werden.

Für praktische nächste Schritte behandelt unser MCP Servers Setup Guide die Anbindung von Servern an eine IDE, das Build Your Own MCP Server Tutorial zeigt, wie man den Server schreibt, den Sie hinter einen Tunnel schalten würden, und der OpenAI Agents Python SDK guide

erklärt die breitere Agent-Laufzeitumgebung, die diese Tools nutzt.

15. Häufig gestellte Fragen

• MCP16. Glossar
• : Model Context Protocol, der offene Standard, der es Modellen ermöglicht, externe Tools über JSON-RPC aufzurufen.MCP server
• : ein Prozess, der Tools, Ressourcen und Prompts für einen MCP client bereitstellt.Secure MCP Tunnel
• : OpenAIs Funktion zur Verbindung eines privaten MCP server mit seinen Produkten ohne öffentlichen Listener.tunnel-client
• Von OpenAI gehosteter Tunnel-Endpunkt: der öffentliche Edge-Endpunkt, den OpenAI-Produkte aufrufen; er stellt Aufgaben für Ihren Tunnel in die Warteschlange.
• tunnel_id: die Identität des Tunnels, Format tunnel_ plus 32 Hexadezimalzeichen.
• Runtime API key: die Anmeldedaten, die tunnel-client verwendet; benötigt Tunnels Read + Use Berechtigungen.
• outbound-only: Datenverkehr wird immer von innerhalb Ihres Netzwerks initiiert; OpenAI baut niemals eine Verbindung von außen auf.
• long-poll: der Client hält eine HTTP-Anfrage offen, um auf Aufgaben in der Warteschlange zu warten, anstatt aktiv benachrichtigt zu werden.
• stdio transport: ein MCP Server, der über einen Befehl gestartet und über die Standard-Ein-/Ausgabe (stdin/stdout) angesprochen wird.
• Harpoon: ein eingebetteter MCP Server in tunnel-client für eng begrenzte, erlaubte private HTTP-Aufrufe.
• mTLS: Mutual TLS, bei dem sowohl Client als auch Server Zertifikate vorlegen; optional für die Control Plane und die MCP-Seite.
• connector: das ChatGPT-seitige Objekt, das auf eine Tool-Quelle verweist, einschließlich eines Tunnels.
• Über die Responses API gehostetes MCP-Tool: das mcp tool type that lets the API call an MCP server, normally via a public server_url.

17. Alle Quellen & Links

Primärquellen

• OpenAI: Leitfaden für sichere MCP-Tunnel
• openai/tunnel-client auf GitHub
• OpenAI: MCP und Connectors (gehostetes MCP-Tool)
• MCP-Autorisierungsspezifikation (OAuth 2.1)

Community

• @OpenAIDevs: Tweet zum Start des sicheren MCP-Tunnels
• r/mcp: Die Tunnel-Architektur und die Lock-in-Kritik
• r/OpenAI: Reaktion auf den ChatGPT MCP-Support

Web & Sicherheitskontext

• Invariant Labs: MCP-Tool-Poisoning-Angriffe
• Cloudflare: Remote-MCP-Server (Tunneling nach dem Stand der Technik)
• Solo.io: Sicherheitslücken in MCP-Servern

Interne Links

• Einrichtungsanleitung für MCP-Server
• Erstellen Sie Ihren eigenen MCP-Server
• Verzeichnis der besten MCP-Server
• Leitfaden zum OpenAI Agents Python SDK