Interne Systeme an Claude anbinden: was ich beim Bau eines MCP-Gateways gelernt habe

Ich wollte herausfinden, ob sich unsere internen, nur über VPN erreichbaren Systeme aus Claude heraus nutzbar machen lassen, mit echter Identität, und ohne dass die Verbindung zu einem Kanal für abfließende Daten wird.

Das klingt nach einem Problem. Es sind eigentlich drei, und sie werden gern zu einem verrührt:

1. Erreichbarkeit. Die Server von Anthropic können nicht in ein privates Netz routen.
2. Identität. Wissen, wer fragt, auf der anderen Seite eines Clients, der mir nicht gehört.
3. Eingrenzung. Sicherstellen, dass die Verbindung keine Leitung zum Absaugen von Daten ist.

Das erste lösen die meisten Beiträge. Das dritte fand ich interessant, und dort ist am Ende die meiste Arbeit gelandet.

Herausgekommen ist ein Proof of Concept: ein kleines Gateway, das ein simuliertes internes Ticketsystem und ein echtes Nextcloud-Konto an claude.ai anbindet, mit OAuth-Login, benutzerbezogenen Berechtigungen, Antwortlimits und einem Audit-Log. Inzwischen sind ein echter Identity Provider und ein echter Secrets Store dazugekommen, und genau das ist der Teil, von dem ich nicht erwartet hätte, dass er der interessanteste wird. Es wurde nicht gebenchmarkt, nicht lasttestet, es gab kein Security Review und keinen Produktionsbetrieb. Das Architekturmuster ist alt, und keine der einzelnen Ideen stammt von mir. Zeit sparen können höchstens die konkreten Funde und die Fehler, und darum geht es hier.

Drei Wege hinein, und was sie kosten

Es gibt drei Wege, einen Chat-Client an interne Daten zu bringen, und sie unterscheiden sich im Aufwand ungefähr um eine Größenordnung. Den richtigen zu wählen ist der größere Teil der Entscheidung.

Ein lokaler MCP-Server auf dem Rechner der Mitarbeitenden ist der unterschätzte. Claude Cowork Desktop führt seine Agentenschleife auf dem Gerät aus, und lokale MCP-Server laufen dort ebenfalls. Das Notebook hängt ohnehin am VPN, es wird also nichts veröffentlicht und kein Weg von außen geöffnet. Für lesenden Zugriff auf ein internes Wiki oder Ticketsystem ist das etwa ein Tag Arbeit, und dort würde ich anfangen. Cowork Web ist der umgekehrte Fall: Diese Sandbox läuft auf der Infrastruktur von Anthropic und erreicht keine privaten Adressen.

Ein öffentliches Gateway, das Thema dieses Artikels, ist die Antwort, wenn die Anfrage aus einer Umgebung kommt, die man nicht kontrolliert, praktisch also aus dem Chatfenster. Das sind ein bis zwei Wochen statt einem Tag.

MCP Tunnels sehen aus, als müssten sie die Antwort sein, und das ist der Fund, den man früh haben will: Sie funktionieren hier nicht. Aus der Dokumentation von Anthropic, wörtlich: „MCP tunnels created through the Console are not available as connectors in claude.ai."¹ Sie bedienen Managed Agents und die Messages API. Daran ändert keine Infrastrukturarbeit etwas.

Es gibt also keine Konfiguration, in der claude.ai in ein VPN hineinwählt. Irgendetwas von einem selbst muss öffentlich erreichbar sein. Das verschiebt die Frage von „wie tunneln wir rein?" zu „was ist das Schmalste, was wir exponieren können?", und die zweite Frage lässt sich deutlich leichter gut beantworten.

Das Gateway

Das Gateway ist ein Prozess, öffentlich erreichbar, zwischen Chat-Client und internen Systemen. Alles andere bleibt von außen unerreichbar.

Die Richtung der Verbindung ist das, was das Ganze trägt. Das Gateway ruft in das private Netz hinein, der LLM-Anbieter nie. Der Anbieter sieht ausschließlich eine HTTPS-Adresse. Niemand braucht einen VPN-Zugang, und genau das ist die Alternative, die hier ersetzt wird.

Alle Pfeile zeigen in dieselbe Richtung. Es gibt keinen Pfeil vom Chat-Client in das private Netz hinein, und genau darum geht es.

Die Kontrollen sind keine aus einem Framework abgeschriebene Checkliste. Jede steht dort wegen eines konkreten Angriffs:

Zwei weitere haben es nicht in die Tabelle geschafft, sind aber billig: sensible Felder gibt es nur bei Einzelabfragen und nie in Listen, und es gibt Rate Limits pro Identität und pro Tool.

Dürfte ich nur eine Zeile behalten, wäre es die erste, und sie ist zugleich die, die am leichtesten weggehandelt wird. Bauen wir doch einfach ein generisches Query-Tool ein, das ist viel flexibler klingt im Design Review vernünftig, nur ist Flexibilität hier genau die Eigenschaft, die man nicht haben will: Eine Ausdruckssprache deckt jeden Request ab, den man hätte verbieten wollen. Das Bild, zu dem ich immer wieder zurückkomme, ist ein Schalter. Man geht nicht ins Lager. Man fragt, und die Person dahinter macht die zwölf Dinge auf ihrer Liste, egal wie nett man um ein dreizehntes bittet. Ein VPN-Zugang ist die Schlüsselgewalt über das Lager.

Identität reist mit, und ist trotzdem nicht die Grenze

Ein Mensch wählt im Browser eine Identität. Dieses Subject kommt unversehrt in einem System an, das der LLM-Anbieter nicht erreichen kann, und taucht im Audit-Log des Gateways ebenso auf wie im Log des internen Systems: zwei Logs, dasselbe Ereignis, von zwei Seiten.

Danach entscheidet die Identität über die Daten. Auf die Frage „welche offenen Tickets sind mir zugewiesen?" ruft der Assistent zuerst und unaufgefordert ein whoami-artiges Tool auf und filtert auf dem Ergebnis. Gefiltert wird auf einer Identität, die der Aufrufer weder mitliefert noch wählen kann. Dass der Assistent sie von sich aus nachschlägt, ist Bequemlichkeit, keine Durchsetzung.

Am nützlichsten war hier der Irrtum, ich könnte selbst als Identity Provider auftreten. Das verwendete Framework bringt einen In-Memory-OAuth-Provider zum Testen mit, der einen vollständigen OAuth-2.1-Flow fährt und alles automatisch genehmigt, ohne festzuhalten, wer der Benutzer ist.³ Er stellt ein plausibel aussehendes Token ohne Subject aus, whoami liefert also nichts zurück, während die Auth aussieht, als funktioniere sie. Eine Komponente kann ein Protokoll korrekt implementieren und für die Eigenschaft, um die es einem geht, trotzdem nutzlos sein.

Der Demo-Provider ist deshalb weg, diese Aufgabe macht jetzt Keycloak. Das Gateway wurde damit zum reinen Resource Server: Der Chat-Client authentifiziert sich direkt gegen Keycloak, das Gateway prüft nur noch Signaturen gegen die Schlüssel des Realms. Benutzer, Gruppen, Rotation und Widerruf gehören zu etwas, das eine Datenbank und eine Admin-Konsole hat.

Zwei Dinge kamen dabei heraus, die ich nicht vorhergesehen hätte.

Sessions haben aufgehört zu sterben. Unter dem Stellvertreter-Provider beendete jeder Neustart sämtliche Sessions, und da man während der Entwicklung ständig neu startet, fühlte sich das Ganze an, als verlange es alle paar Minuten einen frischen Login. Das war eine Eigenschaft des Deployments, keine des Protokolls. Mit Keycloak funktioniert ein Token, das vor einem kill -9 geholt wurde, auch gegen den frisch gestarteten Prozess.

Keycloak vergibt Scopes pro Client, nicht pro Benutzer. Das versteht man leicht falsch herum, und ich habe es falsch herum verstanden. Beide Demo-Benutzer bekommen tickets:write in ihr Token, weil der Client das anfragen darf. Diesen Scope-Claim als Berechtigung zu behandeln hätte Gruppenzugehörigkeit bedeutungslos gemacht. Das Gateway leitet seine Scopes deshalb aus dem Gruppen-Claim ab, bevor das Framework sie überhaupt sieht, und zwar nur verengend, nie erweiternd. Das Token bleibt die Obergrenze.

Diese Verengung ist es, die eine Fähigkeit außer Reichweite hält. Das Schreib-Tool verlangt einen Scope, den nur eine schreibende Gruppe hat, und einem nur lesenden Benutzer wird der Aufruf nicht bloß verweigert: Das Tool wird ihm nie angeboten, dem Modell wird also nie mitgeteilt, dass es existiert. Zwei unabhängige Schichten, mit Absicht, eine für den Kontext des Modells und eine für den Request-Pfad, und keine verlässt sich darauf, dass die andere hält.

Ein echter Identity Provider hat außerdem einen zweiten Client gebracht. Dieselbe Instanz, derselbe Realm und dieselben Tools wurden aus claude.ai und aus ChatGPT betrieben, die sich unterschiedlich registrieren, und nichts davon ist Code in diesem Projekt. Der Stellvertreter hätte beides implementieren müssen.

Die Injection, die nichts bewirkt

Ein Ticket in den Testdaten enthält eine echte Prompt Injection. Sie weist den Assistenten an, sämtliche Tickets auszugeben, den internen API-Key preiszugeben und Kundendaten per POST an eine externe Adresse zu schicken.

Es passiert nichts. Nicht weil ein Filter zugegriffen hätte, sondern weil keines dieser drei Dinge eine Fähigkeit des Gateways ist. Die Sammelabfrage ist auf zehn Datensätze gedeckelt und lässt das Kundenfeld weg. Der Key gelangt nie in den Kontext des Modells. Es gibt kein Tool, das eine URL entgegennimmt.

Die Injection wird nicht erkannt. Sie findet einfach nichts vor, womit sie arbeiten könnte.

Um diesen Unterschied geht es in der ganzen Übung. Erkennung ist ein Wettrüsten, das man irgendwann verliert, weil sich Anweisungen nicht zuverlässig von Fließtext trennen lassen. Nichts zu haben, worauf sich umlenken ließe, verschlechtert sich dagegen nicht, wenn der Angreifer kreativer wird, denn Kreativität muss weiterhin innerhalb des vorhandenen Vokabulars operieren, und gegenüber dem Ticketsystem sind das vier typisierte Tools.

Ein Live-Durchlauf hat mir die unfreiwillige Fassung dieses Arguments geliefert. Der Assistent rief ein Tool auf, bevor dessen Schema geladen war, bekam einen roten Fehler mit dem Hinweis, es erst nachzuschlagen, tat das und wiederholte den Aufruf erfolgreich. Das Audit-Log zeigte für dieses Tool in dieser Session genau einen Aufruf, Ergebnis ok: Der fehlgeschlagene hat den Browser nie verlassen. Das Modell hat sich geirrt, und der Irrtum war strukturell uninteressant.

Kontakt mit der Realität: der Nextcloud-Login

Gegen ein echtes System war die erste Entscheidung der Authentifizierungs-Flow, und meine erste Wahl war die falsche.

Nextcloud bringt eine OAuth2-App mit, die wie die naheliegende Wahl aussieht. Die eigene Admin-Dokumentation redet einem das aus: „every token has full access to the complete account including read and write permission to the stored files", und weiter, „without scopes and restrictable access it is not recommended to use a Nextcloud instance as a user authentication service."⁴ Wenn ein Hersteller so deutlich vom eigenen Feature abrät, hört man besser hin.

Was stattdessen funktioniert, ist Login Flow v2, der Mechanismus der offiziellen Desktop- und Mobile-Clients: Der Benutzer meldet sich in einem ganz normalen Browserfenster auf Nextclouds eigener Login-Seite an, und die App bekommt am Ende ein App-Passwort, das pro Gerät gilt und einzeln widerrufbar ist.⁵ Es braucht kein Admin-Setup, und 2FA und SSO funktionieren, weil es buchstäblich die normale Login-Seite ist.

Inzwischen gibt es genau einen Schreibzugriff auf Nextcloud, und seine Form ist das Argument dieses Artikels im Kleinen. create_event legt einen Kalendereintrag an und nimmt keinen Kalendernamen entgegen. Keine Formulierung einer Anfrage erreicht einen zweiten Kalender, weil der Parameter nicht existiert. Darunter liegen die Freigaberechte von Nextcloud als unabhängige zweite Schicht: Gegen einen Kalender, den das Konto nur lesen darf, scheitert der Schreibversuch mit dem 403 von Nextcloud, an einer Grenze also, die mein Code nicht aufweichen kann, selbst wenn alle meine eigenen Prüfungen ja gesagt haben.

Dieses Schreib-Tool hat außerdem eine Lücke geschlossen. Von Aufrufern gelieferte Pfade wurden nur von Schrägstrichen befreit, .. lief also durch und wurde zu einem wohlgeformten Request auf ein fremdes Konto. Nextcloud lehnt solche Requests ohnehin ab, es ist also nie etwas abgeflossen. Aber wie der Kommentar am Fix es formuliert: Sich darauf zu verlassen legt die Grenze in fremden Code, und der ganze Sinn dieses Gateways ist, dass die Grenze im eigenen liegt.

Wo das Credential jetzt liegt

Das Nextcloud-App-Passwort lag früher in einem Dictionary im Gateway-Prozess, ich hatte also das Interface eingegrenzt, aber nicht das Credential. Eine Live-Demo hat den Preis dafür konkret gemacht: Das Gateway startete neu, der Login überlebte, weil Keycloak ihn inzwischen besaß, und sämtliche Nextcloud-Verknüpfungen waren weg. Es gab auch keine Möglichkeit, eine einzelne Verknüpfung zu widerrufen, außer den Server neu zu starten.

Vault hält es jetzt. Mehr als der Tausch eines Dictionaries gegen eine Datenbank wird daraus durch die Frage, wohin die Autorisierungsentscheidung gewandert ist. Das Gateway authentifiziert sich nicht als es selbst bei Vault. Es reicht das Keycloak-Token des Aufrufers weiter, Vault prüft diese Signatur eigenständig gegen die Schlüssel von Keycloak und wendet dann eine Policy an, die auf der gerade selbst verifizierten Identität basiert. Welchen Pfad ein Aufrufer lesen darf, leitet sich also daraus ab, für wen Vault ihn hält. Ein Fehler in meinem Code, der nach dem Pfad eines anderen fragt, bekommt ein 403. Das behauptet nicht der Code, das prüft ein Test.

In der Kette stehen damit drei Systeme, und keines davon glaubt mir irgendetwas: Keycloak sagt, wer du bist, Vault sagt, welches Credential du benutzen darfst, Nextcloud sagt, was dieses Konto darf. Wem die Lizenz nicht schmeckt: OpenBao ist ein Drop-in-Ersatz, gleiche API, gleiche Pfade.

Die neuen Kosten, lieber gesagt als später entdeckt: Vault muss erreichbar sein, sonst werden die Nextcloud-Tools gar nicht mehr angeboten. Fail closed ist für einen Credential Store richtig, aber es ist eine neue Abhängigkeit. Und das gespeicherte Credential zu löschen widerruft meinen Zugriff, nicht das App-Passwort selbst, das in Nextcloud gültig bleibt, bis es dort widerrufen wird.

Drei Dinge, die kaputtgegangen sind

Nichts davon ist dramatisch, aber es ist die Sorte Stolperstein, die auf demselben Weg wieder auftaucht.

Die Identität ging beim Token-Refresh still verloren. Das ist der Punkt, den ich am ehesten jemandem im eigenen Bau zur Prüfung mitgeben würde. Sie wurde auf Access Tokens aus dem Authorization-Code-Grant gestempelt, aber nicht auf die aus dem Refresh-Grant. Nach etwa einer Stunde wurde das Subject also leise zu unknown, während die Scopes überlebten: volle Berechtigungen, keine Zuordnung. Teilweises Versagen in einem Auth-Pfad ist schlimmer als vollständiges, weil vollständiges auffällt.

Der Mock war zu sauber. Meine Kalenderauflistung filterte System-Collections über den Namen heraus, was gegen einen lokalen Mock durchging, der ausschließlich echte Kalender zurückgab. Eine echte Instanz liefert noch einige mehr, darunter eine, deren letztes Pfadsegment der Kontoname ist, sodass das Konto als ein nach sich selbst benannter Kalender auftauchte. Der Fix war, statt einer Namensliste auf eine protokollseitige Eigenschaft zu filtern. Danach habe ich den Mock absichtlich unsauberer gemacht, sodass der Test prüft, dass die zusätzlichen Collections herausfallen. Ein Fixture, das aufgeräumter ist als die Produktion, verdeckt genau die Fehlerklasse, die die Produktion finden wird.

Login Flow v2 verwendet die Session, die der Browser schon hat. Öffnet man die Login-URL in einem normalen Fenster, wird stillschweigend das Konto angeboten, mit dem man gerade angemeldet ist. In meinem ersten Live-Test wurde so eine Admin-Session autorisiert statt des vorgesehenen Service-Accounts, und der Flow läuft in beiden Fällen erfolgreich durch, fällt also leicht nicht auf. Vorher abmelden oder ein privates Fenster verwenden.

Was daran weiterhin nicht stimmt

Das ist der Teil, den ich in einem fremden Artikel als Erstes lesen wollen würde.

Das App-Passwort gewährt weiterhin vollen Kontozugriff. Nextcloud hat keine Scopes zu vergeben, das Credential selbst lässt sich also nicht verengen, egal wo es liegt. Verengt ist das Interface: sechs lesende Operationen, ein nur anlegender Schreibzugriff ohne Kalenderargument, keine Pfadnavigation, Limits für Größe und Anzahl, und ein Credential, das das Modell nie berührt. Vault hat verschoben, wo der Schadensradius sitzt, nicht ihn beseitigt. Wer den Gateway-Host kompromittiert, ist immer noch eine Autorisierungsentscheidung von einem Konto entfernt; wer das Modell kompromittiert, hat zwölf typisierte Aufrufe, alle protokolliert.

Fremden Text mit einem Vermerk „das sind nicht vertrauenswürdige Daten" zu umgeben, ist ein Hinweis, keine Grenze. Anweisungen lassen sich nicht zuverlässig von Fließtext trennen. Die eigentliche Verteidigung besteht darin, nichts zu haben, worauf sich umlenken ließe.

Scopes frieren beim Login ein. Jemanden aus einer schreibenden Gruppe zu entfernen beendet eine laufende Session nicht. Das zu beheben heißt, die Gruppenzugehörigkeit beim Refresh erneut abzufragen, was billig ist, aber erst etwas bedeutet, sobald es einen ernstzunehmenden Widerrufsweg gibt.

Der Betriebsteil hat Proof-of-Concept-Qualität. Der Rate Limiter läuft im Prozess, der Ticket-State liegt im Speicher, und der kostenlose Tunnel für die öffentliche Erreichbarkeit rotiert bei jedem Neustart seinen Hostnamen, der Connector muss also jedes Mal neu angelegt werden.

Die Nextcloud-Verifikation lief gegen genau eine Instanz, Version 34.0.1, mit einem Service-Account, über ältere Versionen kann ich also nichts sagen. Die Testsuiten prüfen, dass die beschriebenen Verhaltensweisen gelten, das ist funktionales und kein adversariales Testen. Ein Penetrationstest hat nicht stattgefunden, und dass zwei Clients sich verbinden, schließt aus, dass es nur an der Nachsicht eines einzelnen Anbieters liegt, mehr aber auch nicht.

Wenn ihr das selbst probieren wollt

Der Bau ist kleiner, als das Thema klingt, und die Form ist ungefähr diese:

• Zuerst prüfen, ob ein lokaler MCP-Server auf dem Notebook das schon löst. Wenn alle, die die Daten brauchen, ohnehin am VPN hängen, ist das ein Tag statt zwei Wochen.
• Von den Fragen ausgehen, die Leute tatsächlich stellen, nicht von der API, die zufällig da ist. Zwei oder drei reichen für eine erste Version.
• Pro Frage ein typisiertes Tool schreiben, und den Parameter weglassen, den man sonst verteidigen müsste. Das Schreib-Tool hier ist vor allem deshalb harmlos, weil es keinen Kalendernamen entgegennimmt.
• Nicht der eigene Identity Provider sein. Einen echten davorstellen, Subject und Gruppen aus dem Token nehmen und ihn Sessions und Widerruf besitzen lassen.
• Auch nicht der eigene Secrets Store sein, und wenn möglich den Credential Store den Aufrufer selbst prüfen lassen, statt ihm den eigenen Service-Account vorzuhalten.
• Antwortgrößen und -anzahlen deckeln und jeden Aufruf protokollieren.

Der Code ist nicht der schwierige Teil. Die Entwurfsentscheidungen sind es, und bei denen, die funktioniert haben, ist das Muster jedes Mal dasselbe: Jedes Stück Durchsetzung, das ich an etwas abgegeben habe, das dafür gebaut ist, an Keycloak, an Vault, an die Berechtigungen von Nextcloud, ist ein Stück, das ich nicht mehr falsch machen kann. Die Tool-Fläche entscheidet darüber, welche Dinge überhaupt passieren können, und diese Menge wird im Editor festgelegt, bevor irgendein Modell sie zu sehen bekommt. Man macht eine LLM-Integration nicht sicher, indem man das Modell zum Wohlverhalten bringt, sondern indem man Fehlverhalten nichts Interessantes mehr zu tun übrig lässt.

Wenn ihr vor etwas Ähnlichem steht, sei es die Frage, welche internen Dienste sich überhaupt zum Exponieren lohnen, wie die Tool-Fläche aussehen soll oder wie man das betreibt, ohne VPN-Zugänge zu verteilen, denken wir von Infralovers das gerne mit euch durch, gerade in regulierten oder sicherheitsbewussten Umgebungen. Und wenn ihr das Wissen lieber im Haus aufbaut, haben wir Kurse zu MCP-Server-Entwicklung und HashiCorp Vault.