Isolierung von Zugangsdaten in HTTP-Verbindungspools für KI-Agents

Eine wiederverwendete HTTP-Verbindung ist nicht automatisch ein Leck von Zugangsdaten. Wer sie für harmlos hält, übersieht leicht den eigentlichen Fehler: Ein Client-Objekt sammelt Cookies, Challenge-Antworten, Redirect-Header, Proxy-Identität oder TLS-Identität an. Eine spätere Anfrage übernimmt dann diesen Zustand mit einer anderen Anmeldeinformation.

Bei der Isolierung von Zugangsdaten in HTTP-Verbindungspools legen Sie genau fest, welcher Zustand zwischen Anfragen wechseln darf, und verhindern, dass der Rest geteilt wird. Der Ziel-Host allein ist für einen Action Runner oder einen Agent, der für mehrere Konten handeln kann, meist eine zu breite Grenze. Ein schneller Client, der gelegentlich das Cookie des falschen Kontos sendet, ist schlimmer als ein langsamerer Client, denn der Fehler sieht wie eine normale erfolgreiche Anfrage aus.

Ein Socket ist Transport, kein Kontobesitz

Eine TCP-Verbindung transportiert Bytes für eine Origin. Sie bildet keine verlässliche Kontogrenze für eine Anwendung. HTTP/1.1 verwendet die Verbindung nacheinander wieder, HTTP/2 kann viele Streams gleichzeitig ausführen. Keines der beiden Protokolle sagt jedoch, dass jede Anfrage auf einer Verbindung zum selben Nutzer- oder Dienstkonto gehört.

Dieser Unterschied ist wichtig, weil Client-Bibliotheken oft unabhängige Aufgaben hinter einer angenehm einfachen Oberfläche namens Session, Agent, Client oder Transport verbergen. Entwickler erstellen dann eines dieser Objekte pro Host und fügen vor jedem Aufruf ein Bearer-Token ein. Der Bearer-Header kann jedes Mal korrekt sein, während ein Cookie-Speicher, ein Digest-Challenge-Cache oder ein Proxy-Kontext unbemerkt zum letzten Konto gehört, das das Objekt genutzt hat.

RFC 9110 behandelt Authentifizierung als Verhalten einer Anfrage und eines Schutzbereichs. Ein Client antwortet auf eine Challenge für eine bestimmte Origin, ein Schema und einen Realm. Der Standard sagt nicht, dass eine offene Verbindung einer Person oder einem Dienstkonto gehört. Wenn Ihr Client diese Besitzannahme trifft, stammt sie aus Ihrem Code oder seiner Bibliothek, nicht aus HTTP.

Die Wiederverwendung von Verbindungen bleibt sinnvoll. Sie vermeidet wiederholte Handshakes, verringert die Port-Fluktuation und entlastet einen Remote-Dienst unter Last. Die passende Regel ist enger gefasst: Verwenden Sie eine Verbindung nur für Anfragen wieder, deren verbindungsbezogener und clientverwalteter Zustand absichtlich kompatibel ist.

Die Zustände, die Sie trennen sollten, lassen sich in zwei Gruppen einteilen:

• Zum Anfragestatus gehören Authorization, Cookie, Konten-Header, Request-Bodies und Idempotenzwerte. Der Aufrufer muss sie für jede Aktion neu erstellen.
• Zum Verbindungs- und Clientstatus gehören ein Pool-Eintrag, eine Proxy-Session, die Auswahl eines Client-Zertifikats, Redirect-Verhalten, Cookies, Challenge-Caches und Protokolleinstellungen. Der Client muss jeden dieser Punkte bewusst begrenzen oder deaktivieren.

Eine Bearer-Anmeldeinformation, die nur in einem Authorization-Header verwendet wird, kann eine TCP-Verbindung mit einer anderen Bearer-Anmeldeinformation teilen, wenn die Bibliothek Header pro Anfrage sendet und keinen Kontozustand behält. Das ist eine eingeschränkte Aussage, keine pauschale Freigabe. Sobald der Dienst zusätzlich ein Sitzungs-Cookie setzt, auf einen anderen Host umleitet oder nach einem Client-Zertifikat fragt, muss das Pool-Design erneut geprüft werden.

Cookies sind Kontozustand, auch wenn ihre Namen harmlos wirken

Ein Cookie-Speicher ist die häufigste Quelle unbeabsichtigter Kontoüberschneidungen. Teams sehen eine Bearer-Token-API und halten Cookies für irrelevant, bis ein Load Balancer, ein interaktiver Login-Endpunkt oder ein Altsystem einer Antwort Set-Cookie hinzufügt. Ein allgemeiner HTTP-Client speichert es normalerweise, sofern Sie ihm nichts anderes sagen.

RFC 6265 legt fest, wie ein User Agent Cookies anhand von Domain, Pfad, Sicherheitsattributen und verwandten Regeln auswählt. Sein Speichermodell enthält kein Feld für „den Zugangsdaten-Datensatz, der dieses Cookie erhalten hat“. Zwei Bearer-Anmeldeinformationen, die denselben Host und Pfad aufrufen, können daher für dasselbe gespeicherte Cookie infrage kommen. Das Protokoll befolgt seine Regeln einwandfrei, während Ihre Anwendung Konten vermischt.

Betrachten Sie diesen Trace eines Testdienstes. Konto alpha nutzt ein Bearer-Token und erhält ein Affinitäts-Cookie:

GET /v1/whoami HTTP/1.1
Host: api.example.test
Authorization: Bearer alpha-token

HTTP/1.1 200 OK
Set-Cookie: route=alpha-node; Path=/; Secure; HttpOnly
Content-Type: application/json

{"account":"alpha"}

Die nächste Aktion wählt beta. Sendet ein geteilter Speicher das abgelegte Cookie, enthält die Anfrage zwei Eigentumssignale:

GET /v1/whoami HTTP/1.1
Host: api.example.test
Authorization: Bearer beta-token
Cookie: route=alpha-node

Am besten lehnt der Dienst diesen Widerspruch ab. Weniger sorgfältige Dienste leiten betas Anfrage über die Sticky Session von alpha, verknüpfen sie mit dem falschen serverseitigen Kontext oder akzeptieren den Header, der gerade Vorrang hat. Der Client darf sich nicht darauf verlassen, dass der Remote-Dienst eine vermischte Anfrage rettet.

Für Machine-to-Machine-APIs lautet meine Standardempfehlung schlicht: Deaktivieren Sie das automatische Speichern von Cookies. Wenn eine API wirklich Cookies benötigt, erstellen Sie einen Cookie-Speicher für genau einen Zugangsdaten-Datensatz und einen vorgesehenen Dienstkontext. Teilen Sie ihn nicht, nur weil der Host-String übereinstimmt.

Prüfen Sie außerdem Eingaben der Anfrage, bevor Sie Zugangsdaten einfügen. Ein Agent, Plugin oder Aufrufer darf keinen eigenen Cookie-Header liefern können, der in einen Aufruf mit Zugangsdaten gelangt. Entfernen Sie automatisch übernommene Authentifizierungs-Header und Cookies und fügen Sie dann nur die Header hinzu, die die Aktionsdefinition erlaubt. Sonst bauen Sie eine Isolierung um eine Tür, die Aufrufer umgehen können.

Authentifizierungs-Challenges brauchen einen aktuellen Aufrufer

Eine 401-Antwort ist mehr als ein Fehlercode. Sie kann den Client auffordern, nach Auswahl von Zugangsdaten einen erneuten Versuch zu starten. Diese Auswahllogik liegt oft außerhalb des Codes, der die ursprüngliche Anfrage erstellt hat. Handler für Basic- und Digest-Authentifizierung sind besonders anfällig dafür, doch auch benutzerdefinierte Middleware kann bei Bearer-Tokens denselben Fehler machen.

Eine fehlerhafte Implementierung hält ein veränderliches currentCredential auf einem geteilten Client. Anfrage A erhält eine Challenge, der Handler lädt das Geheimnis von alpha und der Client versucht es erneut. Anfrage B startet, bevor dieser Wiederholungsversuch abgeschlossen ist, und ändert currentCredential zu beta. Jetzt enthält der Challenge-Handler eine Race Condition, die Test-Suites übersehen, weil sie Anfragen einzeln ausführen.

Beheben Sie das nicht mit einem Lock um ein globales Feld für Zugangsdaten. Der Lock serialisiert die Arbeit, lässt aber weiterhin das falsche Objekt für die Identität zuständig sein. Binden Sie den Zugangsdaten-Datensatz an den Anfragekontext, führen Sie ihn durch jeden Wiederholungsversuch mit und lehnen Sie einen Retry ab, wenn sein Kontext fehlt.

Digest-Authentifizierung verdient besondere Skepsis. Sie umfasst Nonces, Realms, Zähler und eine berechnete Antwort. Diese Werte gehören zum angeforderten Schutzbereich, nicht zu einem allgemein geteilten Client. Basic-Authentifizierung ist auf dem Übertragungsweg einfacher, doch auch ein Cache, der sie automatisch späteren Anfragen hinzufügt, braucht dieselbe Begrenzung auf Zugangsdaten.

Nutzen Sie einen Test-Endpunkt, der für jedes Konto einen eigenen Realm oder eine eigene Challenge zurückgibt. Führen Sie dann parallele Anfragen aus und prüfen Sie, ob jeder Wiederholungsversuch den Zugangsdaten-Datensatz nutzt, der an seine Aktion gebunden ist. Ein Test, der nur den abschließenden Status 200 prüft, ist zu schwach. Erfassen Sie die Anfrageidentität auf dem Server und lassen Sie den Test fehlschlagen, wenn eine Challenge von alpha zu einem Autorisierungsversuch mit beta führt.

Verwechseln Sie eine 403-Antwort nicht mit einer Challenge. Server nutzen 403 für viele Autorisierungsentscheidungen, und Clients sollten sie nicht als Erlaubnis verstehen, nach einer anderen Anmeldeinformation zu suchen. Ein automatischer Wechsel zwischen Zugangsdaten macht aus einem Zugriffsfehler das Ausprobieren von Konten. Das ist unsicher und schwer zu auditieren.

HTTP/2 macht Fehler bei der Eigentumszuordnung leichter unsichtbar

HTTP/2 erlaubt mehreren Streams, eine TLS-Verbindung zu teilen. Das ist effizient, nimmt aber den alten sichtbaren Hinweis weg, dass eine Anfrage hinter der anderen wartet. Ein Client kann Aktionen für alpha und beta im selben Moment senden. Ihre Header bleiben nur getrennt, wenn die Bibliothek sie bis ganz unten als getrennte Anfragen modelliert.

RFC 9113 verbietet verbindungsspezifische Header-Felder aus HTTP/1.1 wie Connection in HTTP/2-Anfragen. Diese Regel macht Cookies oder Authentifizierung nicht kontogebunden. Sie verhindert nur, dass eine Klasse von Hop-Verhalten als gewöhnliche Request-Header ausgedrückt wird. Ihr Client ist weiterhin für Cookie-Auswahl, Retry-Auswahl, Redirects und jede geteilte Middleware zuständig.

HTTP/2 Connection Coalescing bringt eine weitere Besonderheit mit sich. Manche Clients können eine sichere Verbindung für mehr als eine Origin nutzen, wenn Zertifikat- und Namensprüfungen dies erlauben. Coalescing spielt einen Authorization-Header nicht von selbst erneut ab. Es bedeutet jedoch, dass eine Pool-Identität auf Basis eines oberflächlichen Host-Vergleichs möglicherweise nicht die Verbindung beschreibt, die der Client tatsächlich gewählt hat. Halten Sie Origin-Autorisierungsentscheidungen von Transportoptimierungen getrennt und testen Sie das Verhalten der eingesetzten Bibliothek.

Auch Header-Komprimierung beunruhigt Menschen oft aus dem falschen Grund. HPACK komprimiert Header innerhalb einer HTTP/2-Verbindung, QPACK erledigt Vergleichbares für HTTP/3. Ein konformer Client dekodiert keinen Authorization-Wert einer vorherigen Anfrage in eine spätere Anfrage. Die Gefahr liegt in der direkten Wiederverwendung von Zustand in Ihrem Client-Code sowie möglichen Metadatenrisiken in ungewöhnlichen Bedrohungsmodellen. Markieren Sie sensible Header als nie zu indexieren, wenn Ihre Bibliothek das unterstützt. Halten Sie das aber nicht für einen Ersatz der Anfrageisolierung.

HTTP/3 ändert den Transport von TCP zu QUIC. Die Eigentumsregel ändert sich dadurch nicht. Ein Pool, der einen Cookie-Speicher oder Zugangsdaten-Cache frei zwischen Aktionen wandern lässt, bleibt auch über QUIC falsch.

Client-Zertifikate sind anders. Ein TLS-Client-Zertifikat wird beim Aufbau der Verbindung ausgewählt und ist daher tatsächlich verbindungsgebunden. Multiplexen Sie niemals unterschiedliche Identitäten von Client-Zertifikaten über dieselbe Verbindung oder denselben Pool-Eintrag. Nehmen Sie den Zertifikats-Datensatz in die Pool-Identität auf oder geben Sie jedem Zertifikat eine eigene Client-Instanz. Dieselbe Vorsicht gilt für einen Proxy, der eine Verbindung authentifiziert, bevor er Anfragen weiterleitet.

Die Pool-Identität im Code ausdrücklich festlegen

Die Pool-Identität sollte jeden Wert enthalten, der verändert, was eine neue Verbindung sicher bedeuten kann. Für eine reine Bearer-API mit deaktivierten Cookies und ohne Proxy-Identität kann das die Origin plus die Kennung eines Zugangsdaten-Datensatzes sein. Bei einem Client-Zertifikat, einem per Proxy authentifizierten Pfad oder einem besonderen TLS-Profil nehmen Sie diese Kennungen ebenfalls auf.

Verwenden Sie nicht den Text des Geheimnisses als Map-Kennung. Das erzeugt unnötige Kopien von Geheimnissen im Speicher und in Logs, erschwert die Rotation und verleitet dazu, die Map beim Debuggen auszugeben. Verwenden Sie eine undurchsichtige Kennung für den Zugangsdaten-Datensatz, deren Lebensdauer Ihr Vault oder Aktionsregister steuert.

Diese TypeScript-Skizze zeigt die Form. Sie nutzt Undicis Pool, die Grenze gilt aber für jede Client-Bibliothek. Die credentialId ist eine Kennung, nicht der Bearer-Wert.

import { Pool } from "undici";

type Boundary = {
  origin: string;
  credentialId: string;
  proxyId?: string;
  clientCertificateId?: string;
};

const pools = new Map<string, Pool>();

function poolId(boundary: Boundary): string {
  return [
    boundary.origin,
    boundary.credentialId,
    boundary.proxyId ?? "direct",
    boundary.clientCertificateId ?? "none"
  ].join("\u001f");
}

function poolFor(boundary: Boundary): Pool {
  const id = poolId(boundary);
  let pool = pools.get(id);
  if (!pool) {
    pool = new Pool(boundary.origin);
    pools.set(id, pool);
  }
  return pool;
}

function headersFor(token: string, input: HeadersInit = {}): Headers {
  const headers = new Headers(input);
  headers.delete("authorization");
  headers.delete("cookie");
  headers.delete("proxy-authorization");
  headers.set("authorization", `Bearer ${token}`);
  return headers;
}

Die Skizze verhindert, dass ein vom Aufrufer gelieferter Authorization- oder Cookie-Header zusammen mit der eingefügten Anmeldeinformation mitläuft. Sie implementiert keinen Cookie-Speicher, keine Redirects, keinen Proxy-Versand und keine Zertifikatskonfiguration. Das ist Absicht: Für jeden dieser Punkte braucht es eine bewusste Entscheidung statt eines zufälligen Standards.

Wenn jede Anmeldeinformation mit demselben anonymen öffentlichen Endpunkt kommuniziert, können getrennte Pools unnötig sein. Erkennt der Endpunkt unterschiedliche Konten, nutzen Sie getrennte Pool-Einträge, bis Sie einen konkreten Grund und Belege für eine gemeinsame Nutzung haben. Ein Pool ist günstig im Vergleich zu einer Kontoverwechslung.

Auch für die Rotation braucht es eine eigene Regel. Wenn sich ein Zugangsdaten-Datensatz ändert, weisen Sie neuen Aktionen nicht mehr seinen alten Pool zu. Lassen Sie bereits gesendete Anfragen unter ihrem ursprünglichen Datensatz enden, sofern Ihre Aktionssemantik dies erlaubt, und schließen Sie anschließend den Pool. Eine Rotation verändert Berechtigungen. Sie korrigiert nicht die Bedeutung bereits begonnener Arbeit.

Eine verbreitete Empfehlung lautet, Keep-Alive überall zu deaktivieren. Dadurch gibt es weniger geteilte Transportobjekte, was sich nach einem Vorfall sicher anfühlt. Zugleich verdeckt es, ob Cookies, Redirect-Code und Challenge-Caches richtig abgegrenzt sind, und erzeugt für jede Anfrage neue Handshake-Last. Behalten Sie Pooling bei, machen Sie seine Eigentumsgrenzen ausdrücklich und testen Sie die schwierigen Pfade.

Redirects können eine saubere Anfrage an den falschen Ort senden

Die Redirect-Verarbeitung ist ein zweiter Client, der im ersten verborgen ist. Eine Bibliothek erhält eine Antwort mit 301, 302, 303, 307 oder 308, erstellt eine weitere Anfrage und entscheidet, welche Header erhalten bleiben. Fällt diese Entscheidung nach Ihrem Code für die Zugangsdaten-Grenze, kann sie einen Konten-Header oder ein Cookie an ein unbeabsichtigtes Ziel tragen.

Bei Aktionen mit eingefügten Zugangsdaten sollten Redirects zunächst deaktiviert sein oder manuell behandelt werden. Prüfen Sie die Ziel-Origin, bevor Sie einem Redirect folgen. Erlauben Sie Redirects nur, wenn die Aktionsdefinition sie erwartet, das Ziel in ihrer genehmigten Origin-Menge liegt und der Client Header aus dem ursprünglichen Zugangsdaten-Kontext neu erstellt, statt eine alte Header-Sammlung zu kopieren.

Der Statuscode ist wichtig. Ein 303 kann eine Anfrage im üblichen Browserverhalten in GET ändern, während 307 und 308 Methode und Body beibehalten. Ein Client mit Wiederholungsversuchen, der sie alle gleich behandelt, kann einen Zugriff mit Zugangsdaten an einem anderen Endpunkt wiederholen. Das ist ein Problem der Aktionsintegrität, auch wenn kein Geheimnis eine Origin verlässt.

Entfernen Sie Authorization- und Cookie-Header bei jedem Origin-übergreifenden Redirect. Bei vielen Clients ist das bereits der Standard, doch ein Standard ist kein Testergebnis. Prüfen Sie die verwendete Version und Konfiguration. Auch Redirects innerhalb derselben Origin brauchen eine Pfad-Allowlist, wenn eine Anmeldeinformation weitergehende Berechtigungen verleiht, als der ursprüngliche Endpunkt erhalten sollte.

Für Proxy-Authentifizierung gilt dasselbe. Proxy-Authorization gehört zum gewählten Proxy-Pfad, nicht zum Origin-Dienst. Legen Sie ihn niemals in einer allgemeinen Map für Standard-Header ab. Erreichen zwei Aktionen dieselbe API über unterschiedliche authentifizierte Proxys, trennen Sie ihre Pool-Einträge und machen Sie die Proxy-Auswahl im Aktionsdatensatz sichtbar.

Ein fehlgeschlagener Isolierungstest hat ein erkennbares Muster

Die meisten Teams testen, dass alpha die API aufrufen kann und beta die API aufrufen kann. Das belegt, dass Zugangsdaten funktionieren. Es belegt nicht, dass derselbe langlebige Client von alpha zu beta wechseln kann, ohne Altlasten mitzubringen.

Bauen Sie einen kleinen Testserver mit zwei Konten und lassen Sie ihn melden, was er erhalten hat. Er sollte das aus Authorization abgeleitete Konto zurückgeben, den eingehenden Cookie-Header ausgeben, ein kontospezifisches Cookie setzen und einen Redirect-Endpunkt bereitstellen. Der Dienst sollte eine Anfrage ablehnen, wenn die Kontokennung im Cookie von der Kontokennung im Bearer-Header abweicht. Die Ablehnung macht den Fehler sichtbar, statt ihn hinter einer Affinitätsschicht zu verstecken.

Führen Sie diese Sequenz mit genau der Client-Konfiguration aus, die in Produktion verwendet wird:

1. Senden Sie eine alpha-Anfrage über einen neuen Pool. Bestätigen Sie, dass die Antwort route=alpha setzt.
2. Senden Sie eine beta-Anfrage über die Pool-Suche, die auch die Produktion nutzt. Prüfen Sie, dass der Server die beta-Autorisierung und einen leeren Cookie-Header sieht, außer beta besitzt einen eigenen Speicher, der nur beta-Cookies enthält.
3. Starten Sie alpha- und beta-Anfragen gleichzeitig über HTTP/2. Lassen Sie jeden Endpunkt vor der Antwort warten, damit sich die Streams überlappen, und prüfen Sie dann Identitäten und Cookies unabhängig voneinander.
4. Geben Sie jedem Konto eine 401-Challenge zurück und prüfen Sie, ob der Retry seinen ursprünglichen Zugangsdaten-Datensatz nutzt.
5. Geben Sie einen Redirect zu einer anderen Origin zurück und prüfen Sie, ob die Folgeanfrage keinen Authorization- oder Cookie-Header enthält.

Die Prüfungen sollten mehr als Statuscodes erfassen. Halten Sie die ausgewählte Kennung des Zugangsdaten-Datensatzes, Pool-ID, Origin, Protokollversion, Redirect-Ziel, das Vorhandensein eines Cookies und das Antwortkonto fest. Loggen Sie nie die Anmeldeinformation selbst. Wenn der Test fehlschlägt, zeigen diese Felder, ob das Leck aus der Pool-Suche, automatischen Headern, einem Cookie-Speicher oder der Retry-Middleware stammt.

Testen Sie auch die Rotation von Zugangsdaten. Starten Sie eine Anfrage, die auf dem Server wartet, ersetzen Sie den Zugangsdaten-Datensatz und senden Sie anschließend eine neue Anfrage. Die neue Aktion muss eine neue Pool-Identität verwenden. Entscheiden und dokumentieren Sie, ob die wartende Aktion mit ihrer ursprünglichen Berechtigung endet oder abgebrochen wird. Beides kann vertretbar sein. Die Berechtigung stillschweigend während der Ausführung zu ändern, ist es nicht.

Führen Sie den Test über jede unterstützte Proxy-Konfiguration aus. Proxy- und Origin-Zustand liegen oft in unterschiedlichen Bibliotheksschichten. Genau dort wird aus einem beruhigenden Unit-Test ein hilfreicher Integrationstest.

Agent-Aktionen brauchen eine kleinere Berechtigungsfläche

Ein autonomer Programmier-Agent sollte eine Aktion wie „Diese genehmigte API mit dem Zugangsdaten-Datensatz billing-read aufrufen“ anfordern. Er sollte kein Token erhalten und keinen breit angelegten, langlebigen Client bauen, der Sitzungszustand behält, nachdem sich die Aufgabe geändert hat. Der Action Executor kann genehmigtes Ziel, Methode, Zugangsdaten-Datensatz und Client-Grenze binden, bevor er überhaupt Bytes sendet.

Sallyport folgt dieser Trennung, indem es API- und SSH-Zugangsdaten in seinem verschlüsselten Vault behält und die Aktion selbst ausführt. Der Agent erhält also das Ergebnis statt der Anmeldeinformation. Diese Begrenzung hilft nur, wenn der HTTP-Pfad jeden Zugangsdaten-Datensatz ebenfalls als eigenen Berechtigungskontext behandelt.

Eine Genehmigung ersetzt keine Client-Isolierung. Ein Betreiber kann eine legitime beta-Aktion genehmigen, während ein nachlässig geteilter Cookie-Speicher daraus eine vermischte Anfrage von alpha und beta macht. Der Genehmigungseintrag dokumentiert dann eine Aktion, die von dem abweicht, was der Betreiber erlauben wollte. Setzen Sie die Grenze unterhalb des Genehmigungsbildschirms, dort, wo Header, Wiederholungsversuche und die Transportauswahl tatsächlich stattfinden.

Erfassen Sie für ein Aktions-Gateway die Kennung des Zugangsdaten-Datensatzes und die Pool-Identität im Audit-Ereignis, aber niemals das Geheimnis. Meldet ein Aufrufer eine Kontounstimmigkeit, müssen Sie feststellen können, ob der Executor die richtige Anmeldeinformation ausgewählt und nur den Zustand angehängt hat, der diesem Datensatz gehört. Ein manipulationssicherer Aktivitätstrail hilft bei dieser Untersuchung. Er macht ein mehrdeutiges Client-Design nicht sicher.

Die erste praktische Änderung ist einfach: Finden Sie jeden geteilten HTTP-Client und listen Sie auf, was er außer einer offenen Verbindung noch speichert. Wenn die Antwort Cookies, Challenge-Antworten, Redirects, Client-Zertifikate oder Proxy-Identität enthält, weisen Sie jedem Element einen expliziten Eigentümer zu, bevor die nächste Token-Rotation oder ein paralleler Agent-Lauf den Fehler teuer macht.