MCP-stdio-Sicherheitsgrenzen für lokale KI-Agenten

Lokale MCP-Server gelten oft als harmlos, weil sie über stdio kommunizieren und auf demselben Mac wie der Agent laufen. Diese Einschätzung scheitert, sobald der Server eine externe API aufrufen, SSH verwenden, eine Zugangsdaten-Datei lesen oder einen Shell-Befehl mit den Rechten des Entwicklers starten kann. Lokaler Transport entfernt einen Netzwerkabschnitt. Er verringert nicht die Berechtigungen des Prozesses, der die Anfragen entgegennimmt.

Die entscheidende Grenze ist einfach: Ein MCP-Server sollte Kontext und eng begrenzte Berechnungen bereitstellen. Ein vertrauenswürdiges Aktions-Gateway sollte Zugangsdaten verwahren und Aktionen ausführen, die den Rechner verlassen. Werden diese Rollen vermischt, erhält ein Sprachmodell einen bequemen Weg von nicht vertrauenswürdigen Anweisungen zu dauerhaften Berechtigungen. Ich habe diesen Fehler schon als ordentliches Ein-Datei-Tool auftreten sehen, das später zu einer Sammlung aus Tokens, Unterprozessen und Ausnahmen anwuchs, die während eines Vorfalls niemand erklären konnte.

Stdio ist ein Transport, keine Vertrauensentscheidung

MCP-stdio-Sicherheit beginnt mit der Erkenntnis, dass Standardeingabe und -ausgabe keine Absicht authentifizieren. Der MCP-Client startet den Server und tauscht JSON-RPC-Nachrichten über Pipes aus. Die Spezifikation des Model Context Protocol beschreibt stdio als Transport: Der Server liest Nachrichten aus der Standardeingabe und schreibt sie in die Standardausgabe. Sie behauptet nicht, dass der Transport beweist, eine Anfrage sei sicher, von einem Menschen freigegeben oder überhaupt von dem erwarteten Modell erzeugt worden.

Ein lokaler Client kann direkt eine tools/call-Anfrage senden. Er kann die normale Modellschleife umgehen, Aufrufe mit Maschinengeschwindigkeit wiederholen, Argumente wählen, von denen die Toolbeschreibung abgeraten hat, und jedes empfangene Ergebnis behalten. Startet eine kompromittierte Editor-Erweiterung den Client, kann der Server nicht auf magische Weise erkennen, dass der Aufruf nicht von Claude Code oder einem anderen erwarteten Aufrufer stammt. Dafür muss die umgebende Architektur entsprechende Informationen bereitstellen.

Auch der übliche Prozessbaum bietet weniger Isolation, als viele annehmen. Startet dein Agent einen MCP-Server unter deinem Benutzerkonto, übernimmt dieser Server normalerweise deine Benutzeridentität, dein Arbeitsverzeichnis, deine Umgebung, deine Dateiberechtigungen, deinen Netzwerkzugriff und jedes Geheimnis, das du in Umgebungsvariablen hinterlassen hast. Eine Pipe macht diese Berechtigungen nicht kleiner.

Behandle jeden Tool-Aufruf als nicht vertrauenswürdige Anfrage eines Prozesses, der das Modell überzeugt oder sich als Modell ausgegeben hat, ihn auszuführen. Das klingt streng, weil es streng ist. Es ist auch die Annahme, die Prompt-Injection, fehlerhafte Clients, kopierte Konfigurationen und einen Entwickler übersteht, der eine Anfrage mit einem einfachen JSON-RPC-Skript testet.

Der Server sollte vor wiederverwendbaren Berechtigungen stoppen

Ein MCP-Server sollte enden, bevor er einen wiederverwendbaren Zugangsschlüssel offenlegen oder verwalten muss. Gute Aufgaben sind das Durchsuchen eines indizierten Repositorys, das Parsen von Build-Ausgaben, das Formatieren einer Nutzlast, das Lesen einer absichtlich freigegebenen Projektdatei und das Erstellen eines vorgeschlagenen Befehls zur Prüfung. Auch solche Aufgaben können bei schlechter Implementierung Schaden anrichten. Sie benötigen aber kein Geheimnis, das nach Ende der Sitzung weiterverwendbar bleibt.

Externe Aktionen brauchen einen anderen Besitzer. Eine authentifizierte API-Anfrage, eine SSH-Verbindung, eine Paketveröffentlichung, eine Produktionsabfrage oder die Aktualisierung eines Issues verbindet nicht vertrauenswürdige Eingaben mit einer folgenreichen Identität. Bewahre die Zugangsdaten in einer Komponente auf, die die Anfrage selbst ausführt, und gib anschließend ein begrenztes Ergebnis an den MCP-Server oder Agenten zurück.

Diese Unterscheidung wird oft verwischt, weil beide Komponenten lokale ausführbare Dateien sein können. Sie sind trotzdem nicht austauschbar:

• Ein MCP-Server übersetzt eine Agent-Anfrage in eine begrenzte Operation oder in eine Anfrage nach einer solchen Operation.
• Ein Aktions-Gateway besitzt die Zugangsdaten, entscheidet, ob dieser Prozess sie verwenden darf, führt den externen Aufruf aus und protokolliert das Ergebnis.
• Der Agent erhält die Ausgabe, nicht die Möglichkeit, die authentifizierte Aktion außerhalb dieses Gateways zu wiederholen.

Sende niemals API_TOKEN=... als Tool-Ergebnis. Sende auch keine Tresor-Referenz und nenne das sicher. Lege kein Tool offen, das einen privaten Schlüssel auf stdout ausgibt, in der Hoffnung, das Modell werde wegsehen. Sobald der Client ein Geheimnis erhalten hat, ist jede spätere Kontrolle nur noch ein Hinweis.

Auch ein Gateway sollte keine universelle Shell-API werden. run(command) ist verlockend, weil dadurch das Tool-Design entfällt. Zugleich übergibt es Argumentanalyse, Dateizugriff, Netzwerkziele und oft auch den Zugriff auf Geheimnisse an eine undurchsichtige Zeichenkette. Baue stattdessen enge Aktionen wie get_deployment_status, create_issue, run_readonly_query oder ssh_exec mit benanntem Host und eingeschränkter Befehlsfamilie. Enge Aktionen machen Prüfung und Review möglich.

Tool-Schemas beschreiben Aufrufe, begrenzen sie aber nicht

Ein JSON-Schema für ein Tool ist eine nützliche Eingabeprüfung, aber keine Autorisierung. Die MCP-Spezifikation verlangt, dass Tools Eingabeschemas veröffentlichen, und Clients können sie zum Erstellen von Aufrufen verwenden. Ein Modell kann trotzdem jeden schema-konformen Wert auswählen. Noch problematischer: Nachlässige Implementierungen akzeptieren häufig einen schema-konformen String und setzen ihn später in einen Shell-Befehl oder eine URL ein, wo sich seine Bedeutung verändert.

Betrachte ein Tool, das den Status eines Deployments abrufen soll:

{
  "name": "deployment_status",
  "inputSchema": {
    "type": "object",
    "properties": {
      "environment": {"enum": ["staging", "production"]},
      "service": {"type": "string", "pattern": "^[a-z0-9-]{1,48}$"}
    },
    "required": ["environment", "service"],
    "additionalProperties": false
  }
}

Dieses Schema verhindert ein unerwartetes Feld auf der obersten Ebene und weist offensichtliche Shell-Zeichen in service zurück. Es autorisiert den Aufrufer aber nicht dazu, die Produktion zu prüfen, beweist nicht, dass service zum aktuellen Repository gehört, und begrenzt nicht das HTTP-Ziel, nachdem der Server eine URL erstellt hat. Ein Schema-Validator beantwortet die Frage: «Ist die Form korrekt?» Die Autorisierung beantwortet: «Darf dieser Aufrufer diese Aktion jetzt mit dieser Identität ausführen?» Halte diese Fragen im Code und im Review getrennt.

Eine schlechte Implementierung sieht häufig so aus:

subprocess.run(
    f"ssh {host} systemctl status {service}",
    shell=True,
    check=True,
)

Selbst wenn host und service ein großzügiges Schema bestanden haben, erzeugt die Shell-Analyse eine weitere Sprache mit einer weiteren Angriffsfläche. Verwende Argumentvektoren, lehne unbekannte Hosts vor dem Verbindungsaufbau ab und lasse das Gateway die Zugangsdaten anhand einer festen Kennung auswählen. Es darf keinen vom Agenten gelieferten Pfad oder Tokennamen akzeptieren.

Bei HTTP solltest du die URL vor dem Verbindungsaufbau parsen, https verlangen, den normalisierten Hostnamen mit einer genehmigten Liste exakter Hosts vergleichen und Weiterleitungen deaktivieren oder erneut prüfen. Eine Weiterleitung von einem erlaubten Host zu einer internen Adresse oder einem vom Angreifer kontrollierten Endpunkt kann eine scheinbar harmlose Anfrage in eine Offenlegung von Zugangsdaten verwandeln. Verlasse dich nicht auf eine Präfixprüfung wie url.startswith("https://api.example.com"). Benutzerinformationen, Ports und ähnlich aussehende Hostnamen machen String-Prüfungen unzuverlässig.

Die Prozessidentität muss am Freigabepunkt sichtbar sein

Eine menschliche Freigabeschaltfläche hilft nur, wenn sie anzeigt, wer fragt und welche Berechtigung die Freigabe erteilt. «Agentenzugriff erlauben» ist schwach, weil die ausführbare Datei, die die Berechtigung erhält, und deren Gültigkeitsdauer verborgen bleiben. So gewöhnt man Menschen daran, eine vage Aktivitätskategorie freizugeben.

Ein besseres Design identifiziert den anfragenden Prozess anhand seiner Codesignatur, seiner Elternbeziehung, seines Pfads und seiner Lebensdauer. Der Mensch kann dann einen einzelnen Lauf eines bekannten Clients freigeben, statt dauerhaft ein Etikett zu bestätigen. Sobald der Prozess endet, muss auch seine Freigabe enden. Ein neuer Prozess braucht eine neue Entscheidung.

Eine Codesignatur beweist nicht, dass jeder Prompt oder jedes Plugin innerhalb des Clients harmlos ist. Sie beantwortet eine engere, aber dennoch nützliche Frage: Welche signierte ausführbare Datei hat die Berechtigung angefordert? Diese Unterscheidung ist wichtig, wenn ein bösartiges oder verändertes lokales Programm versucht, einen vertrauten Namen wiederzuverwenden. Unter macOS stellt das Betriebssystem Informationen zur Codesignatur bereit, die ein Gateway anzeigen kann, bevor es einen Prozess handeln lässt.

Sallyport verwendet diese Prozessidentität für die Autorisierung pro Sitzung. Sein gesperrter Tresor verweigert jede Aktion, bis der Benutzer ihn mit den hardwaregestützten Kontrollen des Mac öffnet. Das Modell bleibt bewusst klein: ein gesperrter Tresor, eine Freigabe für einen neuen Prozess und optional eine Freigabe für jede Verwendung eines bestimmten Zugangsschlüssels.

Versuche nicht, Freigabeermüdung mit einer komplizierten Richtlinie in natürlicher Sprache zu lösen. Menschen können ein dichtes Regelwerk mit Dutzenden Ausnahmen nach seinem Wachstum nicht zuverlässig beurteilen. Verwende wenige Entscheidungen, die ein Entwickler direkt sehen kann: ob Geheimnisse verfügbar sind, welcher Prozess in diesem Lauf handeln darf und welche Zugangsdaten jedes Mal eine neue Bestätigung brauchen.

Der Umfang der Freigabe muss dem möglichen Schaden folgen

Eine Freigabe pro Sitzung passt zu wiederholten Aufgaben mit geringen Auswirkungen, etwa dem Lesen eines Issue-Trackers oder dem Prüfen des Zustands eines Entwicklungsdienstes. Sie wird gefährlich, wenn dieselbe Freigabe stillschweigend destruktive Datenbankänderungen, Paketveröffentlichungen, Geldtransfers, Kundenkommunikation oder Produktionszugriff per SSH umfasst.

Gib jedem Zugangsschlüssel eine eigene Freigabeempfindlichkeit. Ein schreibgeschütztes Token kann nach der Sitzungsfreigabe verwendet werden. Ein Produktions-Token mit Schreibrechten oder ein SSH-Schlüssel sollte für jede Verwendung eine Bestätigung verlangen. Das Gateway muss genug Kontext anzeigen, damit ein Mensch die Aktion beurteilen kann: die Identität der Zugangsdaten, den Zielhost oder Dienst, die Methode oder Befehlsklasse und bereinigte Argumente. Das Geheimnis selbst darf nicht angezeigt werden.

Eine Freigabe sollte eine konkrete Anfrage autorisieren und nicht das Versprechen, dass sich der Agent später korrekt verhalten wird. Wenn ein Tool-Aufruf POST /releases lautet, darf die Freigabeansicht ihn nicht zu «Release-API verwenden» verkürzen. Methode, endgültiges Ziel und Operationsname unterscheiden einen harmlosen Lesevorgang von einer unumkehrbaren Änderung.

Die verbreitete Alternative ist eine breite Allowlist: eine Domain, ein Shell-Binary oder ein Agent für den gesamten Arbeitstag. Das wirkt effizient, bis eine eingeschleuste Anweisung dieselbe erlaubte Fähigkeit auf ein anderes Repository, einen anderen Endpunkt oder andere Argumente lenkt. Breite Freigaben verringern Unterbrechungen, indem sie die Prüfung in eine Zeit verschieben, in der niemand den konkreten Aufruf sehen kann.

Verwende kurze Gültigkeitsdauern. Eine Sitzungsfreigabe sollte mit dem Client-Prozess verschwinden. Eine Entscheidung pro Aufruf sollte nach dieser einen Aktion ablaufen. Falls ein Gateway später längere Freigaben unterstützen muss, lege Umfang und Ablauf ausdrücklich fest, statt eine zwischengespeicherte Freigabe wie dauerhaftes Vertrauen wirken zu lassen.

SSH braucht eine eigene Grenze und darf kein Shell-Ausweg sein

Bei SSH verlieren lokale Agent-Designs oft ihre Disziplin. Entwickler haben bereits einen SSH-Agenten, Host-Aliase, weitergeleitete Schlüssel und die Gewohnheit, beliebige Befehle im Terminal einzugeben. Die Versuchung liegt nahe, den MCP-Server ssh mit der vorhandenen Umgebung aufrufen zu lassen. Dadurch wird der Agent zum Aufrufer jeder Identität und jeder Hostregel, die deine Shell erreichen kann.

OpenSSH dokumentiert eine wichtige Einschränkung der Agent-Weiterleitung: Ein entfernter Benutzer, der auf den weitergeleiteten Agent-Socket zugreifen kann, kann Operationen von deinem lokalen Agenten anfordern, auch wenn er keine privaten Schlüssel auslesen kann. Das reicht aus, um während der Weiterleitung in deinem Namen zu handeln. Ein autonomer Agent sollte diesen Weg nicht beiläufig wählen, weil er die Berechtigungen über den ursprünglichen Host hinaus erweitert.

Verwende für Agent-Aufgaben eine eigene SSH-Identität und binde sie an einen benannten Host-Eintrag. Beschränke diese Identität auf dem Server mit den für das Konto passenden Optionen, etwa einem erzwungenen Befehl und deaktivierter Weiterleitung, sofern der Anwendungsfall das erlaubt. Wähle auf der lokalen Seite Host und Identität aus einer Konfiguration, die außerhalb der Kontrolle des Agenten liegt. Der Agent darf host: build-staging und eine begrenzte Befehlsaktion anfordern. Er darf aber keinen beliebigen Hostnamen, keinen Pfad zu einem privaten Schlüssel und kein -o ProxyCommand=... übergeben.

Das ist die minimale Form einer Anfrage, die ein Aktions-Gateway prüfen kann:

{
  "action": "ssh_exec",
  "host_id": "build-staging",
  "command_id": "read_service_status",
  "args": {"service": "worker"}
}

Das Gateway ordnet build-staging dem bekannten Host, der Host-Key-Richtlinie, dem Konto und den dedizierten Zugangsdaten zu. read_service_status wird einem festen Argumentvektor zugeordnet. Die Nutzlast wird nicht zu einer Shell-Zeichenkette zusammengefügt. Eine abgelehnte Anfrage sollte den Grund im Audit-Eintrag nennen, ohne Geheimnisse oder möglicherweise schädliche Daten in ein Terminal zu schreiben.

Wenn du eine beliebige Ferndiagnose brauchst, mache daraus eine separate Aktion mit hohen Hürden, einer Bestätigung pro Aufruf und klaren Ausgabelimits. Verstecke beliebigen Shell-Zugriff nicht hinter einem freundlichen Toolnamen wie check_server.

Audit-Einträge müssen den Verursacher überdauern

Ein Textprotokoll, das von demselben Prozess geschrieben wird, der die Aktion ausführt, ist nur so lange ein Beleg, wie dieser Prozess es nicht ändern möchte. Agent-Aktivitäten brauchen einen Datensatz, mit dem sich sowohl der Lauf als auch jeder externe Aufruf rekonstruieren lässt. Außerdem muss sich nachträglich erkennen lassen, ob Einträge entfernt oder bearbeitet wurden.

Protokolliere Prozessidentität, Sitzungskennung, Zeitpunkt, Aktionstyp, Kennung der Zugangsdaten, freigegebenes Ziel, bereinigte Anfrageform, Freigabeergebnis, Antwortstatus und Fehlerkategorie. Trenne ein Sitzungsjournal von einem Aktionsjournal. Die Sitzungsansicht beantwortet: «Welcher Agent-Lauf hatte die Berechtigung?» Die Aktionsansicht beantwortet: «Was hat er mit dieser Berechtigung getan?» Zwinge Ermittler nicht, eines aus einem flachen Strom von Zeilen abzuleiten.

Eine Hashkette bietet eine praktische Integritätsprüfung. Berechne für jeden Eintrag einen Digest aus dem Digest des vorherigen Eintrags und den kanonischen Bytes des neuen verschlüsselten Eintrags. Speichere den neuen Digest zusammen mit dem Eintrag. Ein Prüfer kann dann einen geänderten, entfernten oder vertauschten Eintrag erkennen, ohne den Klartext zu benötigen.

Der Audit-Prüfer sollte unabhängig vom Agenten laufen und keinen Zugriff auf Zugangsdaten benötigen. Eine Befehlsschnittstelle kann so schlicht aussehen:

$ sp audit verify
records: 184
first sequence: 1
last sequence: 184
chain: valid

Dieses Ausgabeformat liefert einem Betreiber konkrete Informationen, die er in einem Ticket oder Vorfallsbericht festhalten kann. Schlägt die Prüfung fehl, sollte der Befehl die erste Sequenz melden, an der die Kontinuität unterbrochen wurde, und einen Exit-Status ungleich null zurückgeben. «Protokoll nicht lesbar» ist für eine Untersuchung zu vage.

Der Nachweis von Manipulation ist nicht dasselbe wie deren Verhinderung. Ein lokaler Benutzer mit ausreichenden Rechten kann das gesamte Protokoll weiterhin löschen oder den Speicher zurücksetzen. Diese Einschränkung muss sichtbar bleiben. Wenn die Anforderungen einen Beweis gegen lokale Rollbacks verlangen, exportiere signierte Checkpoints in ein separates kontrolliertes System. Behaupte nicht, eine lokale Hashkette löse eine Bedrohung, die sie nicht abdeckt.

Geheimnisse aus Umgebungsvariablen und Tool-Ausgaben heraushalten

Umgebungsvariablen sind für eine menschliche Shell-Sitzung bequem, aber für autonome Agenten eine schlechte Begrenzung. Ein Kindprozess übernimmt sie standardmäßig. Debug-Protokolle können sie ausgeben. Ein Befehl, der seine Umgebung auflistet, kann sie an das Modell zurückgeben. Absturzberichte, Supportpakete, Prozessinspektionen und kopierte Terminalprotokolle haben auf diese Weise bereits Geheimnisse offengelegt.

Eine Zugangsdaten-Datei im Workspace ist noch schlechter. Das Modell kann sie lesen, ein Tool kann sie hochladen, ein Git-Befehl kann sie zum Staging hinzufügen und ein Indexierungsdienst kann eine Kopie aufbewahren. Die Datei in ein verstecktes Verzeichnis zu verschieben, verringert die Unfallhäufigkeit, verändert aber nicht die Sicherheitsgrenze.

Bewahre Zugangsdaten in einem vom Aktions-Gateway kontrollierten Tresor auf. Das Gateway wählt die Zugangsdaten anhand einer festen Aktionszuordnung aus und fügt sie nur in seine eigene HTTP- oder SSH-Aktion ein. Es gibt einen Antworttext nur dann nach Filterung zurück, wenn dieser für den Agenten sicher sichtbar ist. Ein Bearer-Token darf niemals das MCP-Ergebnis durchlaufen, auch nicht redigiert, weil Fehler bei der Redaktion dauerhaft Teil des Transkripts werden.

Bei HTTP solltest du einen Antwortvertrag statt einer unveränderten Weitergabe verwenden. Eine Aktion zum Status eines Deployments könnte Folgendes zurückgeben:

{
  "environment": "staging",
  "service": "worker",
  "state": "healthy",
  "revision": "a1b2c3d4"
}

Sie sollte keine Antwort-Header zurückgeben, die Sitzungskennungen, interne Routing-Informationen oder ein neues Token enthalten können. Lege vor der Implementierung fest, welche Felder der Agent benötigt. Eine unveränderte Proxy-Antwort ist eine weitere Abkürzung, deren Rückbau später teuer wird.

Eine kleine Grenze lässt sich unter Druck leichter betreiben

Du kannst eine lokale Agent-Integration auch ohne Richtliniensprache oder großes Sicherheitsprogramm prüfen. Beginne mit dem Aktionsinventar und zwinge jede Aktion in eine von zwei Kategorien: Entweder liest oder berechnet sie lokalen Kontext ohne wiederverwendbare Berechtigungen, oder sie greift auf einen externen Dienst zu und braucht ein Gateway.

Notiere für jede externe Aktion die feste Zielidentität, die vom Gateway ausgewählten Zugangsdaten, die genauen Argumente, die der Agent beeinflussen darf, den Umfang der Freigabe und den erzeugten Audit-Eintrag. Wenn eine Zeile «beliebiger Befehl», «jede URL», «Token aus der Umgebung» oder «Agent wählt Zugangsdaten» enthält, ist die Grenze noch nicht fertig.

Führe diese Fehlerübung durch, bevor du dem Agenten ein nützliches Geheimnis gibst:

1. Sende eine rohe, schema-konforme Anfrage mit einem unerwarteten Ziel oder einem übergroßen Argument.
2. Wiederhole eine zuvor freigegebene Anfrage, nachdem der Client-Prozess beendet wurde.
3. Versuche eine umgeleitete HTTP-Anfrage und eine SSH-Anfrage mit Weiterleitungsoptionen.
4. Sperre den Tresor und bestätige, dass jede Aktion fehlschlägt, bevor eine Netzwerkverbindung geöffnet wird.
5. Verändere einen gespeicherten Audit-Eintrag und prüfe, ob der Audit-Befehl die unterbrochene Kette erkennt.

Diese Tests finden Designfehler, die eine angenehme Demo verbirgt. Ein Modell, das Anweisungen perfekt befolgt, ist kein Sicherheitstest.

Die sauberste lokale Architektur hält den MCP-Server gewöhnlich und austauschbar. Lass ihn nützlichen Kontext bereitstellen und eng entworfene Aktionen anfordern. Lege Geheimnisse, prozessbezogene Freigaben, Ausführung und ein prüfbares Protokoll hinter die Aktionsgrenze. Wenn jemand fragt, warum ein Tool nicht einfach das Produktions-Token erhalten kann, sollte die Antwort im Design sichtbar sein: Das Tool brauchte das Token für seine Aufgabe nie.