Proxy-Umgebungsvariablen: API-Datenverkehr von Agenten prüfen

Proxy-Umgebungsvariablen sind ausführbare Routing-Anweisungen und keine harmlosen Shell-Einstellungen. Wenn ein KI-Coding-Agent HTTP_PROXY, HTTPS_PROXY, ALL_PROXY oder NO_PROXY übernimmt, kann eine Anfrage, die wie ein direkter Aufruf einer internen API aussieht, einen anderen Netzwerkweg nehmen, bevor der Agent überhaupt nützliche Arbeit geleistet hat.

Ich habe erlebt, dass Teams tagelang Token-Berechtigungen und Endpunkt-Whitelists prüften und dann feststellten, dass der Agent-Runner einen lokalen Debugging-Proxy aus der Entwickler-Shell übernommen hatte. Die Zugangsdaten waren gültig, der API-Client verhielt sich genau wie konfiguriert, und der Datenverkehr lief trotzdem an einen Ort, den niemand vorgesehen hatte. Prüfe die Prozessumgebung, bevor du einem Agenten Zugriff auf interne Dienste gibst.

Proxy-Variablen ändern den Weg, nicht nur die Verbindungseinstellungen

Eine Proxy-Variable weist einen kooperierenden Client an, seine Anfrage an einen Vermittler zu übergeben. Bei normalem HTTP sendet der Client dem Vermittler häufig die vollständige Ziel-URL. Bei HTTPS bittet der Client den Proxy normalerweise, einen CONNECT-Tunnel zum Ziel-Host zu öffnen, und führt TLS anschließend durch diesen Tunnel aus.

Dieser Unterschied ist wichtig, weil ein Proxy Verfügbarkeit, Zielkontrolle, DNS-Verhalten und Beobachtbarkeit beeinflussen kann, selbst wenn er HTTPS nicht entschlüsseln kann. Ein Proxy kann eine Verbindung ablehnen, sie auf TCP-Ebene umleiten, den angeforderten Host und Port protokollieren oder zum einzigen Weg werden, über den ein Agent einen Dienst erreicht.

Behandle diese Variablen als Teil der ausgehenden Berechtigungen des Agenten:

• HTTP_PROXY und http_proxy wirken üblicherweise auf http://-URLs.
• HTTPS_PROXY und https_proxy wirken üblicherweise auf https://-URLs.
• ALL_PROXY und all_proxy dienen in Clients, die sie unterstützen, als Fallback.
• NO_PROXY und no_proxy nehmen Ziele üblicherweise vom Proxy aus.

Das Wort «üblicherweise» ist entscheidend. Umgebungsvariablen sind eine Konvention und kein Netzwerkstandard, den jede Laufzeitumgebung gleich implementiert. Ein Agent kann einen Kommandozeilen-Client aufrufen, eine HTTP-Bibliothek einer Sprache verwenden, einen Paketmanager starten oder einen Hilfsprozess ausführen. Jede dieser Ebenen kann eine eigene Proxy-Entscheidung treffen.

Auch eine nicht gesetzte Variable beweist keinen direkten Weg. Ein Client kann eine Konfigurationsdatei lesen, eine System-Proxy-Einstellung verwenden, eine PAC-Datei beachten oder ausdrücklich ein lokales Relay aufrufen. Dieser Artikel konzentriert sich auf Umgebungsvariablen, weil sie leicht vererbt werden, in einer umfangreichen Prozessumgebung schwer auffallen und oft als vorübergehend gelten, obwohl sie längst dauerhaft geworden sind.

Der Launcher bestimmt, was der Agent übernimmt

Ein Agent erhält nur Variablen, die in seiner eigenen Prozessumgebung existieren oder die ein übergeordneter Prozess an ihn weitergibt. Das Terminal, in dem du env geprüft hast, muss nichts mit dem Prozess zu tun haben, der den Agenten tatsächlich ausführt.

Unter macOS wird das besonders leicht übersehen. Ein Prozess, der aus einer interaktiven Shell gestartet wird, übernimmt deren exportierte Variablen. Eine grafische App, die über den Finder gestartet wird, oder ein Dienst, der über launchd läuft, folgt einem anderen Vererbungsweg. Eine IDE kann ihr integriertes Terminal mit einer Umgebung und ihren Extension-Host mit einer anderen starten. Ein gestern gestarteter Hintergrundagent kann einen alten Proxy-Wert behalten, lange nachdem die Shell-Variable verschwunden ist.

Bilde die Ausführungskette ab, bevor du Einstellungen änderst. Stelle vier konkrete Fragen:

1. Welcher Prozess startet den Agenten?
2. Startet der Agent Shells, Paketwerkzeuge, Test-Runner oder Remote-Hilfsprozesse?
3. Welche dieser Prozesse führen HTTP-Aufrufe aus?
4. Welcher Startpunkt liefert jeweils die Umgebungsvariable?

Akzeptiere «Der Agent läuft in meinem Terminal» nicht als Antwort, solange du den übergeordneten Prozess nicht identifizieren und den Lauf aus genau diesem Terminal reproduzieren kannst. Der Agent kann ein Kindprozess eines Editors, eines Task-Runners oder eines Automatisierungsdienstes sein, der eine gespeicherte Umgebung nutzt.

Eine von einem übergeordneten Prozess gesetzte Proxy-Variable erreicht jeden Kindprozess, sofern dieser sie nicht entfernt. Deshalb kann ein einzeiliger Shell-Export unbemerkt Aufrufe von Paketinstallationen, Versionskontroll-Helfern, Cloud-CLIs, Browser-Automatisierung und Test-Fixtures verändern. Die betroffene Anfrage muss nicht diejenige sein, an die du beim Start des Agenten gedacht hast.

Die Bedeutung von Proxy-Variablen unterscheidet sich je nach Client

Es gibt keine einheitliche Interpretation von HTTP_PROXY, HTTPS_PROXY und NO_PROXY. Jede Sicherheitsprüfung, die das Verhalten eines Clients auf einen anderen überträgt, bleibt unvollständig.

Die curl-Dokumentation beschreibt eine wichtige Ausnahme, die viele übersehen: curl akzeptiert für die HTTP-Proxy-Konfiguration nur http_proxy in Kleinschreibung. Laut Dokumentation verhindert das ein CGI-Problem, bei dem ein eingehender Proxy:-Header zu einer Umgebungsvariablen HTTP_PROXY werden kann. Für mehrere andere Proxy-Variablen akzeptiert curl auch Großschreibung, aber diese HTTP-Ausnahme ist beabsichtigt.

Go dokumentiert http.ProxyFromEnvironment als Funktion, die HTTP_PROXY, HTTPS_PROXY und NO_PROXY sowie kleingeschriebene Alternativen liest. Auch ihr Verhalten enthält einen CGI-Schutz: Enthält die CGI-Umgebung REQUEST_METHOD, verwendet Go HTTP_PROXY nicht, weil ein Request-Header die Variable geliefert haben könnte. Das bedeutet nicht, dass ein Go-Prozess sicher ist. HTTPS_PROXY, kleingeschriebene Varianten, explizite Transport-Einstellungen und Kontexte außerhalb von CGI müssen weiterhin geprüft werden.

Viele JavaScript-Anwendungen machen die Lage noch komplizierter. Die integrierten HTTP-APIs der Node.js-Laufzeit haben traditionell keine einheitliche Proxy-Regel für Umgebungsvariablen vorgegeben. Anwendungen und ihre Abhängigkeiten ergänzen die Proxy-Unterstützung oft selbst. Ein Befehl kann HTTPS_PROXY berücksichtigen, ein anderer Befehl im selben Agent-Lauf kann die Variable ignorieren, und ein dritter kann eine eigene Option lesen.

Erledige diese Prüfung nicht mit einer Tabelle voller Laufzeit-Gerüchte. Ermittle jede ausführbare Datei mit Netzwerkzugriff und teste sie. Halte die Version der ausführbaren Datei, ihren Aufruf, die Ziel-URL, die relevanten Variablen und die Frage fest, ob sie direkt oder über den vorgesehenen Proxy verbunden wurde. Bewahre das Ergebnis bei den Bereitstellungsnotizen des Agenten auf, denn ein Abhängigkeits-Update kann das Verhalten ändern.

Oft wird ein wichtiger Unterschied verwischt: Proxy-Bewusstsein ist nicht Proxy-Durchsetzung. Ein Client, der eine Proxy-Variable berücksichtigt, kann über diese Variable geroutet werden. Er kann trotzdem direkt verbinden, wenn die Variable fehlt, fehlerhaft ist, durch NO_PROXY umgangen wird oder von einem Hilfsprozess ignoriert wird. Wenn du direkten Datenverkehr verhindern musst, setze das an der Netzwerkgrenze durch, statt darauf zu hoffen, dass jede Bibliothek eine Umgebungsvariable liest.

NO_PROXY braucht für interne Namen eindeutige Tests

NO_PROXY ist eine Umgehungsliste. Eine fehlerhafte Liste kann internen Datenverkehr über einen Proxy senden oder Datenverkehr direkt senden, obwohl du eine Kontrolle durch den Proxy erwartet hast. Keine dieser Möglichkeiten darf einfach angenommen werden.

Die meisten Implementierungen akzeptieren durch Kommas getrennte Einträge. Darüber hinaus gehen die Details auseinander. Clients können registry.corp.example, .corp.example, corp.example, 10.20.0.0/16, 10.20.30.40, localhost und * unterschiedlich behandeln. Ein Suffix-Match, der in einem Client funktioniert, kann in einem anderen zu weit reichen oder vollständig scheitern. Auch Einträge mit Portangabe verhalten sich nicht einheitlich.

Vermeide breite Einträge, bis ein Test ihre Bedeutung bestätigt. Ein einfacher Domain-Suffix kann Hosts ausnehmen, die du nicht gemeint hast. Ein Sternchen kann Proxy-Nutzung viel umfassender abschalten, als ein Prüfer erwartet. CIDR-Unterstützung ist nützlich, wo sie vorhanden ist, aber keine portable Annahme. Exakte interne Hostnamen sind langweilig, und gerade das ist hier hilfreich.

Beginne mit einer kurzen Liste benannter Dienste, die sich direkt verbinden müssen, etwa einem internen Quellcode-Host, einer Artefakt-Registry und einem Service-Discovery-Endpunkt. Füge einen Domain-Suffix erst hinzu, nachdem du bestätigt hast, dass der Client ihn wie vorgesehen abgleicht und dass jeder Host unter diesem Suffix denselben Weg verwenden soll.

Trenne außerdem das Hostname-Matching von der Namensauflösung. Ein Client entscheidet häufig vor dem Verbindungsaufbau, ob NO_PROXY greift. Enthält deine Liste einen Hostnamen, kann der Abgleich erfolgreich sein, selbst wenn der Host zu einer Adresse außerhalb deines erwarteten Bereichs aufgelöst wird. Enthält deine Liste einen IP-Bereich, muss der Client den Namen möglicherweise zuerst auflösen, bevor er entscheiden kann. Die Implementierung bestimmt diese Reihenfolge.

Für einen Bypass-Test brauchst du ein Ziel, das du kontrollierst und in Logs identifizieren kannst. Verwende keine Produktions-API und leite den Erfolg nicht aus einer 200-Antwort ab. Ein interner Test-Endpunkt sollte die Remote-Adresse melden oder eine Request-ID in seinem Zugriffslog ausgeben. Vergleiche anschließend eine Anfrage mit vorhandenem Bypass-Eintrag mit einer Anfrage ohne diesen Eintrag. Du brauchst Belege für den Verbindungsweg und keine Vermutung anhand der Anwendungsausgabe.

HTTPS verbirgt Inhalte, aber ein Proxy erhält weiterhin wichtige Daten

Ein HTTPS-CONNECT-Tunnel schützt Request-Header und Inhalte normalerweise vor einem herkömmlichen Forward-Proxy. Der Proxy wird dadurch nicht irrelevant. Er sieht den Host und Port aus der CONNECT-Anfrage, den Zeitpunkt der Verbindung, Byte-Mengen und häufig auch die Quelladresse. Je nach Client und Netzwerk kann zugehöriger DNS-Verkehr weitere Informationen offenlegen.

Der Proxy kann entschlüsselte API-Zugangsdaten lesen, wenn der Client einer Zertifizierungsstelle vertraut, die der Proxy für TLS-Interception verwendet. Das kommt in manchen verwalteten Unternehmensnetzwerken und Debugging-Setups vor. Das Vorhandensein eines vertrauenswürdigen lokalen Root-Zertifikats ist eine Entscheidung über eine Sicherheitsgrenze und keine Komforteinstellung. Wenn ein Agent-Prozess diesem Root vertraut, kann ein Proxy-Betreiber den Datenverkehr zu jedem Host untersuchen, für den die Intercept-Regel gilt.

Klartext-HTTP ist schlimmer. Ein Forward-Proxy kann die vollständige URL und die Request-Header erhalten, einschließlich Bearer-Tokens oder Basic-Authentication. Erlaube einem Agenten nicht, authentifizierte interne APIs über unverschlüsseltes HTTP zu verwenden, nur weil «das Netzwerk privat ist». Proxy-Umgebungsvariablen sind eine von mehreren Möglichkeiten, wie Annahmen über private Netzwerke falsch werden.

Ein weniger offensichtlicher Fehler betrifft eine Proxy-URL mit eingebetteten Zugangsdaten, etwa http://user:[email protected]:8080. Dieser Wert kann in Diagnoseausgaben, Absturzberichten, der Shell-History, der Prozessinspektion oder Logs auftauchen, die die Umgebung aufzeichnen. Proxy-Authentifizierung sollte einen für deine Umgebung geeigneten verwalteten Mechanismus verwenden. Bei einer Sicherheitsprüfung müssen Proxy-Zugangsdaten als eigene Geheimnisse behandelt werden.

Wenn du den Betreiber des Proxys, seine Listener-Adresse und die Möglichkeit einer TLS-Interception nicht identifizieren kannst, leite keine privilegierten Agent-Anfragen über ihn. Das ist keine Paranoia. Der Proxy ist bereits Teil des Wegs zwischen einem automatisierten Prozess und einem sensiblen Dienst.

Prüfe den laufenden Prozess, ohne seine Geheimnisse vollständig auszugeben

Beginne mit einer Bestandsaufnahme, die Variablennamen und Proxy-Endpunkte meldet, aber keine umfassende Umgebungsdatei ausgibt. Führe in einer Shell, aus der der Agent gestartet werden könnte, Folgendes aus:

env | grep -Ei '(^|_)(http|https|all|no)_proxy='

Die Ausgabe sollte ungefähr so aussehen:

HTTPS_PROXY=http://127.0.0.1:8888
NO_PROXY=localhost,127.0.0.1,registry.corp.example

Wenn die Proxy-URL Benutzerinformationen enthält, füge die unveränderte Ausgabe nicht in ein Ticket ein. Halte Schema, Host und Port fest, nachdem du die Zugangsdaten entfernt hast. Eine Loopback-Adresse ist nicht automatisch sicher. Lokale Proxys gehören oft zu legitimen Debugging-Tools, aber auch Schadsoftware und unerwünschte Programme können auf Loopback lauschen. Prüfe, welcher Prozess den Listening-Port besitzt.

Unter macOS kannst du einen Listener so untersuchen:

lsof -nP -iTCP:8888 -sTCP:LISTEN

Ein normales Ergebnis nennt einen Befehl und eine Prozess-ID. Wenn kein erwarteter Prozess den Port besitzt, halte an und untersuche die Ursache. Leite Zugangsdaten nicht an einen Listener, nur weil seine Adresse mit 127.0.0.1 beginnt.

Untersuche als Nächstes den tatsächlichen Agent-Prozess. ps kann unter macOS die Prozessumgebung anzeigen, dabei aber auch andere Geheimnisse offenlegen. Beschränke den Zugriff auf den Gerätebesitzer oder einen Administrator, sammle nur die benötigten Informationen und füge das Ergebnis nicht in einen Chat oder ein gemeinsames Log ein.

ps eww -p "$AGENT_PID" | tr ' ' '\n' | grep -Ei '(^|_)(http|https|all|no)_proxy='

Setze AGENT_PID auf die Prozess-ID des laufenden Agenten. Dieser Befehl kann weiterhin sensible Proxy-Zugangsdaten ausgeben, falls solche vorhanden sind. Verwende ihn daher in einem vertrauenswürdigen Terminal und bereinige die Ausgabe, bevor du Belege speicherst. Wenn sich die Ausgabe von deiner Shell-Bestandsaufnahme unterscheidet, hat der übergeordnete Prozess Variablen hinzugefügt oder entfernt.

Bei Prozessen, die von launchd gestartet werden, untersuche die Job-Definition und den Launcher, statt dich auf dein Terminal zu verlassen. launchctl getenv HTTPS_PROXY kann eine Variable in der aktuellen launchd-Domain anzeigen. Ihr Fehlen entlastet jedoch keinen bestimmten Job. Ein Job kann seine eigene Umgebung definieren, und ein Wrapper-Skript kann Variablen unmittelbar vor dem Start des Agenten exportieren.

Belege den Weg mit einer harmlosen Anfrage

Eine Konfigurationsprüfung zeigt, was passieren sollte. Eine kontrollierte Anfrage zeigt, was passiert ist. Du brauchst beides.

Erstelle oder verwende einen nicht sensiblen Endpunkt, der die Peer-Adresse und den Request-Pfad protokolliert. Sende anschließend eine Anfrage mit ausführlicher Verbindungsdiagnose. curl eignet sich, weil die Ausgabe zeigt, ob eine Verbindung zum Proxy aufgebaut und ob eine CONNECT-Anfrage gesendet wird.

HTTPS_PROXY=http://127.0.0.1:8888 \\
NO_PROXY= \\
curl -v --connect-timeout 5 https://probe.corp.example/agent-proxy-check

Wenn curl den Proxy für HTTPS verwendet, enthält die ausführliche Ausgabe normalerweise Zeilen wie diese:

* Uses proxy env variable HTTPS_PROXY == 'http://127.0.0.1:8888'
* Establish HTTP proxy tunnel to probe.corp.example:443
> CONNECT probe.corp.example:443 HTTP/1.1

Führe anschließend bewusst den direkten Vergleich aus:

HTTPS_PROXY=http://127.0.0.1:8888 \\
NO_PROXY=probe.corp.example \\
curl -v --connect-timeout 5 https://probe.corp.example/agent-proxy-check

Ein direkter Lauf sollte eine Verbindung zum Ziel zeigen und keine CONNECT-Anfrage an den Proxy. Bestätige das Ergebnis in den Server-Logs des Test-Endpunkts. Wenn curl meldet, dass der Proxy umgangen wurde, der Server aber eine unerwartete Quelle sieht oder die Anfrage scheitert, untersuche DNS, Routing und einen möglichen transparenten Netzwerk-Proxy getrennt.

Damit ist curl geprüft, nicht dein Agent. Wiederhole den Test über den exakten Ausführungsweg des Agenten. Wenn er ein Skript aufruft, führe dieses Skript aus. Wenn er eine Abhängigkeit für einen API-Aufruf verwendet, füge über dieselbe Konfiguration vorübergehend eine Test-URL hinzu. Wenn er einen Hilfsprozess startet, sammle Belege für dessen Weg. Ein Test mit einem anderen Client ist nur ein Hinweis.

Verwende für diese Aufgabe keinen öffentlichen «What is my IP»-Dienst. Dadurch wird eine interne Routing-Prüfung zu einer unnötigen externen Datenpreisgabe, und der Dienst kann nicht zeigen, welche interne Proxy-Regel angewendet wurde.

Saubere Startumgebungen sind besser als dauerhafte Shell-Exports

Lege Unternehmens-Proxy-Exports nicht in ein universelles Shell-Profil und erwarte dann, dass autonome Werkzeuge sichere Ausnahmen bilden. Globale Exports sind beliebt, weil sie einen blockierten Befehl einmal zum Funktionieren bringen. Sie werden aber auch an jeden Kindprozess weitergegeben, dessen Existenz du später vergisst.

Verwende einen ausdrücklichen Launcher für den Agenten. Starte mit einer bekannten Umgebung, übergib nur die Variablen, die der Lauf benötigt, und mache die Proxy-Nutzung im Startbefehl oder Wrapper sichtbar. In einer Unix-Shell löscht env -i geerbte Variablen. Deshalb musst du die für das Programm erforderlichen Grundlagen wiederherstellen:

env -i \\
PATH="$PATH" \\
HOME="$HOME" \\
LANG="${LANG:-en_US.UTF-8}" \\
NO_PROXY="localhost,127.0.0.1,registry.corp.example" \\
agent-command

Dieses Beispiel setzt absichtlich keinen Proxy. Wenn der Agent einen benötigt, füge die Proxy-Variable erst im Launcher hinzu, nachdem du ihren Besitzer ermittelt und ihr Verhalten getestet hast. Übernimm keinen Proxy-Wert aus einem Shell-Profil in ein Skript, ohne zu prüfen, ob er Zugangsdaten enthält oder auf einen veralteten lokalen Dienst zeigt.

Eine saubere Umgebung kann Werkzeuge beschädigen, die sich auf Variablen wie Zertifikatspfade, Cloud-Profile, SSH-Agent-Sockets oder Paket-Caches verlassen. Diese Störung liefert nützliche Informationen. Füge die benötigten Variablen einzeln wieder hinzu und dokumentiere den Grund für jede Variable. Ein Agent-Launcher sollte so eng gefasst sein, dass ein anderer Ingenieur ihn lesen und verstehen kann, wohin seine Anfragen gehen.

Netzwerkkontrollen müssen das absichern. Wenn ein Agent nur wenige interne Dienste erreichen darf, verwende Firewall-Regeln, einen Egress-Proxy mit erzwungener Richtlinie oder ein für deine Umgebung geeignetes eigenes Netzwerksegment. Umgebungsvariablen wählen für kooperative Clients einen Weg. Sie hindern einen kompromittierten Prozess oder eine nicht konforme Bibliothek nicht daran, eine direkte Socket-Verbindung zu öffnen.

Halte Zugangsdaten aus dem Prozess heraus, der den Weg auswählt

Eine saubere Proxy-Konfiguration verringert versehentliches Umrouten. Trotzdem ist es nicht sinnvoll, einem autonomen Agenten API-Tokens zu übergeben. Wenn die Agent-Umgebung ein Bearer-Token enthält, wird jeder Prozess mit Zugriff auf diese Umgebung Teil des Offenlegungswegs dieses Geheimnisses.

Sallyport setzt eine andere Grenze: Der Agent fordert eine HTTP- oder SSH-Aktion über seinen MCP-Shim an, während die Zugangsdaten im verschlüsselten Tresor der App bleiben und die App die Aktion ausführt. Dadurch ist weniger gefährdet, wenn im Agent-Prozess eine Proxy-Variable nach außen gelangt, denn der Agent erhält die API- oder SSH-Zugangsdaten nie im Klartext.

Übertreibe diese Grenze nicht. Ein Zugangsdaten-Gateway definiert nicht automatisch ein sicheres Proxy-Verhalten für jeden Befehl, den der Agent ausführt, und es macht ein schädliches Ziel nicht ungefährlich. Du musst weiterhin kontrollieren, welche Ziele und Aktionen erlaubt sind, den Anwendungsprozess prüfen, der den Netzwerkaufruf ausführt, und Belege für den Anfrageweg bewahren.

Die sinnvolle Trennung besteht zwischen Geheimnisverwaltung und Netzwerk-Routing. Die Geheimnisverwaltung beantwortet die Frage, wer die Zugangsdaten lesen kann. Das Netzwerk-Routing beantwortet, welcher Vermittler die Anfrage verarbeitet. Teams lösen oft eines dieser Probleme und nehmen an, beide gelöst zu haben. Das stimmt nicht.

Behandle ungeklärte Proxy-Nutzung als eingedämmten Vorfall

Wenn ein privilegierter Agent Anfragen über einen unbekannten Proxy ausgeführt hat, stoppe den Lauf, bevor du aus derselben verunreinigten Umgebung heraus ermittelst. Notiere die Prozess-ID des Agenten, seinen übergeordneten Prozess, die Proxy-Adresse, die betroffenen Zielnamen und das Zeitfenster. Sichere relevante Agent- und Proxy-Logs nach deinem Incident-Prozess.

Entferne anschließend die Variable an ihrer Quelle. Das Löschen in deinem aktuellen Terminal behebt nur künftige Kindprozesse dieses Terminals. Prüfe Shell-Profile, IDE-Task-Einstellungen, Launch-Agents, CI-Konfigurationen, Wrapper-Skripte und jede Konfigurationsverwaltung, die Umgebungseinstellungen schreibt. Starte den betroffenen Prozess nach der Korrektur des Startpunkts neu.

Bewerte Zugangsdaten nach Protokoll. Wenn der betroffene Datenverkehr authentifiziertes Klartext-HTTP war, rotiere die offengelegte Zugangsdaten. Wenn HTTPS über einen Proxy lief, ermittle, ob der Endpunkt normales TLS validiert hat und ob der Agent einem Interception-Zertifikat vertraute. Gehe nicht davon aus, dass HTTPS keine Prüfung erfordert, und rotiere Zugangsdaten nicht blind, während du den gleichen Injektionsweg bestehen lässt.

Füge schließlich am Start des Agenten eine Preflight-Prüfung hinzu. Beende den Lauf oder verlange eine ausdrückliche Prüfung, wenn eine unerwartete Proxy-Variable auftaucht. Die Prüfung sollte den Variablennamen und den bereinigten Endpunkt melden, ihn mit dem genehmigten Weg für diesen Job vergleichen und festhalten, dass die Preflight-Prüfung ausgeführt wurde. Der erste ungeklärte Proxy ist eine Warnung. Der zweite ist ein Bereitstellungsfehler, den du bewusst beibehalten hast.