Remote-MCP sicher anbinden: Demo Projekt

Tunneln mit API Keys

API-Keys haben durchaus ihren legitimen Platz in der Automatisierung. Sie finden häufig in CI/CD-Pipelines, geplanten Jobs oder Backend-Prozessen Verwendung, die in einer kontrollierten Umgebung laufen. In solchen Fällen wird ein System typischerweise innerhalb klar definierter physischer und logischer Grenzen betrieben, und Credentials werden sorgfältig verwaltet. Ein nächtlicher Build-Job auf einem dedizierten Build-Server ist ein gutes Beispiel: Der Prozess benötigt Zugriff auf ein Repository, und läuft in einer Umgebung, die genau für diesen Zweck ausgelegt ist. Der Zugang zu den Repositories erfolgt üblicherweise mit API Keys oder API tokens, die den Zugriff auf die geschützte Ressourcen gewähren.

Diebstahl von Zugangsdaten

Problematisch werden API tokens, wenn sie in sicherheitskritische KI-Workflows genutzt werden. Genau das ist bei agentenbasierter Automatisierung und sogenannten „Vibe Coding“-Szenarien inzwischen verbreitet. Dort beschreiben Nutzer ein gewünschtes Ergebnis und ein KI-Agent orchestriert die notwendigen Schritte. Dieser Ansatz führt zu schnellen Erfolgen, fördert aber vor allem eine gefährliche Abkürzung: „Welchen API-Key brauchst du?“ wird zu einer normalen Frage ungeachtet davon, wo der Schlüssel landet. In der Regel findet ein solches Vibe Coding nicht in einem geschützten Bereich statt. Im besten Fall innerhalb der Zugriffsrechte des angemeldeten Benutzers.

Chat-Protokolle werden in der Regel lokal gespeichert, in die Cloud synchronisiert, von Tools eingesehen oder in zukünftige Kontexte übernommen. Sobald Zugangsdaten einem Agenten bekannt gemacht werden, ist die Kontrolle darüber bereits verloren.

Wenn er in Chatverläufen, Prompt-Kontexten, Terminal-Historien, Logs, Screenshots oder generierten Konfigurationen auftaucht, wird es einfacher, ihn auszulesen und zu missbrauchen. Ein Angreifer wird dabei dieselben Automatisierungs- und KI-Techniken nutzen, um nach geleakten Zugangsdaten zu suchen.

Proliferation von Zugangsdaten

Hinzu kommt ein zweites Risiko, das weniger offensichtlich, aber genauso gefährlich ist: Sobald Zugangsdaten im Kontext eines Agenten bekannt sind, können diese auch unbeabsichtigt verwendet werden. Ein Agent mit weitreichendem Zugriff kann Aktionen ausführen, die nie beabsichtigt waren, schlicht weil dem Agenten bekannte Zugangsdaten das ermöglichen.

Das Problem umfasst also nicht nur den Diebstahl von Geheimnissen, sondern es geht auch um einen möglichen Schaden an Systeme durch unkontrolliert im Umlauf befindliche Zugangsdaten.

Entscheidungen im professionellen Umfeld

Natürlich birgt nicht jedes Automatisierungsszenario dasselbe Risiko. Wenn jemand einen Assistenten nutzen möchte, um Termine aus einem persönlichen Kalender zusammenzufassen oder öffentliche Fachartikel zu einem Thema zu sammeln, mag derjenige oder diejenige dieses Risiko bewusst akzeptieren. Im professionellen Umfeld ist jedoch Kompetenz gefragt. Sobald Systeme, Quellcode, Tickets, Produktionsdaten oder interne Services betroffen sind, müssen Zugangsdaten deutlich disziplinierter und im Rahmen der geltenden Sicherheitsrichtlinien (Governance) behandelt werden.

Automatisierung ist fantastisch. Sie kann Geschwindigkeit erhöhen, monotone Arbeit verringern und die Qualität von Prozessen verbessern. Diese Vorteile gelten jedoch nur dann, wenn die Automatisierung bewusst und im Rahmen der Regeln entworfen wird.

Ein minimales Fundament sind diese drei Regeln:

• Zugangsdaten oder API-Keys nicht in KI Chats offenlegen. Übergib keine Zugangsdaten an eine Partei oder einen Kanal, denen du nicht vertraust.
• Wenn Zugangsdaten ausgetauscht werden, dann über einen sicheren und verschlüsselten Kanal, der nach dem aktuellen Stand der Technik dafür ausgelegt ist.
• Zugangsdaten in einem Credential Manager wie KeePass, Apple Keychain oder Windows Credential Manager speichern. Sie gehören nicht in unverschlüsselte Dateien, spontane Notizen oder andere Orte, die Tools und Agenten leicht auslesen können.

Diese Regeln sind nicht neu, und sie sind nicht spezifisch für MCP. Es handelt sich um allgemeine Sicherheitspraktiken für den Umgang mit vertraulichen Informationen. Dieselben Prinzipien gelten für jede Drittpartei, jeden Automatisierungs-Stack und jede vertrauliche Information, die unter kontrolliertem Zugriff bleiben sollen.

Erste Schritte

Dieses Projekt demonstriert wie ein MCP-Server in einem geschützten Bereich operiert, der Keycloak für die Benutzeranmeldung und ein serverseitiges GitLab-Token für den Zugriff auf die GitLab-API verwendet. Der zentrale Punkt ist einfach: Der MCP-Client, also im Zweifelsfall der KI Agent, sollte weder das Passwort des Benutzers noch das GitLab-API-Token erhalten.Das sind die beabsichtigten Szenarien im Umgang mit dem Agenten:

• „Analysiere den Fehler XY und erstelle daraus ein Ticket im aktuellen Projekt.“
• „Löse das Ticket #2345. Kommentiere Deine Lösung im Ticket“
• „Schließe das Ticket #2345.“

Das Demo zeigt in kompakter Form, wie sich ein geschützter MCP-Server mit einem Identity-Provider verbinden lässt. Im vorliegenden Projektaufbau werden dabei insbesondere Keycloak als OIDC-Provider, FastAPI als geschützte Python-Anwendung, FastMCP als geschützter Streamable-HTTP-MCP-Server sowie ein browserbasierter Login per Authorization Code Flow mit PKCE kombiniert.

Der entscheidende Punkt dabei: Der Nutzer authentifiziert sich im Browser gegen Keycloak. Benutzername und Passwort müssen nicht an den Python-Server übergeben werden. Der Server arbeitet stattdessen mit validierten Tokens und prüft Signatur, Issuer, Audience und Rollen.

Mehr als ein Login-Beispiel

Interessant ist das Projekt nicht deshalb, weil es KI und MCP mit OAuth verbindet. Interessant ist es, weil es ein wiederkehrendes reales Integrationsproblem in einer Form löst, das für KI- und MCP-Szenarien tatsächlich relevant ist.

Das Demo macht sichtbar, wie ein lokaler oder Desktop-naher Client einen Browser-Login auslöst, wie der Callback für einen lokalen Host verarbeitet wird, wie Access Tokens anschließend für geschützte HTTP- und MCP-Endpunkte genutzt werden und wie dieselbe Identitätsprüfung konsequent auch vor MCP-Tools und Resources gesetzt wird.

Genau diese Kette fehlt in vielen frühen MCP-Beispielen. Dort wird oft nur gezeigt, wie ein Tool bereitgestellt wird. Nicht gezeigt wird, wie Authentifizierung, Autorisierung und Token-Prüfung in einem Setup aussehen, das für Unternehmen überhaupt ernsthaft relevant ist.

Was Unternehmen daraus konkret mitnehmen können

• Wie interne Systeme zusammen mit KI Agenten als atemberaubende Supersysteme gebaut werden können.
• Wie ein sauberer Login-Flow für lokale oder Desktop-basierte Clients aussieht.
• Wie ein Remote-MCP-Server an bestehende Identitätsinfrastruktur angebunden wird.
• Welche Claims und Rollen serverseitig geprüft werden müssen.
• Wie verhindert wird, dass Passwörter oder statische Zugangsdaten an den falschen Stellen landen.
• Wie derselbe Sicherheitsrahmen sowohl für klassische API-Endpunkte als auch für MCP genutzt werden kann.

Gerade für interne Demos, Architekturabstimmungen und Sicherheitsgespräche ist so ein Beispiel wertvoller als eine theoretische Präsentation. Es zeigt nicht nur das Zielbild, sondern einen nachvollziehbaren technischen Pfad dorthin.

Warum SilverQ das Thema so einordnet

Die Einführung von KI Agenten ist nicht nur eine Frage der Werkzeuge und Modell-Anbieter. Das wahre Potenzial liegt in der Anbindung bereits bestehender Systeme, und umfasst ebenfalls die Frage nach Sicherheit und Governance. Wer die Integration von Infrastruktur produktiv denkt, muss deshalb früh klären, wie bestehende Sicherheitsprinzipien auf KI-gestützte Zugriffe erweitert werden.

SilverQ unterstützt Unternehmen dabei, solche Fragen praktisch zu beantworten. Wie Governance im Zusammenspiel mit KI erstellt und umgesetzt wird.

Fazit

KI produktiv einzuführen heißt nicht nur, einen Agenten und einen Anbieter auszuwählen. Es bedeutet Governance so zu gestalten, dass KI-Tools kontrolliert mit echten Unternehmenssystemen arbeiten können.

Das Demo Projekt hilft dabei, die nötigen Schritte nachvollziehbar zu machen und die Produktätivitätsgewinne, die und mit KI zur Verfügung stehen mit Mut und Kompetenz zu heben.

Quellen

• Open Source Projekt: mcp-oauth-demo
• MCP – What is the Model Context Protocol?
• Heise: KI Agent löscht Daten
• Keycloak – Open Source Identity and Access Management