Ein KI-Worker soll einen Projektserver prüfen oder eine freigegebene Aktion auslösen. Dafür braucht er passende Werkzeuge und Rechte. Eine Datei mit sämtlichen API-Tokens und privaten SSH-Schlüsseln im Projektordner macht diesen Ablauf bequem, vergrößert aber die möglichen Folgen eines Fehlers oder einer manipulierten Eingabe.
Eine kontrollierte MCP-Vermittlung kann den erlaubten Handlungsspielraum gezielt abbilden. Der Agent fordert eine definierte Aktion an; der Server prüft Identität, Projekt und Berechtigung. Wo der Ablauf es erlaubt, verwendet ein begrenzter Backend-Dienst die benötigten Zugangsdaten, ohne sie an das Modell zurückzugeben.
MCP vermittelt Werkzeuge, nicht automatisch sichere Rechte
Das Model Context Protocol beschreibt, wie Clients Werkzeuge und andere Fähigkeiten eines Servers nutzen. Ob ein Benutzer eine bestimmte Aktion auf einem konkreten Objekt ausführen darf, muss die Anwendung zuverlässig entscheiden. Ein angemeldeter Client ist nicht automatisch für jedes Projekt oder jedes Werkzeug berechtigt.
Für geschützte HTTP-Verbindungen beschreibt MCP einen OAuth-basierten Autorisierungsweg. Die aktuelle Spezifikation unterscheidet diesen von lokalen STDIO-Verbindungen. Die passende Absicherung hängt vom tatsächlichen Transport ab. Ein beliebiger Schlüssel im URL-Parameter oder ein gemeinsames dauerhaftes Token ist keine gleichwertige Umsetzung einer differenzierten Rechteverwaltung.
Ein konkretes Beispiel: Projekt A bleibt Projekt A
Ein Worker erhält die Aufgabe, den Zustand eines vereinbarten Dienstes in Projekt A abzufragen. Ein dafür vorgesehenes Werkzeug akzeptiert eine geprüfte Objektkennung und liefert nur das benötigte Ergebnis. Es bietet keine frei wählbare Shell und keinen allgemeinen Export sämtlicher Geheimnisse.
Jeder Aufruf wird serverseitig gegen Benutzer, Projekt, Werkzeug und Aktion geprüft. Auch eine vom Client veränderte Projektkennung darf keinen Zugriff auf Projekt B ermöglichen. Ziele werden aus freigegebenen Zuordnungen aufgelöst; eine beliebige vom Modell gelieferte Adresse ist kein ausreichender Auftrag. Mandantengrenzen gehören in diese Prüfung.
Token für den richtigen Empfänger prüfen
Beim geschützten HTTP-MCP-Server muss ein Access-Token für den vorgesehenen Empfänger ausgestellt und dort geprüft sein. Audience, erlaubter Umfang und Gültigkeit gehören zusammen. Kurze Laufzeiten begrenzen das Zeitfenster eines gestohlenen Tokens; sie ersetzen weder die serverseitige Objektprüfung noch den Widerrufsprozess.
Die MCP-Sicherheitsdokumentation verbietet ungeprüftes Token-Passthrough: Ein Server soll nicht fremde Tokens als eigenen Berechtigungsnachweis akzeptieren und unverändert an nachgelagerte APIs weiterreichen. Die Anmeldung des MCP-Clients und die Berechtigung gegenüber einem Zielsystem sind getrennte Vertrauensbeziehungen. Ein unklarer Übergang kann einen privilegierten Vermittler für fremde Zwecke missbrauchen; dieses Problem wird als „confused deputy“ bezeichnet.
Geheimnisse im vorgesehenen Backend verwenden
Ein verwaltetes Secrets-Backend kann Zugangsdaten nach Zuständigkeit und Zweck bereitstellen. Der ausführende Dienst erhält nur die notwendigen Rechte. Die Administrationsoberfläche verwaltet Freigaben, Zuordnungen und Entzug; sie macht daraus keinen allgemein lesbaren Passwortkatalog für alle verbundenen Worker.
Ein begrenztes Werkzeug kann etwa einen Zustandswert lesen oder eine ausdrücklich erlaubte Betriebsaktion ausführen und ein bereinigtes Ergebnis zurückgeben. Rohdaten aus dem Secrets-Backend gehören nicht nebenbei in Tool-Ausgaben, Fehlermeldungen, Traces oder Prompts. Muss ein konkreter Client technisch ein Secret erhalten, wird diese Offenlegung ausdrücklich bewertet und auf Umfang, Laufzeit und Empfänger begrenzt. Eine pauschale Geheimnisfreiheitsgarantie wäre dann falsch.
| Prüfpunkt | Gewünschte Grenze | Konkreter Test |
|---|---|---|
| Benutzer und Projekt | Jede Aktion bleibt im erlaubten Projektumfang. | Projektkennung wechseln: unberechtigten Zugriff ablehnen. |
| Werkzeug und Parameter | Nur vorgesehene Aktionen und Ziele sind erreichbar. | Freie Zieladresse oder fremde Objektkennung zurückweisen. |
| Token und Backend | Empfänger und Berechtigungsweg sind eindeutig. | Falsche Audience, Ablauf und Entzug prüfen. |
| Secrets und Rückgaben | Nur benötigte Ergebnisse verlassen das Backend. | Toolausgaben, Fehler und Logs auf Rohwerte kontrollieren. |
| Freigabe und Betrieb | Folgenreiche Änderungen sind gezielt freigegeben. | Zielbindung, Laufzeit, Limits und Ausfallweg testen. |
Fremder Inhalt darf keine Freigabe erzeugen
Ein Ticket, eine Webseite oder ein Repository kann Text enthalten, der den Agenten zu anderen Aktionen bewegen soll. Auch Werkzeugbeschreibungen und Rückgaben können manipuliert sein. Solche Inhalte sind Daten und kein Berechtigungsnachweis. Ein Prompt wie „verwende nur Projekt A“ hilft bei der Aufgabenbeschreibung, ersetzt jedoch keine technisch durchgesetzte Projektgrenze.
Die Wirkung einer Prompt Injection wird durch eng zugeschnittene Werkzeuge, geprüfte Parameter, begrenzte Zielsysteme und unabhängige Rechteprüfung reduziert. Zusätzliche Freigaben richten sich nach der Aktion: Eine Zustandsabfrage braucht einen anderen Ablauf als eine Änderung mit erheblichen Folgen. Eine Freigabe wird an das konkrete Ziel und die beabsichtigte Änderung gebunden.
Protokollierung und Entzug mitplanen
Für einen nachvollziehbaren Betrieb werden Benutzer oder Dienstidentität, Projekt, Werkzeug, Entscheidung, Zeitpunkt und Ergebnis erfasst. Geheimniswerte werden dabei ausgespart. Aufbewahrung, Zugriff auf die Protokolle und die benötigte Detailtiefe werden passend zur Umgebung vereinbart. Ein einzelnes Erfolgslog ersetzt keine Prüfung, was am Ziel tatsächlich passiert ist.
Rate-Limits, Zeitbegrenzungen und ein begrenzter Backend-Umfang reduzieren zusätzlich die Folgen unerwarteter Aufrufe. Beim Entzug werden neue Aufrufe, bereits ausgegebene Nachweise und laufende Aktionen getrennt betrachtet. Ein Ausfall des MCP- oder Secrets-Dienstes benötigt einen definierten Fehler- und Wiederherstellungsweg.
Mit einem kleinen Pilot beginnen
Ein geeigneter Pilot beginnt mit einem Projekt und wenigen lesenden Werkzeugen. Geprüft werden erlaubte und verbotene Objektkennungen, fehlende Rechte, abgelaufene Nachweise, manipulierte Rückgaben und der Ausfall eines Backends. Erst danach werden klar begrenzte Schreibaktionen bewertet. Der Umfang richtet sich nach dem Risiko und dem vorhandenen Betrieb.
DAXS unterstützt bei Architektur, Integration und einem überprüfbaren Werkzeugumfang. Die Fachseite zu MCP und Schnittstellen, der Beitrag zu verwalteten SSH-Zugängen und die Einordnung zur KI-Sicherheit vertiefen die Zusammenhänge. Sie können eine projektbezogene KI-Integration besprechen.
Häufige Fragen
Kann ein MCP-Server alle Zugangsdaten vor dem Modell verbergen?
Bei passend entworfenen serverseitigen Aktionen kann das Modell nur das bereinigte Ergebnis erhalten. Ob dies für jeden benötigten Vorgang möglich ist, muss geprüft werden. Eine technische Übergabe eines Secrets an den Client verändert die Risikobewertung.
Genügt ein langes geheimes Token als Schutz?
Nein. Zusätzlich werden Empfänger, Umfang, Gültigkeit, Benutzer- und Projektzuordnung sowie die konkrete Aktion geprüft. Ein einziges breit berechtigtes Token bietet diese Trennung nicht von selbst.
Wie beginnt ein Pilot mit mehreren Projekten?
Zunächst werden die erlaubten Aktionen für ein Projekt festgelegt und getestet. Ein zweites Projekt wird anschließend auch mit ausdrücklich verbotenen Querverweisen geprüft. Erst eine tatsächlich durchgesetzte Trennung schafft die Grundlage für weitere Aufgaben.
Quellen: MCP: Autorisierung, Fassung 28.07.2026 (externer Link) · MCP: Vertrauensgrenzen und Token-Passthrough (externer Link) · OWASP: Autorisierung pro Aufruf und Objekt (externer Link) · OWASP: Secrets verwalten (externer Link) · OWASP: Prompt Injection begrenzen (externer Link)
Der konkrete Funktions- und Betriebsumfang wird für die jeweilige Umgebung vereinbart.