Action-Gateway für KI-Agenten oder MITM-Proxy: Kontrollpunkte

Ein Action-Gateway für KI-Agenten und ein Man-in-the-Middle-Proxy können beide zwischen einem Agenten und einem externen Dienst sitzen. Diese oberflächliche Ähnlichkeit führt zu falschen Architekturentscheidungen. Das eine Modell führt eine authentifizierte Aktion im Namen des Agenten aus und verwahrt dabei die Zugangsdaten. Das andere leitet Datenverkehr weiter oder fängt ihn ab, den der Agent bereits erzeugt hat.

Dieser Unterschied entscheidet, wo du Nein sagen kannst, was der Agent stehlen kann, was eine Genehmigung bedeutet und ob dein Audit-Eintrag eine beabsichtigte Operation oder einen rekonstruierten Paketfluss beschreibt. Wenn die Anforderung lautet: «Der Agent darf niemals Produktionszugangsdaten besitzen», ist ein Proxy normalerweise die falsche primäre Grenze. Er kann trotzdem eine Aufgabe haben, aber er kann kein Geheimnis reparieren, das bereits im Clientprozess liegt.

Ein Gateway führt benannte Aktionen aus, während ein Proxy Verbindungen verarbeitet

Ein Action-Gateway für KI-Agenten nimmt eine Anfrage für eine externe Operation entgegen, wählt eine gespeicherte Zugangsdaten aus, führt die Operation aus und gibt das Ergebnis zurück. Der Agent fordert Arbeit an. Er erhält weder das Bearer-Token noch das Passwort oder den privaten Schlüssel, die er für eine Wiederholung an anderer Stelle benötigen würde.

Ein Forward-Proxy erhält eine Netzwerkverbindung von einem Client und leitet sie an ein Ziel weiter. Der Client besitzt die Anfrage weiterhin. Bei einfachem HTTP kann der Proxy Methode, URL, Header und Body lesen, weil der Client HTTP an ihn sendet. Bei HTTPS ist der häufige Fall ein CONNECT-Tunnel: Der Proxy baut eine TCP-Verbindung zum Ziel auf und leitet verschlüsselte Bytes in beide Richtungen weiter.

Ein MITM-Proxy verändert den HTTPS-Fall. Er beendet die TLS-Verbindung des Clients, prüft oder verändert die entschlüsselte HTTP-Nachricht und baut anschließend eine separate TLS-Verbindung zum Upstream-Server auf. Der Client muss einer vom Proxy kontrollierten Zertifizierungsstelle vertrauen, weil der Proxy ein Zertifikat für den Zielhost präsentiert.

Diese Modelle beantworten unterschiedliche Fragen:

• Ein Proxy fragt, wohin Datenverkehr fließen darf und, bei Interception, was dieser Datenverkehr aussagt.
• Ein Action-Gateway fragt, ob es eine bestimmte authentifizierte Operation ausführen wird.
• Ein Proxy kann Material aus einer vom Client kontrollierten Anfrage hinzufügen oder entfernen.
• Ein Gateway kann die Zugangsdaten behalten und die authentifizierte Anfrage selbst erstellen.

Der letzte Punkt ist keine Formulierungsfrage. Er entscheidet, ob ein kompromittierter Agent eine Zugangsdaten nehmen und den Dienst von einem anderen Rechner, zu einer anderen Zeit oder über einen anderen Weg aufrufen kann.

Stell dir einen Agenten vor, der eine Bereitstellung erstellen soll. In einem Proxy-Design erstellt der Agent normalerweise POST /deployments, wählt den JSON-Body und sendet die Anfrage. Der Proxy kann sie erlauben, ablehnen, protokollieren oder einen Authorization-Header einfügen. In einem Executor-Design ruft der Agent eine Aktion wie create_deployment mit Argumenten auf. Das Gateway löst Ziel und Geheimnis aus der Konfiguration auf, führt den HTTP-Aufruf aus und gibt den Status sowie den Antwort-Body zurück, den die Aktion freigeben darf.

Auch der Executor muss sorgfältig gestaltet sein. Eine unbedacht definierte generische Aktion wie «beliebige HTTP-Anfrage senden» kann einen großen Teil des Proxy-Modells wiederherstellen. Die Grenze für die Zugangsdaten bleibt jedoch eine andere: Das Gateway besitzt die Zugangsdaten, der Agent nicht.

TLS macht aus Interception ein Problem der Zertifizierungsstelle

HTTPS-Datenverkehr wird nicht allein deshalb für einen gewöhnlichen Forward-Proxy sichtbar, weil er durch diesen Proxy läuft. Das wird so häufig falsch dargestellt, dass Teams Kontrollen auf einer Annahme aufbauen, die beim ersten Client mit CONNECT scheitert.

RFC 9110 beschreibt CONNECT als Anfrage zum Aufbau eines Tunnels zu einem Zielhost und Port. Sobald der Tunnel steht, leitet der Proxy Bytes weiter. Der TLS-Handshake findet innerhalb dieses Tunnels zwischen Client und Ursprungsserver statt. Ein Proxy kann Zielhost, Port, Zeitpunkte, Bytezahlen und Verbindungsergebnis aufzeichnen. POST /v1/... oder einen API-Schlüssel in einem verschlüsselten Header kann er jedoch nicht lesen.

Um HTTPS zu prüfen, muss ein Intercepting-Proxy zum TLS-Endpunkt des Clients werden. TLS 1.3, spezifiziert in RFC 8446, verlangt vom Client, Zertifikatskette und Hostnamen zu validieren. Ein Proxy kann diese Prüfung nur erfüllen, wenn der Client einer Zertifizierungsstelle vertraut, die Zertifikate für die abgefangenen Websites ausstellen kann.

Diese Voraussetzung erzeugt echte Betriebsarbeit:

1. Installiere und schütze eine private CA auf jedem Rechner und in jeder Laufzeitumgebung, die der Agent nutzt.
2. Sorge dafür, dass Sprachlaufzeiten, Paketmanager, Kommandozeilenwerkzeuge, Container und eingebettete Clients ihr vertrauen.
3. Behandle Clients, die öffentliche Zertifikate pinnen oder ihren eigenen Zertifikatsspeicher verwenden.
4. Schütze entschlüsselte Request-Bodies und Zugangsdaten, sobald der Proxy sie erhält.
5. Erkläre, warum ein Prozess, der unbekannten Zertifikatsausstellern misstrauen soll, nun deiner Interception-CA vertraut.

In einer verwalteten Unternehmensumgebung kann das angemessen sein. Es ist kein kleines Implementierungsdetail. Ein Proxy, der den gesamten Agentenverkehr entschlüsselt, wird zum besonders wertvollen Aufbewahrungsort für jedes Geheimnis, jeden Request-Body und jede Antwort, die ihn durchläuft.

Ein Executor, der Zugangsdaten verwahrt, muss nicht jedes Zielzertifikat imitieren, um eine Operation zu beobachten. Er fungiert als HTTP-Client für die Operation, die er besitzt. Er baut eine normale TLS-Verbindung zum Ziel auf, validiert das öffentliche Zertifikat des Ziels wie jeder Client und fügt die gespeicherte Zugangsdaten erst bei der Ausführung hinzu.

Damit verschwinden TLS-Probleme nicht. Das Gateway muss Zertifikate korrekt validieren und seinen Geheimnisspeicher schützen. Es muss aber keine private Interception-CA an den Agentenprozess verteilen, nur um Einblick in eine Aktion zu erhalten.

Ein nützlicher Test lautet: Wenn dein Design-Dokument sagt, dass der Proxy HTTPS-Anfragen prüfen wird, frage, wo der Client der Interception-CA vertraut. Kann das niemand klar beantworten, sieht der Proxy nur Tunnel oder das System scheitert, sobald ein Tool Zertifikate korrekt validiert.

Die Verwahrung der Zugangsdaten verändert den Schaden durch einen kompromittierten Agenten

Die nützliche Sicherheitsgrenze lautet nicht: «Der Agent hat eine Netzwerkanfrage durch unsere Box gestellt.» Entscheidend ist, ob der Agent wiederverwendbare Berechtigungen erhalten kann.

Bearer-Tokens machen das deutlich. Ein API-Server akzeptiert ein Bearer-Token normalerweise von jedem Prozess, der ihn erreichen kann. Erhält ein Agent die Zeichenfolge, kann er sie in eine Datei schreiben, in eine Tool-Ausgabe einfügen, an einen anderen Endpunkt übertragen oder nach Ende der Genehmigungssitzung verwenden. Nachträgliches Schwärzen von Logs hilft dann nicht. Die Zugangsdaten haben ihre vorgesehene Grenze bereits verlassen.

Ein Proxy kann die Offenlegung verringern, wenn er das Token selbst einfügt. Trotzdem muss das Design kritisch geprüft werden. Der Agent kontrolliert die Anfrage, die den Proxy erreicht. Versteht der Proxy die Semantik der API nicht und setzt sie nicht zuverlässig durch, kann der Agent das eingefügte Token für jeden Endpunkt, jede Methode und jeden Payload verwenden, die das Token erlaubt.

Eine Proxy-Regel wie «füge dieses Token für api.example.internal ein» gibt dem anfragenden Prozess die wirksame Berechtigung für diesen gesamten Host. Der Agent sieht die Token-Zeichenfolge zwar nicht, kann den Proxy aber auffordern, destruktive Aufrufe auszuführen. Für ein eng begrenztes Dienstkonto kann das akzeptabel sein. Es ist nicht dieselbe Kontrolle wie eine benannte Bereitstellungsaktion zu erlauben und andere administrative Endpunkte abzulehnen.

Ein Action-Gateway kann eine Zugangsdaten an den Aktionspfad binden, der sie verwendet. Der Agent liefert Argumente, kein Autorisierungsmaterial. Das Gateway kann einem Menschen vor dem Netzwerkaufruf die Identität der Zugangsdaten und die geplante Operation anzeigen. Es kann außerdem eine Anfrage ablehnen, die nicht zum konfigurierten Kanal passt, ohne überhaupt eine Verbindung aufzubauen.

Der klare Unterschied liegt zwischen Geheimnis-Nichtoffenlegung und Begrenzung der Berechtigungen.

Geheimnis-Nichtoffenlegung bedeutet, dass der Agent die Rohdaten der Zugangsdaten nie sieht. Ein Proxy, der Header einfügt, kann das leisten.

Begrenzung der Berechtigungen bedeutet, dass der Agent eine erlaubte Integration nicht in einen universellen authentifizierten Transport verwandeln kann. Dafür braucht es Aktionsdefinitionen, Zielverarbeitung, Argumentvalidierung und Kontrollen vor dem Seiteneffekt. Ein generischer Proxy liefert das nicht automatisch.

SSH macht das Problem noch deutlicher. Die Public-Key-Authentifizierung von SSH weist nach, dass ein Client während des Protokollaustauschs den privaten Schlüssel besitzt. Hat der Agent den privaten Schlüssel, kann er sich überall authentifizieren, wo dieser Schlüssel akzeptiert wird. Hat der Agent nur Zugriff auf einen SSH-Befehl, der über ein Gateway geleitet wird, muss das Gateway oder sein Helfer die Authentifizierung ausführen, ohne den Schlüssel zu exportieren.

RFC 4253 beschreibt das SSH-Transportprotokoll und die dazugehörige Authentifizierungsarchitektur. Die praktische Konsequenz ist einfach: Du kannst nicht sicher «einen privaten SSH-Schlüssel-Header einfügen». Entweder hält der Prozess die Signaturberechtigung, oder ein anderer Prozess führt die authentifizierte Verbindung für ihn aus.

Die Autorisierung muss vor dem externen Seiteneffekt stattfinden

Ein Kontrollpunkt ist nur wertvoll, wenn er vor dem Vorgang eingreift, den du kontrollieren willst. Eine Anfrage zu protokollieren, nachdem ein Upstream-Server sie akzeptiert hat, liefert Belege. Einen Veto-Mechanismus liefert es nicht.

MITM-Proxys bieten häufig Richtlinien- und Genehmigungssysteme auf Basis von Anfrageattributen: Host, URL, Methode, Header, Request-Body, Clientidentität oder Zielkategorie. Das können starke Kontrollen sein, wenn der Proxy entschlüsselten Datenverkehr sieht und das Protokoll der Anwendung versteht. Sie werden jedoch auch zu einem Regelproblem. Jemand muss entscheiden, ob /projects/123/members sicher ist, ob ein JSON-Payload aus einer harmlosen Änderung eine Berechtigungsvergabe macht und ob eine codierte Anfrage einen Stringvergleich umgeht.

Ich habe erlebt, wie Teams mit drei Proxy-Regeln begannen und schließlich eine undokumentierte Sprache aus Ausnahmen pflegten. Das Problem ist nicht, dass Regeln grundsätzlich schlecht wären. Das Problem ist die Annahme, das beliebige Anfrageformat eines Agenten habe eine stabile und eindeutig interpretierbare Richtlinienoberfläche.

Ein Action-Gateway kann ein kleineres Vokabular verwenden. Die Autorisierungsentscheidung kann sich auf den aufrufenden Prozess, die konfigurierte Zugangsdaten, die angeforderte Aktion und die gelieferten Argumente beziehen. Eine Person muss keinen undurchsichtigen curl-Befehl prüfen und daraus ableiten, welches gespeicherte Geheimnis downstream angehängt wird.

Sallyport verfolgt diesen Weg mit einer festen Entscheidungskette statt einer Richtliniensprache. Sein gesperrter Tresor verweigert jede Aktion. Ein neuer Agentenprozess benötigt standardmäßig eine Sitzungsautorisierung, wobei die Genehmigung die Codesignatur des Prozesses ausweist. Einzelne Zugangsdaten können außerdem bei jeder Verwendung eine Genehmigung verlangen. Diese Kontrollen sind bewusst grob, greifen aber ein, bevor die App die HTTP- oder SSH-Aktion ausführt.

Diese Methode hat eine wichtige Einschränkung: Ein festes Genehmigungsmodell kann nicht die bedingten Regeln jeder Organisation ausdrücken. Wenn du eine Regel wie «Erlaube Schreibvorgänge nur während eines Wartungsfensters, wenn ein Ticketfeld einen bestimmten Wert hat» brauchst, benötigst du ein System, das diese Regel auswerten und pflegen kann. Stelle ein einfaches Action-Gateway nicht als universelle Richtlinien-Engine dar.

Der Vorteil einer kleinen Kontrollmenge besteht darin, dass ein Betreiber sie vorhersehen kann. Der Tresor ist entweder gesperrt oder entsperrt. Ein Prozesslauf ist entweder genehmigt oder nicht. Eine Zugangsdaten verlangt entweder jedes Mal eine Genehmigung oder nicht. Sicherheitskontrollen versagen in der Praxis, wenn niemand erklären kann, warum ein Aufruf durchgelassen wurde.

Sichtbarkeit von Anfragen und Aktionsberechtigung sind getrennte Eigenschaften

Teams verlangen oft «vollständige Sichtbarkeit», obwohl sie eigentlich zwei verschiedene Dinge brauchen: einen Eintrag darüber, welcher Agent Arbeit angestoßen hat, und einen Eintrag über jede externe Aktion. Sichtbarkeit auf Paketebene kann beim Debugging helfen, ist aber kein guter Ersatz für einen Aktionsdatensatz.

Ein Proxy-Log kann Quelladresse, Ziel, TLS-Details, bei erfolgreicher Interception HTTP-Felder und rohe Bytes enthalten. Das ist nützliches forensisches Material. Es erzeugt aber auch ein schwieriges Identitätsproblem. Eine Verbindung zeigt nur dann, welcher Prozess verbunden war, wenn die Umgebung diese Identität liefert und bewahrt. Eine Anfrage zeigt, was den Proxy erreicht hat, nicht unbedingt, welche Modellanweisung oder Agentensitzung sie ausgelöst hat.

Ein Action-Gateway beginnt an der Grenze der Operation. Es kann den Agentenlauf aufzeichnen, der die Operation angefordert hat, und den einzelnen Aufruf, den es ausgeführt hat. Diese Datensätze beantworten unterschiedliche Fragen:

• Welcher autorisierte Agentenprozess hatte eine aktive Sitzung?
• Welche externe Aktion hat diese Sitzung angefordert?
• Welche Zugangsdaten oder welchen Kanal hat der Executor verwendet?
• Welches Ergebnis kam zurück oder woran ist der Aufruf gescheitert?

Verwechsle einen Audit-Trail nicht mit einem Zugriffskontrollsystem. Ein detailliertes Log verhindert nicht, dass ein Agent Daten löscht, wenn du diese Aktion freigegeben hast. Es kann spätere Änderungen erkennbar machen und die Untersuchung eines Vorfalls deutlich unabhängiger von der eigenen Datenbank des Dienstes machen.

Sallyport erzeugt seine Journale Sessions und Activity aus einem einzigen verschlüsselten, hashverketteten Audit-Log. Der Befehl sp audit verify prüft diese Kette offline über dem Chiffretext und benötigt keinen Tresorschlüssel. So wird die Prüfung von der Fähigkeit getrennt, Geheimnisse zu entschlüsseln. Das ist die richtige Aufteilung für einen Ermittler, der die Historie validieren, aber keinen Zugriff auf Zugangsdaten erhalten soll.

Ein konkreter Prüfablauf sollte eine Ausgabe erzeugen, die Menschen wiedererkennen. Zum Beispiel:

$ sp audit verify
Verifying audit chain...
Entries checked: 184
Chain status: valid

Die genaue Zahl ändert sich. Wichtig ist, dass ein veränderter, fehlender oder umsortierter Datensatz die Prüfung fehlschlagen lässt, statt unbemerkt eine kürzere Historie zu erzeugen. Bewahre eine Kopie der verschlüsselten Audit-Daten außerhalb des Rechners auf, der sie erstellt hat, wenn du dich gegen vollständiges Löschen schützen musst. Eine Hashkette erkennt Manipulationen an den Datensätzen, die du behältst. Sie kann nicht die Existenz von Dateien beweisen, die ein Angreifer zusammen mit dem Rechner zerstört hat.

HTTP und SSH zeigen unterschiedliche Grenzen der Vermittlung

HTTP wirkt einfach, weil es Header, URLs und Verben besitzt. Dieser Eindruck kann Teams dazu verleiten, jede Integration als Problem der Header-Injektion zu behandeln.

Bei einer HTTP-API mit Bearer-Token kann der Executor einen Zugangsdaten-Datensatz aufbewahren, der beschreibt, wie authentifiziert wird und wo die Zugangsdaten gelten. Fordert ein Agent eine Operation an, fügt der Executor den Bearer-Header selbst ein. Bei einem benutzerdefinierten Header-Schema fügt er den konfigurierten Header hinzu, ohne seinen Wert an den Agenten zurückzugeben. Basic Authentication folgt derselben Regel für die Verwahrung, allerdings muss der Executor Benutzername und Passwort als Geheimnisse und nicht als bequemen Konfigurationstext behandeln.

Das praktische Ergebnis ist eine Trennung der Eingaben. Der Agent darf Anfragedaten wie diese liefern:

{
  "method": "POST",
  "path": "/repos/acme/widget/deployments",
  "body": {
    "environment": "staging",
    "revision": "7d3c1a"
  }
}

Das sollte der Agent nicht liefern:

{
  "authorization": "Bearer token-value-goes-here"
}

Diese Trennung verhindert den häufigen Fehler, bei dem ein Tool-Schema ein Geheimnisfeld anbietet, das Modell einen Wert einträgt und dieser anschließend in Traces, im Terminalverlauf, in Test-Fixtures oder in kopiertem Konversationstext auftaucht. Ein Token als Tool-Argument zu behandeln ist ein Designfehler, selbst wenn die Oberfläche den Wert nach dem Aufruf verbirgt.

Auch die HTTP-Vermittlung braucht Grenzen. Akzeptiert das Gateway beliebige URLs, kann der Agent interne Dienste, Cloud-Metadaten-Endpunkte oder fremde Hosts über einen Pfad mit Zugangsdaten ansprechen. Akzeptiert es beliebige Header, kann der Agent Request-Smuggling versuchen oder die Authentifizierungssemantik überschreiben. Akzeptiert es beliebige Bodies, musst du akzeptieren, dass die API selbst zur Richtliniensprache wird.

SSH hat andere Grenzen. Eine Aktion muss möglicherweise einen Remote-Befehl ausführen, eine Datei kopieren oder einen Host abfragen. Das Gateway braucht ein Ziel und einen privaten Schlüssel, den es behält. Ein zustandsloser Helfer kann die SSH-Verbindung aufbauen und Standardausgabe, Standardfehler sowie Exit-Status zurückgeben, ohne den Schlüssel in die Umgebung des Agenten zu legen.

Die Befehlsgrenze ist entscheidend. Eine Anfrage wie:

host: build-host
command: git rev-parse HEAD

hat eine engere Prüfoberfläche als ein Agent, der eine lokale Shell mit Zugriff auf ~/.ssh, beliebigen Proxy-Einstellungen und einer uneingeschränkten Befehlszeile ausführt. Es bleibt ein authentifizierter Remote-Befehl. Kann die Zugangsdaten remote rm -rf ausführen, macht das Gateway ihn nicht sicherer, indem es den Transport verändert. Begrenze die Berechtigungen des Remote-Kontos und wähle Zugangsdaten für die Aufgaben, die es tatsächlich erledigt.

Ein Proxy kann SSH über einen TCP-Tunnel übertragen, aber den SSH-Befehl nicht einfach durch das Weiterleiten von Port 22 prüfen. Um Inhalte des SSH-Protokolls zu untersuchen, müsste er als SSH-Endpunkt fungieren und eine weitere SSH-Verbindung zum Upstream aufbauen, einschließlich aller daraus folgenden Anforderungen an Hostvertrauen, Authentifizierung, Aufzeichnung und Kompatibilität. Dass man dies Proxy nennt, verringert den technischen Aufwand nicht.

Ein Proxy bleibt nützlich, wenn er die richtige Ebene kontrolliert

Das Argument gegen einen MITM-Proxy als Action-Gateway für Agenten richtet sich nicht gegen Proxys. Proxys lösen mehrere Probleme gut, wenn sie auf der tatsächlich benötigten Ebene arbeiten.

Nutze einen Forward-Proxy oder ein Egress-Gateway, wenn du Netzwerke oder Hostnamen beschränken, Datenverkehr über einen bekannten Weg führen, den ausgehenden Zugriff gewöhnlicher Tools kontrollieren oder Verbindungsmetadaten sammeln musst. Diese Kontrollen können verhindern, dass ein Agent einen nicht genehmigten Host aufruft, selbst wenn er dein Aktionsmodell nicht versteht.

Nutze einen MITM-Proxy, wenn du die Clients besitzt, eine Vertrauens-CA verwalten kannst, Verhalten vieler herkömmlicher HTTP-Clients untersuchen oder durchsetzen musst und die Verantwortung für entschlüsselten Datenverkehr übernimmst. Sicherheitstestumgebungen und verwaltete Geräteflotten erfüllen diese Bedingungen häufig.

Nutze ein Action-Gateway, wenn die Anforderung an Identität und Berechtigung eines autonomen Agenten gebunden ist: Der Agent muss eine externe Aktion anfordern, darf die Zugangsdaten nicht besitzen und muss einen prüfbaren Eintrag über die vom Executor ausgeführte Aktion hinterlassen.

Viele ernsthafte Installationen kombinieren beides. Die Laufzeitumgebung des Agenten erhält einen eingeschränkten ausgehenden Zugriff und kann keine beliebigen direkten Aufrufe durchführen. Das Action-Gateway erhält den engen Netzwerkzugriff, den es für genehmigte externe Dienste benötigt. Das Gateway besitzt Zugangsdaten und Genehmigungen. Die Netzwerkschicht blockiert Umgehungswege.

Lege nicht alle Kontrollen in den Proxy, nur weil er bereits im Netzwerkpfad liegt. Dadurch landet die Autorisierung auf Anwendungsebene häufig in URL-Mustern und die Geheimnisverwaltung in einem Interception-Dienst, der eigentlich für die Weiterleitung von Datenverkehr gebaut wurde. Das ist beliebt, weil Bereitstellungsdiagramme übersichtlich aussehen. Die betriebliche Grenze wird dadurch schlechter.

Ein plausibles Proxy-Design scheitert bei der Übergabe

Nimm einen Coding-Agenten in einer Entwicklungsumgebung. Er muss einen Issue-Tracker abfragen, eine Bereitstellung erstellen und einen Build-Host über SSH untersuchen. Ein Team installiert einen HTTPS-Proxy und konfiguriert Variablen wie diese:

HTTPS_PROXY=http://proxy.internal:8080
HTTP_PROXY=http://proxy.internal:8080

Der Proxy fügt ein API-Token für den Issue-Tracker ein. Das Team hält das Token für geschützt, weil der Agent es nie aus einer Konfigurationsdatei liest.

Nun sendet der Agent eine Anfrage an einen administrativen Endpunkt auf demselben Host. Der Proxy sieht einen erlaubten Hostnamen und fügt dasselbe Token ein. Versteht die Regel die Semantik des Endpunkts nicht, hat sie dem Agenten gerade die vollständige Berechtigung des Tokens über eine indirekte Schnittstelle gegeben.

Das Team versucht, dies mit Pfad-Allowlists zu beheben. Bald braucht es Ausnahmen für Paginierung, Upload-Endpunkte für Anhänge, Weiterleitungen, alternative API-Versionen und einen Ablauf, der einen Schreibvorgang mit einem Lesevorgang verbindet. Der Proxy trägt nun eine Anwendungsrichtlinie, die sich bei jeder Änderung der Dienst-API ebenfalls ändert.

Währenddessen beachtet ein Tool HTTPS_PROXY nicht. Ein anderes nutzt einen privaten Zertifikatsspeicher und scheitert bei der TLS-Interception. Ein drittes läuft in einem Container mit einem anderen CA-Bundle. Jemand fügt eine Umgehung hinzu, damit die Arbeit weitergeht. Diese Umgehung erzeugt genau den Weg, den ein durch Prompt-Injection manipulierter Agent oder eine kompromittierte Abhängigkeit später wählen wird.

SSH kommt zuletzt und macht den Widerspruch sichtbar. Der Proxy kann den privaten SSH-Schlüssel nicht in einen Tunnel einfügen. Das Team bindet den Schlüssel «vorübergehend» in die Umgebung des Agenten ein oder startet einen Agentenprozess, der auf einen lokalen SSH-Agenten zugreifen kann. Damit hat das System die Eigenschaft verloren, die es bewahren wollte.

Ein Action-Execution-Design verändert diese Übergabe. Der Agent ruft ein MCP-Tool über eine lokale stdio-Verbindung auf. Der Executor besitzt API-Zugangsdaten oder SSH-Schlüssel, stellt die externe Verbindung her und gibt das Ergebnis zurück. MCP transportiert die Tool-Anfrage. Es gewährt dem Agenten keinen freien Zugang zu Geheimnissen. Die Spezifikation des Model Context Protocol definiert die Grenze der Tool-Interaktion. Die Verwahrung der Zugangsdaten bleibt jedoch Aufgabe der Implementierung.

Dieses Design beseitigt Prompt-Injection nicht. Eine schädliche Anweisung kann einen Agenten weiterhin dazu bringen, eine gefährliche Aktion anzufordern, zu der er berechtigt ist. Es begrenzt den Fehler auf die Berechtigungen, die das Gateway freigibt, bietet dem Betreiber einen Punkt zum Genehmigen oder Ablehnen und verhindert, dass jeder erfolgreiche Tool-Aufruf zu einer Gelegenheit wird, ein wiederverwendbares Geheimnis abzugreifen.

Wähle die Architektur anhand der Berechtigung, die du nicht übergeben willst

Beginne mit dem Satz, den du wahr machen musst. Lautet er «Der Prozess darf nur genehmigte Ziele erreichen», gehört eine Netzwerkkontrolle in den Pfad. Lautet er «Der Prozess darf diesen API-Schlüssel oder privaten SSH-Schlüssel niemals besitzen», muss ein anderer Prozess die authentifizierte Aktion ausführen. Lautet er «Ein Mensch muss jede Verwendung dieser Zugangsdaten genehmigen», muss die Genehmigung vor dem Aufruf des Remote-Dienstes durch den Executor liegen.

Prüfe die Aussage anschließend gegen Umgehungen. Kann der Agent eine Umgebungsvariable mit einem Token lesen? Hat er Zugriff auf eine Zugangsdaten-Datei, einen lokalen SSH-Agenten, eine Browsersitzung, einen Cloud-Metadaten-Dienst oder ein uneingeschränktes ausgehendes Netzwerk? Kann er ein generisches HTTP-Tool auffordern, mit derselben eingefügten Zugangsdaten einen anderen Pfad aufzurufen? Führt eine fehlschlagende TLS-Interception dazu, dass ein Betreiber die Zertifikatsvalidierung deaktiviert oder einen direkten Weg einrichtet?

Eine kurze Prüfung sollte vier Fragen beantworten:

1. Welcher Prozess hält welches Geheimnis im Speicher?
2. Welcher Prozess erstellt die authentifizierte Verbindung?
3. Wo kann ein Mensch den Aufruf ablehnen, bevor der Remote-Dienst ihn sieht?
4. Welcher Datensatz verbindet einen bestimmten Agentenlauf mit der abgeschlossenen Operation?

Lautet die Antwort auf die ersten beiden Fragen «der Agent», ändert keine Proxy-Regel das grundlegende Risiko. Lautet sie «der Proxy», musst du entscheiden, ob du TLS-Interception und Anwendungsrichtlinien betreiben willst. Lautet sie «ein Executor, der Zugangsdaten verwahrt», muss er eine enge Aktionsoberfläche besitzen und der Agent darf ihn nicht umgehen können.

Sallyport ist auf macOS für die letzte Anordnung gebaut: Sein sp mcp-Shim ermöglicht MCP-fähigen Agenten, HTTP- und SSH-Aktionen anzufordern, während die App die Geheimnisse behält und diese Aktionen ausführt. Es ist kein MITM-Proxy und sollte auch nicht als solcher dargestellt werden.

Die erste Implementierungsaufgabe ist meist unspektakulär: Entferne direkte Zugangsdaten aus der Laufzeitumgebung des Agenten. Solange das nicht geschehen ist, sind Genehmigungen und Verkehrsprotokolle nur Leitplanken um einen Prozess, der die Schlüssel weiterhin mit sich führt.