Zugangsdaten & die Übertragungsgrenze

Eine agentische Coding-Sitzung braucht Zugangsdaten — einen Anthropic-Schlüssel, um mit Claude zu sprechen, ein GitHub-Token, um zu pushen, AWS-Schlüssel, um zu deployen. Sie führt außerdem beliebigen Code aus, installiert beliebige Pakete und folgt Anweisungen aus Dateien, die sie nicht selbst geschrieben hat. Einer solchen Umgebung Ihre echten Geheimnisse zu geben ist der Weg, auf dem Schlüssel im Posteingang eines Diebes landen.

Bromure Agentic Coding löst diesen Konflikt mit der Übertragungsgrenze: Der Agent innerhalb der VM sieht immer nur gefälschte Platzhalter-Token. Ihre echten Zugangsdaten liegen verschlüsselt auf dem macOS-Host und werden von einem hostseitigen MITM-Proxy im letztmöglichen Moment auf die Leitung eingesetzt — nachdem die Anfrage die VM verlassen hat und nur dann, wenn sie für den Host bestimmt ist, zu dem das Zugangsdatum gehört. Keine Datei, keine Umgebungsvariable und kein Prozess innerhalb der VM enthält jemals einen echten API-Schlüssel, ein echtes OAuth-Token, ein echtes AWS-Geheimnis oder einen echten privaten SSH-Schlüssel.

Dieses Kapitel erklärt den Mechanismus von Anfang bis Ende, führt dann durch jeden unterstützten Typ von Zugangsdaten und seinen Lebenszyklus, das Genehmigungssystem pro Verwendung, den Kompromittierungs-Detektor und wie Sie die Grenze selbst überprüfen können.

Hinweis: Dieses Kapitel behandelt die Konzepte und das Laufzeitverhalten. Eine Feld-für-Feld-Referenz des Einstellungsbereichs finden Sie unter Einstellungen → Zugangsdaten.

Die Übertragungsgrenze auf einen Blick

Drei Prinzipien definieren das Modell:

1. Fälschungen in der VM. Jedes Zugangsdatum, das Sie konfigurieren, wird innerhalb der VM durch eine strukturerhaltende Fälschung ersetzt. Fälschungen behalten die Form, die Validatoren erwarten — eine Anthropic-Fälschung beginnt mit sk-ant-api03-brm-, eine GitHub-Fälschung ist ghp_ plus 36 Zeichen — sodass Tools wie claude, gh und doctl sie anstandslos akzeptieren.
2. Echte Werte nur auf der Leitung. Jede HTTPS-Anfrage, die die VM stellt, wird zum Host-Proxy getunnelt, der sie entschlüsselt, die Fälschung gegen den echten Wert austauscht und stromaufwärts wieder verschlüsselt. Der Austausch ist auf den Zielhost beschränkt, für den das Zugangsdatum erstellt wurde.
3. Fail-Closed. Wenn irgendetwas den Proxy umgeht, trägt die Anfrage nur eine Fälschung, und die stromaufwärtige Authentifizierung schlägt fehl. Es gibt keinen Pfad, auf dem ein echtes Geheimnis versehentlich durchsickert.

Fälschungen sind deterministisch: Jede wird aus dem echten Wert plus einem 32-Byte-Salt pro Installation über HKDF-SHA256 abgeleitet. Derselbe echte Schlüssel bildet auf Ihrem Mac immer dieselbe Fälschung ab, sodass Clients, die ihren Schlüssel per Fingerprint erkennen (Claude Code speichert zum Beispiel einen Schlüssel-Hash zwischen), das Zugangsdatum nie zwischen Sitzungen „rotieren" sehen.

Es gibt keinen Ein-/Ausschalter für die Grenze. Der Proxy ist der einzige Egress-Pfad der VM; der Austausch ist einfach die Art, wie Zugangsdaten in dieser App funktionieren.

Wie der Austausch von Anfang bis Ende funktioniert

Der vollständige Umlauf einer authentifizierten Anfrage:

1. Sitzungsstart — der Token-Plan. Wenn eine Arbeitsbereich-VM startet, erstellt die App einen Token-Plan pro Arbeitsbereich, der jedes echte Zugangsdatum mit seiner abgeleiteten Fälschung paart. Die Fälschungen werden in die VM geschrieben: Umgebungsvariablen (ANTHROPIC_API_KEY, GH_TOKEN, LINEAR_API_KEY, …) und Konfigurationsdateien (~/.git-credentials, ~/.docker/config.json, ~/.kube/config, ~/.aws/config, ~/.config/doctl/config.yaml, MCP-Konfigurationen). Die echten Werte werden in die In-Memory-Austauschzuordnung des Proxys geladen, jede mit dem Zielhost verknüpft, zu dem sie gehört.
2. Die Anfrage verlässt die VM. Der HTTPS-Verkehr des Gasts wird über einen virtio-Socket (vsock-Port 8443) zum Host-Proxy getunnelt. Die VM hat keine andere Route ins Netzwerk.
3. TLS-Terminierung. Der Proxy präsentiert ein gefälschtes Leaf-Zertifikat pro Host — der Ziel-Hostname als CN und SAN, ein EC-Schlüssel pro Host — signiert von der Bromure Agentic Coding Root CA. Da das öffentliche Zertifikat dieser CA beim Boot in den Trust Store der VM installiert wurde, akzeptieren die TLS-Clients des Gasts die Verbindung, und der Proxy kann die Klartext-Anfrage lesen.
4. Der Austausch. Der Proxy sucht jedes gefälschte Token, das in der Anfrage erscheint (Header und, für dafür angemeldete Typen von Zugangsdaten, der Body) und ersetzt es, wenn der Zielhost zum Geltungsbereich des Zugangsdatums passt, durch den echten Wert.
5. Erneute Verschlüsselung stromaufwärts. Die umgeschriebene Anfrage wird über Apples URLSession, also den eigenen TLS-Stack von macOS, an das echte Ziel neu ausgesendet, wobei das echte Zertifikat des stromaufwärtigen Servers validiert wird. Die Antwort streamt durch den Tunnel zurück zum Gast.

Wenn das Ziel nicht zum Geltungsbereich einer Fälschung passt, geht die Fälschung unverändert hinaus (und scheitert an der stromaufwärtigen Authentifizierung) — oder, wenn die Nichtübereinstimmung wie eine Exfiltration aussieht, wird die Anfrage sofort blockiert (siehe Der Kompromittierungs-Detektor unten).

Die Bromure Agentic Coding Root CA

Die CA existiert pro Installation und liegt unter ~/Library/Application Support/BromureAC/ca/ (cert.pem plus ein key.pem mit Modus 0600). Ihr Subject ist „Bromure Agentic Coding Root CA", die Organisation „Bromure". Wissenswerte Eigenschaften:

• Die Gültigkeit der CA beträgt 10 Jahre. Gefälschte Leaf-Zertifikate pro Host sind 1 Jahr gültig und um 24 Stunden zurückdatiert, sodass ein Gast, dessen Uhr während Suspend/Resume abgedriftet ist, sie dennoch akzeptiert. Leaves werden pro Host für die Lebensdauer des App-Prozesses zwischengespeichert.
• Das öffentliche Zertifikat wird beim Boot in den Trust Store jeder VM installiert (über die Meta-Freigabe geliefert und mit update-ca-certificates angewendet). Es verlässt Ihre Maschine nie und wird von nichts außer Ihren VMs vertraut.
• Um die CA zu rotieren, beenden Sie die App und löschen Sie das Verzeichnis ca/. Beim nächsten Start wird eine frische CA erstellt, und jede VM übernimmt das neue öffentliche Zertifikat bei ihrem nächsten Boot. Die Rotation macht nichts anderes ungültig — Arbeitsbereich-Geheimnisse und profile.json-Metadaten bleiben unberührt.

Host-Geltungsbereich

Jeder Austauscheintrag ist an einen Host-Geltungsbereich gebunden. Der Abgleich erfolgt exakt oder als Subdomain und ohne Berücksichtigung der Groß-/Kleinschreibung, niemals als Teilzeichenkette: Ein auf openai.com beschränktes Zugangsdatum passt zu api.openai.com, aber nicht zu openai.com.evil.example — ein täuschend ähnlicher Host kann den Proxy nicht dazu bringen, seine Anfrage mit einem echten Schlüssel zu versehen. Manuelle Token-Regeln dürfen absichtlich einen leeren Host-Filter verwenden, was „auf jedem Host einsetzen" bedeutet; das ist eine explizite Entscheidung, die Sie pro Eintrag treffen (siehe Generische API-Schlüssel).

Fail-Closed durch Konstruktion

Das Design verlässt sich für die Geheimhaltung nie darauf, dass der Proxy unumgänglich ist — es verlässt sich darauf, dass die Geheimnisse gar nicht dort sind:

• Eine Anfrage, die den Proxy irgendwie überspringt, trägt ein gefälschtes Token; die stromaufwärtige API lehnt es ab.
• AWS-Anfragen, die innerhalb der VM signiert werden, werden mit einem gefälschten geheimen Schlüssel signiert; wenn sie AWS direkt erreichten, würden sie mit InvalidSignatureException scheitern (siehe AWS unten).
• Die Bytes des privaten SSH-Schlüssels befinden sich gar nicht erst in der VM; nur Signaturen überqueren die Grenze.

Zugangsdaten im Arbeitsbereich-Editor verwalten

Zugangsdaten werden pro Arbeitsbereich konfiguriert. Öffnen Sie den Editor des Arbeitsbereichs (Arbeitsbereich bearbeiten) und wählen Sie in der Seitenleiste Zugangsdaten.

Der Bereich beginnt mit Git-Identität (ein Name und eine E-Mail-Adresse, die in ~/.gitconfig in der VM geschrieben werden; lassen Sie beide leer, um die Standardwerte von git beizubehalten — die Platzhalter sind nur Beispiele, keine Zugangsdaten), gefolgt von einer Liste ausschließlich der von Ihnen konfigurierten Zugangsdaten, gruppiert unter Kategorie-Überschriften (Agenten, Git, Cloud, Datenbanken, SSH, Andere). Zwei Schaltflächen befinden sich am unteren Rand: Zugangsdatum hinzufügen öffnet eine Auswahl der Typen von Zugangsdaten — Git-Token, SSH-Schlüssel, AWS-Zugangsdaten, DigitalOcean-Token, Linear-API-Schlüssel, Kubernetes, Container-Registry, Datenbank und Anderer API-Schlüssel — und Env-Datei importieren… importiert massenweise aus einer .env oder einer ~/.bashrc. Der eigene Schlüssel des primären Agenten liegt im Bereich Agenten, der als Nächstes beschrieben wird. Klicken Sie auf Sichern; der nächste Sitzungsstart schreibt die Fälschungen in die VM und lädt die echten Werte in den Proxy.

Das Genehmigungs-Gate pro Zugangsdatum (Vor Verwendung fragen) und die Schreibrichtlinie jedes Dienstes werden im Bereich Schutzmechanismen festgelegt, nicht hier — der Bereich Zugangsdaten trägt diese Steuerelemente nicht mehr. Die Feld-für-Feld-Referenz finden Sie unter Einstellungen → Zugangsdaten.

Sechs Anbieter werden automatisch behandelt — Anthropic, OpenAI, GitHub, GitLab, DigitalOcean und Kubernetes benötigen keine manuellen Token-Regeln; ihre eigenen Abschnitte behandeln sie. Alles andere läuft über Andere API-Schlüssel.

Import aus einer Env-Datei. Env-Datei importieren… liest eine bestehende .env-Datei — oder eine ~/.bashrc — und wandelt ihre Variablen in Zugangsdaten um. Der Parser verarbeitet KEY=VALUE und export KEY=VALUE, entfernt umgebende Anführungszeichen und nachgestellte Kommentare und überspringt absichtlich alles, was eine Shell-Auswertung erfordern würde ($VAR-Interpolation oder $(…)-Substitution), sodass es sicher ist, ihn auf eine echte .bashrc zu richten. Ein Prüfblatt zeigt dann die Variablen mit maskierten Werten: Erkannte Namen (ANTHROPIC_API_KEY, OPENAI_API_KEY, XAI_API_KEY, GH_TOKEN/GITHUB_TOKEN, GITLAB_TOKEN, AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN, DIGITALOCEAN_ACCESS_TOKEN, LINEAR_API_KEY) bilden automatisch ihren Typ von Zugangsdaten ab, während unerkannte Namen als generische manuelle Token mit einem von Ihnen angegebenen, kommagetrennten Host-Geltungsbereich importiert werden können. Bereits konfigurierte Einträge werden markiert und nicht angehakt, sodass ein erneuter Import nie stillschweigend ein Geheimnis überschreibt.

Typen von Zugangsdaten

API-Schlüssel des primären Agenten (Anthropic, OpenAI, xAI)

Der Schlüssel für den primären Agenten des Arbeitsbereichs wird im Bereich Agenten festgelegt, wo jede Agentenkarte einen Auswahlschalter für den Auth-Modus bietet.

Wählen Sie API-Token und fügen Sie den Schlüssel in das Feld ein (Anthropic-API-Schlüssel für Claude Code, OpenAI-API-Schlüssel für Codex, den xAI-Schlüssel für Grok Build). Lebenszyklus:

• In der VM: exportiert als ANTHROPIC_API_KEY / OPENAI_API_KEY / XAI_API_KEY, mit der anbietergeformten Fälschung (sk-ant-api03-brm-…, sk-brm-…, xai-brm-…).
• Auf der Leitung: auf Anfragen an die Hosts des Anbieters (anthropic.com, openai.com, x.ai jeweils) zum echten Schlüssel ausgetauscht.
• Genehmigung: Um die erste Verwendung in jeder Sitzung zu gaten, aktivieren Sie Vor Verwendung fragen für den Schlüssel des Agenten im Bereich Schutzmechanismen (siehe Genehmigung pro Verwendung). Standardmäßig ist es ausgeschaltet.

Die anderen Auth-Modi im Auswahlschalter — Abonnement (interaktive Anmeldung), Bedrock (AWS) und Lokales Modell — werden unten und in Lokale Modelle behandelt. Über die CLI ist dieselbe Wahl --auth token|subscription|bedrock|local bei bromure-cli workspaces create (und token|subscription|bedrock bei bromure-cli vm run für spontane Arbeitsbereiche).

Claude-, Codex- und Grok-Abonnements

Wenn Sie ein Claude-, ChatGPT- (Codex) oder Grok-Abonnement statt eines API-Schlüssels haben, authentifiziert sich der Agent normalerweise per interaktiver OAuth-Anmeldung — ein Browser-Flow, den eine gesandboxte VM mit echten Token nicht abschließen kann (und sollte). Bromure Agentic Coding unterstützt Abonnements mit zwei Mechanismen. Beide enden am selben Ort: Die echten OAuth-Token liegen nur auf dem Host, und der Gast läuft mit einem Schein-Schlüssel.

Bei Claude / ChatGPT / Grok registrieren (empfohlen)

Setzen Sie den Auth-Modus des Agenten auf Abonnement (interaktive Anmeldung) und klicken Sie auf Registrieren…. Was passiert:

1. Die App prüft, dass der Proxy läuft (andernfalls wird die Registrierung verweigert) und zeigt ein Erklärblatt mit dem Titel Bei Claude registrieren (oder ChatGPT / Grok). Klicken Sie auf Fortfahren.
2. Eine Wegwerf-Registrierungs-VM bootet — temporär, isoliert, ohne Arbeitsbereich-Ordner-Einhängungen und ohne Austauschzuordnung für Zugangsdaten. Darin läuft der echte Anmeldebefehl (claude login, codex login oder das Grok-Äquivalent).
3. Der Standardbrowser Ihres Macs öffnet die Anmeldeseite des Anbieters. Melden Sie sich wie gewohnt an. Sie haben etwa 4 Minuten, bevor der Flow ausläuft.
4. Die resultierenden OAuth-Token werden auf dem Host erfasst, verschlüsselt und gespeichert; die Wegwerf-VM wird zerstört.
5. Wenn Sie die Registrierung aus einem Arbeitsbereich-Editor gestartet haben, fragt die App Mit jedem Arbeitsbereich teilen? — wählen Sie Jeder Arbeitsbereich, um das Abonnement als gemeinsamen Standard zu speichern, oder Nur dieser Arbeitsbereich. Aus den Einstellungen der App gestartete Registrierung speichert immer den gemeinsamen Standard, ohne zu fragen.

Danach läuft der Gast jeder Sitzung im API-Schlüssel-Modus mit einem deterministischen Schein-Zugangsdatum — einem gefälschten ANTHROPIC_API_KEY für Claude, einer geseedeten ~/.codex/auth.json mit einem gefälschten JWT mit weit in der Zukunft liegendem Ablauf für Codex (sodass der Client nie versucht, es selbst zu aktualisieren), einer Platzhalter-~/.grok/auth.json für Grok. Der Proxy erkennt den Schein-Wert und injiziert ein aktives Authorization: Bearer-Zugriffstoken (plus den OAuth-Beta-Header für Claude) auf der Leitung.

Token-Verwahrung und -Aktualisierung erfolgen vollständig hostseitig. Der Host aktualisiert Token etwa 5 Minuten vor Ablauf gegen den Token-Endpunkt des Anbieters (platform.claude.com/v1/oauth/token für Claude, auth.openai.com/oauth/token für Codex, auth.x.ai/oauth2/token für Grok), sodass eine Aktualisierung jeder laufenden VM dient und der Gast nie ein Refresh-Token hält. Ein frisch erfasster Datensatz wird absichtlich mit einem bereits vergangenen Ablauf gespeichert, was bei der ersten Verwendung eine Aktualisierung erzwingt — und beweist, dass der Aktualisierungspfad funktioniert, bevor Sie sich darauf verlassen.

Die Steuerelemente neben dem Auswahlschalter für den Auth-Modus vervollständigen den Lebenszyklus: Neu registrieren… wiederholt die Erfassung (zum Beispiel nach dem Widerruf von Sitzungen stromaufwärts), und Vergessen löscht das gespeicherte Abonnement vom Host.

Der Token-Austausch innerhalb der Sitzung

Alternativ, wenn sich der Agent selbst innerhalb der VM anmeldet (Sie führen claude login in der Sitzung aus), bemerkt der Proxy ein echtes Abonnement-OAuth-Token, das zum Anbieter hinausgeht, und bietet an, es in Verwahrung zu nehmen. Ein Blatt erscheint — Claude-Abonnement-Token austauschen? (oder Codex) — das erklärt, dass das echte Token auf diesem Mac bleiben kann, während eine Fälschung es in der Zugangsdaten-Datei der VM ersetzt. Sowohl das Zugriffs- als auch das Refresh-Token werden zusammen ausgetauscht. Ihre Optionen:

Der Zustand pro Arbeitsbereich hinter dieser Abfrage ist im Editor als Claude-Abonnement-Token-Austausch / Codex-Abonnement-Token-Austausch sichtbar (standardmäßig nicht gesetzt; „akzeptiert" oder „abgelehnt", nachdem Sie gewählt haben). Der Austauschkanal vom Host zur VM ist absichtlich einseitig: Der Host kann nur Fälschungen in die VM schreiben, und die VM kann nur echte Werte an den Host senden — es gibt keinen RPC, über den die VM ein echtes Token zurückfordern könnte. Der Agent in der VM weigert sich zusätzlich, ein Zugangsdatum zu schreiben, das nicht das Fälschungs-Präfix brm- trägt, sodass selbst ein fehlverhaltender Host die Zugangsdaten-Datei des Gasts nicht mit einem echten Wert beschädigen kann.

Hinweis: Codex bleibt innerhalb des Gasts im Abonnement-Modus (sein API-Schlüssel-Modus zielt auf ein anderes Backend), und Groks Token reisen über die Datei ~/.grok/auth.json statt über einen vsock-Agenten. Dies sind Implementierungsdetails; das Verwahrungsmodell ist identisch.

AWS

AWS erhält die tiefgründigste Behandlung aller Anbieter, weil AWS-Anfragen nicht durch ein Bearer-Token authentifiziert werden — sie werden signiert (SigV4). Öffnen Sie Zugangsdaten → AWS im Arbeitsbereich-Editor; ein segmentiertes Steuerelement wählt zwischen Statische Schlüssel und SSO / Identity Center.

Statische Schlüssel und der Host-Resigner

Fügen Sie Ihre Access Key ID und Ihren Secret Access Key ein (plus ein optionales STS-Session-Token und eine Standardregion). Der Lebenszyklus:

• In der VM: ~/.aws/config verweist auf einen credential_process-Helper, der — über vsock-Port 8445 — die echte Access Key ID gepaart mit einem 40 Zeichen langen gefälschten Secret Access Key ausgibt und das Session-Token weglässt. Jedes AWS-SDK, die aws-CLI, terraform und boto3 übernehmen dies nativ; keine toolspezifische Einrichtung ist nötig.
• Was der Gast tut: signiert seine Anfragen mit dem gefälschten Geheimnis und erzeugt eine syntaktisch gültige, aber kryptografisch zum Scheitern verurteilte SigV4-Signatur.
• Auf der Leitung: der AWS-Resigner des Hosts erkennt Anfragen, die für *.amazonaws.com und *.amazonaws.com.cn bestimmt sind (GovCloud-, ISO-, regionale und bucket-artige S3-Hosts eingeschlossen), entfernt die Signatur des Gasts, injiziert das echte X-Amz-Security-Token, wenn ein Session-Token vorhanden ist, und signiert mit dem echten Geheimnis neu, bevor die Anfrage Ihren Mac verlässt. Jede erfolgreiche Neusignierung erzeugt ein credential.aws_sign-Audit-Ereignis mit einer maskierten Access Key, sichtbar in Tracing.

Dies ist Fail-Closed im stärksten Sinne: Der echte geheime Schlüssel existiert in der VM in keiner Form, und eine Anfrage, die den Proxy umgeht, wird von AWS mit InvalidSignatureException abgelehnt.

Drei Anfragestile werden nicht unterstützt und geben dem Gast einen klaren Fehler statt eines stillen Scheiterns zurück: Chunked-Streaming-S3-Uploads (STREAMING-AWS4-HMAC-SHA256-PAYLOAD, mit 501 beantwortet), asymmetrische SigV4A-Signierung und vorsignierte Query-String-URLs (die die Signatur dort einbetten, wo der Resigner sie nicht ersetzen kann).

SSO / IAM Identity Center

Wenn Ihre Organisation IAM Identity Center verwendet, wählen Sie SSO / Identity Center statt langlebige Schlüssel einzufügen:

1. Klicken Sie auf Zugriff auf ~/.aws gewähren und genehmigen Sie die Ordnerzugriffs-Abfrage (eine sicherheitsbereichsbeschränkte Gewährung; der Ordner wird auf dem Host gelesen und nie in die VM eingehängt).
2. Wählen Sie Ihr Profil aus dem SSO-Profil-Auswähler. Die App entdeckt [profile …]-Abschnitte in ~/.aws/config, die sso_start_url, sso_account_id und sso_role_name tragen, und löst [sso-session …]-Referenzen auf; Account-ID und Rolle werden schreibgeschützt angezeigt.
3. Beim Sitzungsstart löst der Host temporäre Rollen-Zugangsdaten aus dem SSO-Token-Cache (~/.aws/sso/cache) auf. Wenn das zwischengespeicherte Token abgelaufen ist, öffnet sich Ihr Browser für aws sso login — ausgeführt auf dem Host, von /usr/local/bin/aws.

Die aufgelösten temporären Schlüssel speisen denselben Resigner wie statische Schlüssel; die VM sieht weiterhin nie ein Geheimnis. Zugangsdaten werden auf dem Host etwa 5 Minuten vor Ablauf automatisch aktualisiert.

Bedrock

Bedrock (AWS) im Auth-Modus-Auswahlschalter des Agenten führt Claude Code gegen AWS Bedrock aus, wobei die AWS-Zugangsdaten verwendet werden, die der Arbeitsbereich konfiguriert hat (statisch oder SSO) — es ist ein Auth-Modus des primären Tools, kein separates Zugangsdatum. Setzen Sie den Auth-Modus, konfigurieren Sie Zugangsdaten → AWS und setzen Sie optional eine Bedrock-Modell-ID auf dem Arbeitsbereich. Die Signierung läuft über denselben Resigner-Pfad, da Bedrock-Endpunkte *.amazonaws.com-Hosts sind.

Git-HTTPS-Token (GitHub, GitLab, Bitbucket, selbstgehostet)

Persönliche Zugriffstoken für git-über-HTTPS liegen unter GitHub-Token / GitLab-Token / Bitbucket-Token (zusammen HTTPS-Token). Jeder Eintrag nimmt einen Host, einen Benutzernamen und das Token; selbstgehostete GitLab- oder Gitea-Instanzen funktionieren durch Setzen des Host-Feldes. Lebenszyklus:

• In der VM: eine Fälschung wird in ~/.git-credentials und die gh/glab-Konfiguration geschrieben; GH_TOKEN und GITLAB_TOKEN werden exportiert, sodass sich die CLIs automatisch authentifizieren. Die Formen der Fälschungen entsprechen den Validatoren jedes Anbieters (ghp_ + 36 für GitHub, glpat- + 20 für GitLab, brm_… sonst), sodass Präfix- und Längenprüfungen in gh und glab bestehen.
• Auf der Leitung: auf Anfragen an den Git-Host dieses Eintrags zum echten Token ausgetauscht.
• Genehmigung: jeder Eintrag erhält seine eigene Vor Verwendung fragen-Zeile im Bereich Schutzmechanismen.

Wenn Sie nur git push über SSH benötigen, brauchen Sie möglicherweise überhaupt kein HTTPS-Token — siehe SSH-Schlüssel unten.

Generische API-Schlüssel (Andere API-Schlüssel / Manuelle Token-Regeln)

Für jede API, die die App nicht automatisch behandelt, fügen Sie einen Eintrag unter Andere API-Schlüssel hinzu (die manuellen Token-Regeln, auch als MITM-Token-Austausch dargestellt). Klicken Sie auf Token hinzufügen und geben Sie an:

Zwei Randfälle sind beabsichtigt:

• Leerer Env-Variablenname: nichts wird exportiert; Sie kopieren die Fälschung aus dem Willkommensbanner der Sitzung und platzieren sie dort, wo Ihr Tooling sie benötigt.
• Leerer Host-Filter: der echte Wert wird auf jedem Host injiziert, ohne zu fragen. Das ist eine explizite Immer-an-Entscheidung — nützlich für APIs mit vielen regionalen Hostnamen — aber es bedeutet, dass der Geltungsbereich des Zugangsdatums es nicht mehr schützt. Um ein Geheimnis ohne Geltungsbereich zu gaten, aktivieren Sie Vor Verwendung fragen dafür im Bereich Schutzmechanismen (oder geben Sie ihm doch einen Host-Filter).

Anthropic, OpenAI, GitHub, GitLab, DigitalOcean und Kubernetes benötigen hier nie manuelle Einträge.

1Password-Geheimnisreferenzen (op://)

Statt ein echtes Geheimnis einzufügen, kann der Wert eines Anderen API-Schlüssels eine 1Password-Geheimnisreferenz sein — op://vault/item/field oder die Klammerform {{ op://vault/item/field }}, die op inject und .env.op-Dateien verwenden. Nur die Referenz wird jemals auf der Festplatte gespeichert; das Geheimnis selbst wird nirgendwo auf dem Host oder der VM geschrieben. Der Editor erkennt die Referenz, zeigt sie im Klartext an (sie ist kein Geheimnis) und weist darauf hin, dass sie über 1Password aufgelöst wird.

Bei jedem Arbeitsbereich-Start löst Bromure die Referenz hostseitig mit der 1Password-CLI (op read) auf, erstellt eine Fälschung aus der Referenzzeichenkette (sodass die Fälschung stabil bleibt, selbst wenn das Geheimnis rotiert) und exportiert nur diese Fälschung in die VM. Der MITM-Proxy tauscht dann die Fälschung gegen den aufgelösten Wert auf der Leitung aus, genau wie bei einem eingefügten Geheimnis — und er löst alle 2 Minuten neu auf, sodass das Rotieren des Elements in 1Password innerhalb weniger Minuten ohne Neustart wirksam wird.

Dies erfordert die installierte und angemeldete op-CLI — biometrische Entsperrung über die 1Password-App oder op signin in einem Terminal. Wenn op nicht gefunden wird, zeigt der Editor einen 1Password-CLI beziehen-Link und der Arbeitsbereich zeigt beim Start Installationsanweisungen an; wenn die Auflösung fehlschlägt (nicht angemeldet oder das Element existiert nicht), zeigt Bromure den Fehler an, damit Sie ihn beheben und den Arbeitsbereich neu starten können.

Der Import einer .env- oder .env.op-Datei (Aus .env importieren… im Editor) erkennt op://-Werte automatisch — unter erkannten Namen wie ANTHROPIC_API_KEY oder beliebigen wie STRIPE_KEY — und speichert jeden als manuelles Token, das die Referenz hält.

DigitalOcean

Fügen Sie ein persönliches Zugriffstoken unter Zugangsdaten → DigitalOcean ein (der Link DigitalOcean-Token-Seite im Browser öffnen führt Sie zur Token-Generierung). Die Fälschung (dop_v1_ + Hex, 64 Zeichen) wird als DIGITALOCEAN_ACCESS_TOKEN exportiert und in ~/.config/doctl/config.yaml geschrieben, sodass doctl auth init unnötig ist. Der Austausch deckt Anfragen an digitalocean.com ab, plus einen zweiten Eintrag für den base64-Basic-Auth-Blob, den docker login / doctl registry login gegen registry.digitalocean.com verwenden, sodass sich auch Registry-Pushes und -Pulls auflösen.

Linear

Fügen Sie einen persönlichen API-Schlüssel unter Zugangsdaten → Linear ein (Link: Linear-API-Einstellungen im Browser öffnen; Schlüssel kommen von linear.app → Settings → API). Die Fälschung (lin_api_ + 40) wird als LINEAR_API_KEY exportiert, das das Linear-SDK, MCP-Server und CLI-Tools automatisch übernehmen; der Austausch ist streng auf linear.app beschränkt (GraphQL bei api.linear.app und MCP bei mcp.linear.app). Ein Linear-Schlüssel auf dem Arbeitsbereich ist außerdem Voraussetzung für Automatisierungs-Trigger auf Basis von Linear-Issues — siehe Automatisierung & CLI.

Bearer-Token für MCP-Server

MCP-Server mit HTTP-Transport, die im MCP-Bereich konfiguriert sind, erhalten dieselbe Behandlung: Das echte Bearer-Token bleibt auf dem Host, eine brm-mcp_…-Fälschung wird in die MCP-Konfiguration injiziert, die der Agent liest, und der Proxy tauscht es auf der Leitung aus, beschränkt auf den Host des Servers. Nur aktivierte Server mit HTTP-Transport und einem nicht leeren Bearer-Token erhalten einen Austauscheintrag.

Ein zusätzliches Entgegenkommen: Für Hosts mit einem brm-mcp_-Eintrag beantwortet der Proxy die OAuth/OIDC-Discovery-Pfade (.well-known-Authorization-Server, Protected-Resource und OpenID-Konfigurations-Endpunkte) mit 404. Claude Code behandelt den Server dann als vorauthentifiziert, statt seinen eigenen OAuth-Flow zu versuchen — der ohnehin nie innerhalb der VM abgeschlossen werden könnte.

Container-Registries (Docker Hub, GHCR und Freunde)

Zugangsdaten → Container-Registries verwaltet die HTTP-Basic-Auth für docker pull/push. Voreinstellungen existieren für Docker Hub (docker.io), GitHub Container Registry (ghcr.io) und GitLab Container Registry (registry.gitlab.com); jede andere Registry kann per Host hinzugefügt werden. Lebenszyklus:

• In der VM: ~/.docker/config.json enthält einen gefälschten Auth-Blob — das base64 Ihres Benutzernamens gepaart mit einem abgeleiteten brm-docker-…-Passwort — sodass Docker glaubt, angemeldet zu sein.
• Auf der Leitung: der Proxy ersetzt den echten base64-Blob am passenden Registry-Host. Der Token-Tanz der Distribution-Spec wird ebenfalls behandelt: Austauscheinträge werden für bekannte Auth-Realms hinzugefügt (Docker Hub authentifiziert gegen auth.docker.io, DigitalOceans Registry gegen api.digitalocean.com).
• Import: klicken Sie auf config.json importieren…, um Einträge aus einer bestehenden ~/.docker/config.json auf dem Host zu übernehmen. An credsStore/credHelpers delegierte Einträge werden übersprungen — ihre Passwörter liegen im OS-Schlüsselbund, nicht in der Datei — und die Import-Zusammenfassung meldet, wie viele übersprungen wurden und warum.
• Genehmigung: pro Registry, über Vor Verwendung fragen im Bereich Schutzmechanismen. Diese Registry entfernen löscht einen Eintrag.

Kubernetes-Kontexte

Zugangsdaten → Kubernetes wandelt kubeconfig-Kontexte in proxy-vermittelten Cluster-Zugriff um. Klicken Sie auf kubeconfig importieren, um eine bestehende kubeconfig in eine Zeile pro Kontext zu parsen (der aktuelle Kontext zuerst, Auth-Typ automatisch erkannt), oder auf Kontext hinzufügen, um eine Server-URL, Zugangsdaten, einen Namespace und eine Cluster-CA manuell einzugeben. In jedem Fall erhält die VM eine synthetische ~/.kube/config: kubectl im Gast spricht mit dem Proxy (vertraut über die Bromure-CA), nie direkt mit dem API-Server.

Pro Auth-Typ:

• Bearer-Token-Kontexte erhalten einen brm-k8s-…-Platzhalter in der VM, auf der Leitung zum echten Token ausgetauscht.
• Client-Zertifikat-Kontexte erhalten ein Wegwerf-selbstsigniertes Zertifikat und einen Schlüssel in der VM; das echte Zertifikat und der echte Schlüssel werden auf dem Host als SecIdentity registriert und für stromaufwärtiges mTLS verwendet.
• Exec-Plugin-Kontexte führen das Plugin überhaupt nie in der VM aus. Der Exec-Plugin-Poller führt den Befehl auf dem Host in jedem Aktualisierungsintervall aus (Standard 600 Sekunden, Untergrenze 60), parst das ExecCredential-JSON und speist das frische Token in die Austauschzuordnung ein. Aktualisierungen bewahren den Zustimmungszustand des Eintrags.

Wenn die kubeconfig die eigene CA des Clusters liefert, wird sie weitergeleitet, damit der Proxy den stromaufwärtigen API-Server verifizieren kann. Dateipfad-Felder in einer importierten kubeconfig (CA, Zertifikat, Schlüssel) werden zum Importzeitpunkt eifrig gelesen — spätere Änderungen an diesen Dateien auf der Festplatte werden nicht übernommen. Jeder Kontext erhält seine eigene Vor Verwendung fragen-Zeile im Bereich Schutzmechanismen, wo eine Schreibrichtlinie zusätzlich destruktive Verben (kubectl delete, AWS Delete*/Terminate*, docker push, git push) hostseitig entfernen kann, bevor ein einziges Byte weitergeleitet wird — eine von der Zugangsdaten-Austausch getrennte Schicht.

HTTP-Datenbanken (MongoDB, ClickHouse, Elasticsearch)

Zugangsdaten → Datenbanken (die Abschnitte MongoDB / ClickHouse / Elasticsearch) deckt HTTPS-sprechende Datenbank-Endpunkte ab — die Mongo Data API, die HTTP-Schnittstelle von ClickHouse, Elastic. Jeder Endpunkt nimmt eine Engine, einen Host, ein Geheimnis, einen Benutzernamen, einen Auth-Typ und einen oder mehrere Env-Variablennamen (kommagetrennt), unter denen die brm-db-…-Fälschung exportiert wird; verweisen Sie aus Ihrem Code oder Ihren Verbindungszeichenketten auf diese Variablen.

Datenbank-Zugangsdaten sind die eine Familie, bei der der Austausch auch den Anfrage-Body durchsucht, nicht nur Header und Query-Parameter, weil Verbindungsgeheimnisse routinemäßig innerhalb von JSON- oder SQL-Nutzlasten reisen. Der Proxy korrigiert Content-Length nach einem Body-Austausch; unbeteiligte Multipart- oder Binär-Bodys anderen Verkehrs werden nie angetastet (alle anderen Austausche sind header-beschränkt). Basic-Auth-Endpunkte erhalten außerdem ihren base64-Benutzer-und-Geheimnis-Blob ausgetauscht. Das Vor Verwendung fragen pro Endpunkt und die Schreibrichtlinie werden im Bereich Schutzmechanismen festgelegt.

SSH-Schlüssel

SSH wird ganz ohne Token behandelt: Der SSH_AUTH_SOCK der VM wird von einer ssh-agent-Brücke über vsock (Port 8444) gestützt. Der Gast kann Identitäten auflisten und Signaturen anfordern, aber die Bytes des privaten Schlüssels liegen nur auf dem Host und können physisch nicht von innerhalb der VM gelesen oder extrahiert werden. Es gibt zwei Schlüsselquellen, beide unter Zugangsdaten → SSH-Schlüssel:

• Der Standardschlüssel pro Arbeitsbereich. Ein gemeinsames ed25519-Standard-Schlüsselpaar wird beim App-Start generiert (gespeichert unter default-ssh/ in Application Support) und in das Agentenverzeichnis jedes neuen Arbeitsbereichs kopiert. Der Bereich zeigt den öffentlichen Schlüssel des Arbeitsbereichs, sodass Sie ihn in Ihren Git-Host einfügen können (für GitHub: github.com/settings/keys). Sie können auch einen frischen Schlüssel über die CLI mit bromure-cli workspaces ssh-keygen <workspace-id|name> erstellen, was den neuen öffentlichen Schlüssel ausgibt.
• Importierte Schlüssel. Klicken Sie auf Importieren… / Datei importieren… unter Importierte SSH-Schlüssel und richten Sie die App auf eine bestehende private Schlüsseldatei — RSA, ed25519 und ECDSA werden unterstützt, verschlüsselte Schlüssel eingeschlossen. Ein verschlüsselter Schlüssel fragt beim Import einmal nach seiner Passphrase; die Passphrase wird im macOS-Schlüsselbund gespeichert (Dienst io.bromure.agentic-coding.ssh-key-passphrases) und beim Start über SSH_ASKPASS bereitgestellt, nie protokolliert. Die Signierung mit importierten Schlüsseln läuft über einen privaten ssh-agent-Prozess, den die App für sich selbst startet (ssh-agent -D auf einem Socket unter dem temporären Verzeichnis) — getrennt von allem anderen auf Ihrem System.

Pro importiertem Schlüssel bewirkt das Aktivieren von Vor Verwendung fragen im Bereich Schutzmechanismen, dass jede Signaturanfrage in der VM zur Zustimmung auffordert. Jede Signatur — Standard- oder importierter Schlüssel — erzeugt ein credential.ssh_sign-Audit-Ereignis, das den SHA256-Fingerprint des Schlüssels und ob es ein verwalteter oder importierter Schlüssel war trägt.

Hinweis: Ihr macOS-Anmelde-ssh-agent (der launchd-Agent) wird absichtlich nie der VM ausgesetzt. Nur Schlüssel pro Arbeitsbereich und von Ihnen ausdrücklich importierte Schlüssel sind aus einer Sitzung erreichbar.

Genehmigung pro Verwendung und Gewährungsdauern

Jedes Zugangsdatum in diesem Kapitel kann als Vor Verwendung fragen markiert werden — ein Kontrollkästchen pro Zugangsdatum im Bereich Schutzmechanismen (auf dem Steuerelement selbst als Genehmigung zur Verwendung erforderlich beschriftet), standardmäßig aus, in der Benutzeroberfläche beschrieben als: „Zeigt einen Bestätigungsdialog an, wenn dieses Zugangsdatum zum ersten Mal in einer Sitzung verwendet wird."

Wenn ein gegatetes Zugangsdatum zum ersten Mal in einer Sitzung verwendet wird, hält der Proxy die Anfrage und zeigt einen Zustimmungsdialog mit dem Titel „Arbeitsbereich-Name" die Verwendung des Zugangsdatums erlauben? (mit dem Namen Ihres Arbeitsbereichs und der Bezeichnung des Zugangsdatums ausgefüllt), der vier Schaltflächen bietet:

Wissenswertes Verhalten:

• Zusammenführung. Gleichzeitige Anfragen, die dasselbe Zugangsdatum benötigen, laufen in einem Dialog zusammen — ein geschwätziger Agent, der zwölf parallele API-Aufrufe abfeuert, erzeugt eine Abfrage, und alle zwölf folgen Ihrer Entscheidung.
• Ablehnung gewinnt. Eine aktive Ablehnung greift kurz, bevor eine ältere Erlaubnis konsultiert wird.
• Flüchtig durch Design. Gewährungen und Ablehnungen werden nur im Speicher gehalten und beim Sitzungsabbau widerrufen. „Rest der Sitzung" überlebt nie ein Fensterschließen, und nichts wird über App-Läufe hinweg persistiert.
• Headless-Sitzungen. In einer SSH- oder Headless-Sitzung erscheint die Abfrage im tmux des Arbeitsbereichs statt als GUI-Warnung — siehe Fernzugriff.

Für AWS gilt das Gate für jeden hostseitigen Signieraufruf; für SSH-Schlüssel für Signaturanfragen; für alles andere für den ersten Leitungsaustausch der Sitzung.

Tipp: Das Zustimmungs-Gate gilt pro Zugangsdatum, nicht pro Host. Wenn Sie möchten, dass ein manuelles Token ohne Geltungsbereich unter Kontrolle bleibt, ist die Genehmigung der dafür gedachte Mechanismus.

Das Fenster „Zugangsdaten-Genehmigungen"

Fenster → Zugangsdaten-Genehmigungen… öffnet eine Live-Ansicht jeder Zustimmungsentscheidung, die während des aktuellen App-Laufs getroffen wurde: zeitbegrenzte Erlaubnisse (5 Minuten / 1 Stunde / Rest der Sitzung) und gemerkte Ablehnungen. Jede Zeile zeigt den Arbeitsbereich-Namen und die verbleibende Zeit und bietet Widerrufen; Alle widerrufen (⌘⌫) löscht alles auf einmal. Die Liste aktualisiert sich automatisch alle 2 Sekunden und schrumpft natürlich, wenn Gewährungen ablaufen.

Da Entscheidungen nur im Speicher liegen, ist das Fenster leer, nachdem Gewährungen ablaufen, nachdem Sitzungen geschlossen werden (sitzungsbeschränkte Gewährungen) und nachdem die App beendet wird. Es ist ein Bedienfeld für die Gegenwart, kein Audit-Log — für die Historie verwenden Sie Tracing.

Der Kompromittierungs-Detektor

Die Fälschungen leisten Doppeldienst: Neben dem Ersatz für Geheimnisse sind sie Stolperdrähte. Ein gefälschtes Token hat genau eine legitime Zielfamilie — den Host-Geltungsbereich, für den es erstellt wurde. Es gibt keinen ehrlichen Grund, dass sk-ant-api03-brm-… in einer Anfrage an pastebin.example erscheint. Also durchsucht der Proxy jede ausgehende Anfrage — Header und Body, über einen Aho-Corasick-Automaten, günstig genug, um auf allem zu laufen — nach jeder Fälschung, die außerhalb ihres Geltungsbereichs unterwegs ist.

Wenn er eine findet, behandelt er die Anfrage als versuchte Exfiltration von Zugangsdaten:

1. Die Anfrage wird mit HTTP 451 blockiert. Kein einziges Byte wird an das Ziel weitergeleitet.
2. Die VM wird sofort pausiert.
3. Eine Warnung wird ausgelöst: „Bromure hat einen ausgehenden Versuch erkannt, ein Sitzungs-Zugangsdatum an einen Host zu leaken, für den es nicht erstellt wurde. Die VM wurde pausiert."

Der Arbeitsbereich wird dann als kompromittiert markiert — der Arbeitsbereich-Browser zeigt Kompromittiert — beim Start wird zum Löschen von Festplatte und Home aufgefordert — und der nächste Start erfordert eine Behebung: „Um fortzufahren, müssen das VM-Festplattenabbild und der persistente Home-Ordner gelöscht werden. Ihre Token, SSH-Schlüssel und Arbeitsbereich-Einstellungen bleiben erhalten." Klicken Sie auf Löschen und starten, um fortzufahren. Beachten Sie die begleitende Warnung: Freigegebene Ordner werden NICHT gelöscht, sodass, wenn die Kompromittierung über ein Paket oder eine Datei in einem freigegebenen Ordner kam, sie möglicherweise noch dort ist — prüfen Sie diese Ordner, bevor Sie die Arbeit fortsetzen.

Empfohlene Reaktion auf eine Kompromittierungs-Warnung: Öffnen Sie den Trace-Inspektor (⇧⌘I) oder führen Sie bromure-cli trace leaks aus, um den betreffenden Host und die Anfrage zu sehen, entscheiden Sie, ob eine Projekt-Abhängigkeit oder eine per Prompt injizierte Anweisung verantwortlich war (siehe Prompt-Injection und Lieferkette), und löschen und starten Sie dann neu.

Details zum Geltungsbereich:

• Fälschungen ohne Geltungsbereich sind ausgenommen. Ein manuelles Token mit leerem Host-Filter ist per Design „jeder Host" und kann den Detektor nicht auslösen; Schein-Abonnement-Platzhalter sind ebenfalls ausgeschlossen.
• Verwandte Erstanbieter-Hosts werden toleriert. Der Abgleich spiegelt die Geltungsbereichs-Richtlinie des Austauschs wider, mit einer Lockerung: Hosts unter derselben registrierten Domain wie der Anbieter des Zugangsdatums (Claude- oder Codex-Infrastruktur unter anthropic.com zum Beispiel) verwenden einen Familienabgleich, sodass ein legitimes api.anthropic.com-Token, das auf mcp-tools.anthropic.com gesehen wird, kein Fehlalarm ist. Alles andere ist streng.
• Echt aussehende Leaks werden ebenfalls markiert. Unabhängig von den Fälschungs-Stolperdrähten markiert der Proxy nicht ausgetauschte, echt aussehende Geheimnisse im ausgehenden Verkehr — Bearer- oder x-api-key-Werte mit bekannten Präfixen (sk-ant-, ghp_, AKIA, …) oder undurchsichtige Token von 20 Zeichen oder mehr. Diese erscheinen als Leak-Warnungen im Trace-Inspektor und in bromure-cli trace leaks; sie bedeuten meist, dass ein echtes Geheimnis von Hand in die VM eingefügt wurde, was die Übertragungsgrenze gerade unnötig machen soll.

Es gibt nichts zu aktivieren — der Detektor ist immer an.

Wo Geheimnisse auf dem Host liegen

Alles Sensible ist ruhend mit AES-GCM unter einem 256-Bit-Master-Schlüssel pro Installation verschlüsselt — dem Geheimnis-Tresor. Der Master-Schlüssel liegt im macOS-Data-Protection-Schlüsselbund, beschränkt auf die Signaturidentität der App, mit Zugänglichkeit kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly und deaktivierter iCloud-Synchronisierung. Er fragt nie, synchronisiert nie und verlässt den Mac nie. Wenn der Schlüsselbund unerreichbar ist (ein unsignierter oder nicht bereitgestellter Build), greift die App auf eine Schlüsseldatei mit Modus 0600 neben dem Chiffretext zurück — schwächer, da Schlüssel und Chiffretext dann eine Festplatte teilen, aber es hält die ruhende Verschlüsselung funktionsfähig; ein vollständig bereitgestelltes Release verwendet den Schlüsselbund.

Praktische Konsequenzen:

• Backups und Kopien sind Chiffretext. Ein Time-Machine-Backup oder ein kopierter Application Support-Ordner enthält nur verschlüsselte Blobs; ohne den Schlüsselbund-Eintrag dieses Macs können sie nicht entschlüsselt werden (es sei denn, der Datei-Fallback-Schlüssel war in Verwendung und wurde mitkopiert).
• Das Löschen des Schlüsselbund-Eintrags rotiert den Schlüssel. Bestehende verschlüsselte Blobs werden unlesbar, und Sie geben Ihre Zugangsdaten erneut ein. Nicht sensible Metadaten in profile.json sind unberührt.
• Nichts wird irgendwohin synchronisiert. Keine Zugangsdaten, kein Token-Speicher und kein Schlüsselmaterial werden von der App selbst hochgeladen, synchronisiert oder gesichert.

Speicherorte auf der Festplatte, alle unter ~/Library/Application Support/BromureAC/, sofern nicht anders vermerkt:

Hostseitige Lesevorgänge für Importe — ~/.aws/config, ~/.aws/sso/cache/*.json, ~/.docker/config.json, kubeconfig-Dateien — geschehen nur auf dem Host; keine dieser Dateien wird jemals in eine VM eingehängt. Verschlüsselte Trace-Bodys (siehe Tracing) verwenden denselben Tresor-Schlüssel.

Die Grenze selbst überprüfen

Die Übertragungsgrenze ist so gestaltet, dass sie überprüfbar ist, nicht auf Glauben angewiesen. Aus einer Shell innerhalb einer beliebigen Sitzung:

1. Die Umgebung enthält Fälschungen.

echo "$ANTHROPIC_API_KEY"
# sk-ant-api03-brm-…            ← a fake, not your key

env | grep -E 'TOKEN|KEY' 
# every value is brm_/ghp_/glpat_/dop_v1_/lin_api_-shaped placeholder

2. Die Konfigurationsdateien enthalten Fälschungen.

cat ~/.git-credentials          # fake tokens per git host
cat ~/.docker/config.json       # fake base64 auth blobs
grep -A2 credential_process ~/.aws/config   # helper, not a secret key

3. Und dennoch funktioniert alles.

aws sts get-caller-identity     # succeeds — the host resigned the request
gh api user                     # succeeds — the fake was swapped on the wire

4. TLS innerhalb der VM terminiert am Proxy.

openssl s_client -connect api.anthropic.com:443 -brief 2>&1 | head
# issuer: the Bromure Agentic Coding Root CA — not a public CA

5. SSH-Schlüssel sind abwesend, aber die Signierung funktioniert.

ssh-add -L                      # lists public keys served by the vsock agent
ls ~/.ssh/id_*                  # no private key files to find

6. Beobachten Sie auf dem Host, wie die Austausche geschehen. Aktivieren Sie Tracing für den Arbeitsbereich, dann:

bromure-cli trace summary        # per-request swap reports and leak warnings
bromure-cli trace leaks          # only the suspicious ones

oder öffnen Sie den Trace-Inspektor (⇧⌘I), wo ausgetauschte Anfragen mit Nie an VM gesendet — vom Proxy ausgetauscht annotiert sind.

Wenn Sie jemals ein echtes Zugangsdatum innerhalb einer VM finden, ist es auf eine von zwei Weisen dorthin gelangt: Sie (oder der Agent auf Ihre Anweisung) haben es von Hand eingefügt, oder es kam über einen freigegebenen Ordner. Die Austauschmaschinerie schreibt nie echte Werte in den Gast — und der Kompromittierungs-Detektor behandelt echt geformte Geheimnisse auf der Leitung genau deshalb als Leak, weil sie dort nicht existieren sollten.

Kurzreferenz

vsock-Ports an der Gast-Host-Grenze:

Verwandte CLI-Befehle (vollständige Referenz in Automatisierung & CLI):