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 und geht dann durch, wie sich Agenten anmelden, jeden unterstützten Zugangsdatentyp und seinen Lebenszyklus, das Genehmigungssystem pro Verwendung, den Kompromittierungsdetektor, die Notausgänge für Hosts, die unter Abfangen nicht funktionieren, und wie Sie die Grenze selbst überprüfen.

Zugangsdaten werden pro Maschine eingerichtet. Eine Maschine ist das, was der Einstellungseditor noch Arbeitsbereich nennt; beide Wörter bezeichnen dieselbe VM und ihre Einstellungen.

Hinweis: Dieses Kapitel behandelt die Konzepte und das Laufzeitverhalten. Eine Referenz des Einstellungsbereichs Feld für Feld finden Sie unter Einstellungen → Zugangsdaten. API-Schlüssel und Abonnements der Agenten werden nicht mehr in diesem Bereich eingestellt; sie liegen unter Einstellungen › Modelle (siehe Modelle & Anbieter).

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 die VM einer Maschine startet, erstellt die App einen Token-Plan pro Maschine, der jedes echte Zugangsdatum mit seiner abgeleiteten Attrappe paart. Die Attrappen 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 Tauschtabelle im Speicher des Proxys geladen, jeweils an den Zielhost gebunden, zu dem sie gehören.
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

Dienst-Zugangsdaten — Git-Tokens, Cloud-Schlüssel, Registries, Datenbanken, SSH-Schlüssel — werden pro Maschine eingerichtet. Öffnen Sie die Einstellungen der Maschine (Einstellungen… im Maschinenmenü oder Einstellungen für „Maschine“ … aus dem Menü einer Sitzung) und wählen Sie in der Seitenleiste unter Sicherheit den Eintrag Anmeldedaten.

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 git-Standardwerte zu behalten — die Platzhalter sind nur Beispiele, keine Zugangsdaten), gefolgt von einer Liste nur der Zugangsdaten, die Sie eingerichtet haben, gruppiert unter Kategorie-Überschriften (Agents, Git, Cloud, Databases, SSH, Other). Ist nichts eingerichtet, zeigt der Bereich Noch keine Anmeldedaten. Unten stehen zwei Schaltflächen: Anmeldedaten hinzufügen öffnet eine Auswahl der Zugangsdatentypen — Git token, SSH key, AWS credentials, DigitalOcean token, Linear API key, Twilio API key, Kubernetes, Container registry, Database und Other API key —, und env-Datei importieren… importiert gesammelt aus einer .env oder ~/.bashrc. Klicken Sie auf Sichern; der nächste Sitzungsstart schreibt die Attrappen in die VM und lädt die echten Werte in den Proxy.

Agenten-API-Schlüssel (Anthropic, OpenAI, xAI, Moonshot und die anderen Modellanbieter) stehen nicht in dieser Auswahl: Sie werden unter Einstellungen › Modelle eingestellt, wie im Folgenden beschrieben. Die Gruppe Agents erscheint nur bei einem Arbeitsbereich, der aus einer früheren Version noch einen eigenen Agentenschlüssel speichert; sein Menüpunkt In „Modelle“ bearbeiten… öffnet Einstellungen › Modelle. Um den Modellzugang zu ändern, verwenden Sie Einstellungen › Modelle oder den Bereich Modelle der Maschine.

Die Genehmigungs-Sperre pro Zugangsdatum (Vor Verwendung fragen) und die Schreibrichtlinie jedes Dienstes werden im Bereich Schutzmechanismen eingestellt, nicht hier. Die Referenz Feld für Feld finden Sie unter Einstellungen → Zugangsdaten.

Sieben Anbieter werden automatisch behandelt — Anthropic, OpenAI, GitHub, GitLab, DigitalOcean, Twilio und Kubernetes brauchen keine manuellen Token-Regeln; ihre eigenen Abschnitte behandeln sie. Alles andere läuft über Weitere API-Schlüssel.

Import aus einer env-Datei. env-Datei importieren… liest eine vorhandene .env-Datei — oder eine ~/.bashrc — und macht aus ihren Variablen Zugangsdaten. Der Parser versteht KEY=VALUE und export KEY=VALUE, entfernt umgebende Anführungszeichen und Kommentare am Zeilenende und überspringt bewusst alles, was eine Auswertung durch die Shell bräuchte ($VAR-Interpolation oder $(…)-Substitution), sodass er gefahrlos auf eine echte .bashrc angesetzt werden kann. Ein Prüf-Sheet zeigt die Variablen dann mit maskierten Werten: Erkannte Namen (GH_TOKEN/GITHUB_TOKEN, GITLAB_TOKEN, AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN, DIGITALOCEAN_ACCESS_TOKEN, LINEAR_API_KEY, TWILIO_ACCOUNT_SID/TWILIO_AUTH_TOKEN sowie die Modellanbieter-Schlüssel ANTHROPIC_API_KEY, OPENAI_API_KEY, XAI_API_KEY, MOONSHOT_API_KEY und KIMI_API_KEY, die zum passenden Anbieter unter Einstellungen › Modelle gehen — oder bei einer entfernten Maschine in deren eigene Modelle-Überschreibung) werden automatisch ihrem Zugangsdatentyp zugeordnet, während nicht erkannte Namen als generische manuelle Tokens mit einem von Ihnen angegebenen, durch Kommas getrennten Host-Bereich importiert werden können. Bereits eingerichtete Einträge werden markiert und bleiben abgewählt, damit ein erneuter Import nie stillschweigend ein Geheimnis überschreibt.

Agentenschlüssel und Abonnements

Jeder Coding-Agent — Claude Code, Codex, Grok, Kimi und omp — erhält seinen Modellzugang von einem Anbieter, der unter Einstellungen › Modelle eingerichtet ist (⌘, dann Modelle). Denselben Bereich gibt es in den Einstellungen jeder Maschine als optionale Überschreibung pro Maschine. Die vollständige Referenz — Anbieter, Modellwahl pro Agent, Überschreibung pro Maschine, OpenRouter, eigene Server und Modelle auf dem Gerät — steht unter Modelle & Anbieter. Dieser Abschnitt behandelt, was für Zugangsdaten zählt: wie ein Schlüssel oder ein Abonnement den Agenten erreicht, ohne je in die VM zu gelangen.

Klicken Sie in der Spalte Anbieter auf einen Anbieter, um sein Popover zu öffnen. Für jeden Anbieter enthält es ein Feld API-Schlüssel; für die vier Anbieter mit Abonnements enthält es außerdem die Anmeldesteuerung.

API-Schlüssel

Fügen Sie den Schlüssel in das Feld API-Schlüssel des Popovers ein. In den Einstellungen sichert der Bereich während des Tippens; in den Einstellungen einer Maschine wird der Schlüssel mit Sichern gesichert. Lebenszyklus:

• In der VM: Die übliche Variable des Agenten (ANTHROPIC_API_KEY, OPENAI_API_KEY, XAI_API_KEY, …) enthält die anbieterförmige Attrappe (sk-ant-api03-brm-…, sk-brm-…, xai-brm-…, sk-kimi-brm-…).
• Auf der Leitung: gegen den echten Schlüssel getauscht, nur bei Anfragen an die Hosts dieses Anbieters (anthropic.com, openai.com, x.ai, moonshot.ai, …).
• Im Ruhezustand: Die Schlüssel werden wie der Rest der Modelleinstellungen verschlüsselt in models.enc gespeichert (siehe Wo Geheimnisse auf dem Host liegen).

Unter Modelle eingestellte Schlüssel erscheinen nicht in den Bereichen Anmeldedaten oder Schutzmechanismen und haben daher keine Zeile Vor Verwendung fragen. (Ein Agentenschlüssel, der aus einer früheren Version noch im Arbeitsbereich selbst gespeichert ist, erscheint dort und kann genehmigungspflichtig gemacht werden. Der Import einer env-Datei legt solche Schlüssel nicht mehr an: Er legt Agentenschlüssel in den Modelleinstellungen ab.)

Über die CLI wählen bromure-cli workspaces create --auth token|subscription|bedrock|local und bromure-cli vm run --auth token|subscription|bedrock|local weiterhin den Authentifizierungsmodus des primären Agenten des Arbeitsbereichs.

Abonnements: Claude, ChatGPT, Grok und Kimi

Haben Sie ein Abonnement statt eines API-Schlüssels, melden Sie sich stattdessen an. Abonnements gibt es nur für Anthropic (Claude), OpenAI (ChatGPT, genutzt von Codex), xAI (Grok) und Moonshot (Kimi); z.ai, Amazon Bedrock, OpenRouter und eigene Server nehmen nur Schlüssel, und omp arbeitet nur mit API-Schlüssel. Ein Abonnement versorgt nur seinen eigenen Agenten: Eine Claude-Anmeldung betreibt Claude Code, eine ChatGPT-Anmeldung Codex und so weiter.

Wie auch immer Sie sich anmelden, das Ergebnis ist dasselbe: Die echten OAuth-Tokens liegen nur auf dem Host, und der Gast läuft mit einem Scheinschlüssel — einem falschen ANTHROPIC_API_KEY für Claude, einer vorbelegten ~/.codex/auth.json mit einem Schein-JWT mit weit in der Zukunft liegendem Ablauf für Codex (damit der Client nie versucht, es zu erneuern), und Platzhalter-Tokens in den eigenen Zugangsdatendateien von Grok und Kimi. Der Proxy erkennt den Scheinwert und setzt auf der Leitung ein gültiges Authorization: Bearer-Zugriffstoken ein.

Anmelden unter Einstellungen › Modelle

Das Popover des Anbieters zeigt einen von drei Zuständen:

Sign in with Anbieter startet den Registrierungsablauf:

1. Eine Erklärung mit dem Titel Bei Anbieter registrieren sagt, was gleich passiert. Klicken Sie auf Fortfahren. (Die Registrierung wird abgelehnt, wenn der Bromure-Proxy nicht läuft.)
2. Eine Wegwerf-Registrierungs-VM startet — temporär, isoliert, ohne Arbeitsbereich-Ordner, ohne gespeicherte Geheimnisse und ohne Tauschtabelle für Zugangsdaten. Darin läuft der eigene Anmeldebefehl des Agenten.
3. Der Standardbrowser Ihres Macs öffnet die Anmeldeseite des Anbieters. Melden Sie sich wie gewohnt an.
4. Die erhaltenen Tokens werden auf dem Host erfasst, verschlüsselt und gespeichert; die Wegwerf-VM wird heruntergefahren und gelöscht.

Eine in den Einstellungen gestartete Anmeldung wird immer von allen Maschinen geteilt. Abmelden… fragt „Von Anbieter abmelden?“ — „Workspaces, die diese Anmeldung nutzen, funktionieren erst wieder, wenn Sie sich erneut anmelden.“ — und löscht die gespeicherte Anmeldung. Abmelden… ist ausgeblendet, wo es nichts bewirken kann.

Anmelden im Bereich Modelle einer Maschine: Freigabebereich

Dasselbe Popover erscheint im eigenen Bereich Modelle einer Maschine. Eine dort gestartete Anmeldung endet mit einer Frage, Mit jedem Arbeitsbereich teilen?:

Der Bereich zählt, weil eine Maschine zuerst ihre eigene Anmeldung liest und nur dann auf die geteilte zurückgreift, wenn sie keine hat. Eine Maschine, die sich einmal für sich selbst angemeldet hat, nutzt diese Anmeldung weiter, auch nach einer neueren geteilten Anmeldung, bis Sie Jeder Arbeitsbereich wählen oder diese Maschine abmelden. Ein entfernter Client, der die Anmeldung startet, bekommt dieselbe Frage; antwortet niemand, bleibt die Anmeldung bei dieser Maschine.

Anmelden aus dem Chat

Sie müssen nicht erst in die Einstellungen. Muss sich ein Agent in einer Sitzung anmelden, zeigt der Chat eine Karte mit dem Titel Bei Anbieter anmelden — „Bromure meldet Sie auf diesem Mac an und hält Ihr Anbieter-Konto aus der Maschine heraus — der Agent sieht immer nur einen Stellvertreterschlüssel.“ — mit einer Schaltfläche Bei Anbieter anmelden…, und die Zeile der Sitzung in der Seitenleiste zeigt Anmeldung nötig. Wurde die gespeicherte Anmeldung eines Agenten abgelehnt, bietet die rote Fehlerkarte dieselbe Schaltfläche.

Ein Klick darauf meldet ohne Wegwerf-VM an:

1. Das eigene Terminal der Sitzung führt den Anmeldebefehl des Agenten aus, und die Anmeldeseite des Anbieters öffnet sich im Browser Ihres Macs („Ihr Browser wird zur Anmeldung geöffnet…“).
2. Wenn der Agent seinen Autorisierungscode gegen Tokens tauscht, beantwortet der Proxy diesen Tausch selbst: Die echten Tokens gehen direkt in den Speicher des Hosts. Claude Code und Codex wird mitgeteilt, dass das Zugangsdatum auf dem Mac bleibt; Grok und Kimi erhalten Platzhalter-Tokens, die ihre CLIs in ihre Zugangsdatendateien schreiben.
3. Der Agent startet mit dem Platzhalter neu („Angemeldet. … wird erneut gestartet…“).

Eine Anmeldung aus dem Chat ersetzt die Anmeldung, die die Maschine gelesen hat: ihre eigene, falls vorhanden, sonst die geteilte. Erreicht innerhalb von 5 Minuten keine Anmeldung den Proxy, meldet die Karte „Bromure hat nicht rechtzeitig eine Anbieter-Anmeldung erhalten. Sie können es erneut versuchen.“ Pro Maschine kann immer nur eine Anmeldung laufen.

omp hat kein Konto, bei dem man sich anmelden könnte; seine Karte lautet „omp braucht einen Modellanbieter“ und bietet stattdessen Maschineneinstellungen… an.

Warnung: Führen Sie /login (oder den Anmeldebefehl des Agenten) nicht von Hand in der VM aus, um eine abgelaufene Anmeldung zu reparieren. Verwenden Sie die Karte oder Einstellungen › Modelle, damit die Tokens vom Host erfasst werden, statt in der VM zu bleiben.

Kimi meldet sich in der internationalen Region an

Die CLI von Kimi Code verwendet standardmäßig die Region Festlandchina, die Konten von anderswo ablehnt. Bromure meldet Kimi in der internationalen Region an (auth.kimi.ai, API unter api.kimi.ai), indem es die Regionsvariablen der CLI in der Registrierungs-VM und in jeder Sitzung setzt. Eine Kimi-Anmeldung, die in der älteren Region auth.kimi.com erfasst wurde, wird weiterhin erkannt.

Token-Verwahrung: eine Berechtigung, ein Erneuerer

Die Token-Erneuerung läuft vollständig auf dem Host, und jede Anmeldung wird von genau einem Besitzer erneuert:

• Eine Berechtigung pro Platz. Die geteilte Anmeldung und die eigene Anmeldung jeder Maschine sind getrennte Plätze. Pro Platz läuft immer nur eine Erneuerung, und jede Maschine, die diesen Platz liest, nutzt deren Ergebnis. Der Gast hält nie ein Refresh-Token.
• Zeitpunkt der Erneuerung. Der Host erneuert etwa 5 Minuten vor Ablauf, beim Token-Endpunkt des Anbieters (platform.claude.com für Claude, auth.openai.com für Codex, auth.x.ai für Grok, auth.kimi.ai für Kimi). Eine frisch registrierte Anmeldung wird als bereits abgelaufen gespeichert, sodass die erste Verwendung beweist, dass der Erneuerungsweg funktioniert.
• Automatisierungsklone teilen die Berechtigung. Eine für eine Automatisierung geklonte Maschine verweist auf die Anmeldung ihrer Basismaschine, statt sie zu kopieren.
• Die CLI-Anmeldungen Ihres Macs werden nicht importiert. Eine Berechtigung mit einer CLI auf dem Host zu teilen, würde jedes Mal eine der beiden abmelden, wenn die andere erneuert.
• Wenn kein Token verfügbar ist für eine Claude-Anfrage, antwortet der Proxy dem Agenten selbst, statt den Scheinschlüssel weiterzuleiten: Ein vorübergehender Fehler kommt als wiederholbares 529 zurück, eine abgelehnte Anmeldung als 401, das Sie auffordert, sich in Bromure erneut anzumelden. Das Popover zeigt dann Anmeldung abgelaufen.

Dienst-Zugangsdaten

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-Neusignierer des Hosts erkennt Anfragen an AWS in jeder Partition, unter dem IPv4- oder Dual-Stack-Namen (*.amazonaws.com, *.api.aws, *.amazonaws.com.cn, *.api.amazonwebservices.com.cn, die Domains der European Sovereign Cloud und der ISO-Partitionen; einschließlich GovCloud, regionaler, FIPS- und Bucket-artiger S3-Hosts), entfernt die Signatur des Gasts, setzt das echte X-Amz-Security-Token ein, wenn ein Session-Token vorhanden ist, und signiert mit dem echten Geheimnis neu, bevor die Anfrage Ihren Mac verlässt. Der AWS-Schutzmechanismus deckt dieselben Hosts ab, und das Umschreiben der von der VM erzeugten Zugangsdaten (unten) deckt sie ebenfalls ab, dazu public.ecr.aws. Jede erfolgreiche Neusignierung erzeugt ein Audit-Ereignis credential.aws_sign mit maskiertem Access Key, angezeigt als Zeile Anmeldedaten verwendet in der Sicherheits-Zeitleiste.

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).

Von der VM erzeugte Zugangsdaten

Manche Aufrufe stellen ein neues Zugangsdatum aus: aws sts assume-role / get-session-token / get-federation-token, aws iam create-access-key, die Rollen-Zugangsdaten von IAM Identity Center, GetCredentialsForIdentity von Cognito, aws ecr get-login-password sowie bei DigitalOcean doctl registry login, doctl kubernetes cluster kubeconfig save (und dessen Zugangsdaten-Aufruf) und doctl spaces keys create. Der Proxy hält die Antwort auf einen solchen Aufruf zurück und ersetzt jedes Geheimnis darin durch eine Fälschung, bevor die VM sie sieht. Ein temporärer AWS-Schlüssel behält seine echte Access Key ID, mit gefälschtem Secret und Session-Token, damit der Neusignierer erkennt, mit welchem Schlüssel der Gast signiert hat. Ein Registry- oder Cluster-Token wird zu einer Fälschung, die nur gegenüber genau dieser Registry bzw. diesem Cluster zurückgetauscht wird.

Die echten Werte werden verschlüsselt in der Konfiguration des Arbeitsbereichs gespeichert, sodass Fälschungen, die die VM abgelegt hat (in ~/.aws, ~/.docker/config.json oder einer kubeconfig), auch nach einem Neustart funktionieren. Ein ausgestellter AWS-Schlüssel wird mit seinem eigenen Secret und Session-Token neu signiert. Sobald er abgelaufen ist, werden damit signierte Anfragen abgelehnt, statt mit dem eigenen Schlüssel des Arbeitsbereichs neu signiert zu werden, was sie unter einer anderen Identität ausführen würde. Abgelaufene Zugangsdaten werden 30 Tage nach ihrem Ablauf verworfen.

Eine Antwort, die der Proxy nicht vollständig umschreiben kann, wird nie weitergereicht: Der Gast erhält stattdessen eine 502. Aufrufe, die ein von der VM selbst gewähltes Geheimnis setzen, für das keine Fälschung einspringen kann, werden in jedem Modus der Schutzmechanismen abgelehnt: iam:CreateLoginProfile, UpdateLoginProfile, CreateServiceSpecificCredential und ResetServiceSpecificCredential. Eine AWS-Zustimmungsabfrage nennt den Aufruf, den sie signieren würde (zum Beispiel sts:AssumeRole), und jedes ausgestellte Zugangsdatum erzeugt ein credential.minted-Ereignis.

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

Amazon Bedrock ist ein Modellanbieter für jeden Agenten, kein Authentifizierungsmodus eines einzelnen. Schalten Sie Amazon Bedrock verwenden im Popover Amazon Bedrock unter Einstellungen › Modelle (oder im Bereich Modelle einer Maschine) ein und wählen Sie dann pro Agent Bedrock-Modell-IDs. Claude Code läuft nativ auf Bedrock; die anderen Agenten erreichen es über die OpenAI-kompatible API von Bedrock. Anfragen werden mit den eigenen AWS-Zugangsdaten jeder Maschine (Anmeldedaten → AWS, statisch oder SSO) über denselben Neusignierungsweg signiert, da Bedrock-Endpunkte *.amazonaws.com-Hosts sind — oder, falls Sie einen in das Feld Bedrock-API-Schlüssel (optional — sonst signieren die AWS-Anmeldedaten) des Popovers einfügen, mit diesem Schlüssel, den die VM nur als Attrappe bedrock-brm-… sieht. Das Popover nimmt außerdem eine AWS-Region an; lassen Sie sie leer, um die AWS-Region jeder Maschine zu verwenden. Siehe Modelle & Anbieter.

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.

Beim Import einer .env- oder .env.op-Datei (env-Datei importieren… im Bereich Anmeldedaten) werden op://-Werte automatisch erkannt — unter erkannten Namen wie ANTHROPIC_API_KEY oder beliebigen wie STRIPE_KEY — und jeweils als manuelles Token gespeichert, das die Referenz enthä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 Anmeldedaten → Linear ein (Link: Linear-API-Einstellungen im Browser öffnen; Schlüssel gibt es unter linear.app → Settings → API). Die Attrappe (lin_api_ + 40) wird als LINEAR_API_KEY exportiert, die das Linear-SDK, MCP-Server und CLI-Werkzeuge automatisch übernehmen; der Tausch ist streng auf linear.app beschränkt (GraphQL unter api.linear.app und MCP unter mcp.linear.app). Ein Linear-Schlüssel im Arbeitsbereich ist auch Voraussetzung für Automatisierungs-Auslöser bei Linear-Issues — siehe Automatisierungen.

Twilio

Fügen Sie ein Zugangsdatum Twilio API key hinzu, mit der SID in Account SID (AC…) or API Key SID (SK…) und dem Geheimnis in Auth Token / API Key secret (beides aus console.twilio.com). Twilio authentifiziert per HTTP Basic, wobei die SID eine Identität ist — sie reist in der Anfrage-URL mit — und nur das Token geheim ist. Lebenszyklus:

• In der VM: TWILIO_ACCOUNT_SID enthält die echte SID und TWILIO_AUTH_TOKEN eine Attrappe brm-twilio-…, sodass Twilio-SDKs und die CLI sie ohne Einrichtung übernehmen.
• Auf der Leitung: Bei Anfragen an twilio.com tauscht der Proxy sowohl das nackte Attrappen-Token als auch den vorab base64-kodierten Basic-Auth-Block SID:Token gegen die echten aus.
• Genehmigung: über Vor Verwendung fragen im Bereich Schutzmechanismen.

env-Datei importieren… erkennt TWILIO_ACCOUNT_SID / TWILIO_API_KEY_SID und TWILIO_AUTH_TOKEN / TWILIO_API_SECRET und fügt sie zu einem Twilio-Zugangsdatum zusammen.

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.
• Schlüssel aus einem Host-Agenten. Ein Schlüssel, dessen privater Teil sein Gerät nicht verlassen kann — ein YubiKey oder ein anderer Sicherheitsschlüssel hinter gpg-agent, Secretive, 1Password —, wird stattdessen mit Vom Host-Agenten… hinzugefügt. Wählen Sie den Socket des Agenten (leer = das eigene SSH_AUTH_SOCK der App, das bei einer aus dem Finder geöffneten App der macOS-Agent ist, nicht einer, den Ihre Shell exportiert; für gpg-agent verwenden Sie ~/.gnupg/S.gpg-agent.ssh), klicken Sie auf Laden und haken Sie die Schlüssel an, die der Arbeitsbereich verwenden darf. Nichts wird kopiert: Die VM sieht nur die angehakten Schlüssel — und nur, solange der Agent sie hält, sodass ein abgezogener Schlüssel nicht angeboten wird —, und ihre Signaturanfragen werden an diesen Agenten weitergeleitet, sodass eine Berührungs- oder PIN-Abfrage wie gewohnt auf Ihrem Mac erscheint (die Anfrage wartet bis zu zwei Minuten darauf). Die übrigen Schlüssel des Agenten bleiben für die VM unsichtbar, und eine Anfrage, mit einem davon zu signieren, wird abgelehnt.

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, importierter oder Host-Agent-Schlüssel war trägt.

Hinweis: Ihr macOS-Anmelde-ssh-agent (der launchd-Agent) — oder jeder andere Host-Agent — wird absichtlich nie als Ganzes der VM ausgesetzt. Nur Schlüssel pro Arbeitsbereich, von Ihnen ausdrücklich importierte Schlüssel und die einzelnen von Ihnen ausgewählten Host-Agent-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 per Design. Freigaben und Ablehnungen liegen nur im Speicher und werden beim Herunterfahren der VM widerrufen. „Rest der Sitzung“ übersteht nie einen VM-Neustart, und nichts wird über App-Läufe hinweg gespeichert.
• Headless-Sitzungen. In einer SSH- oder Headless-Sitzung erscheint die Abfrage im tmux der Maschine statt als grafischer Hinweis — 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 Freigaben abgelaufen sind, nachdem die VM heruntergefahren wurde (sitzungsbezogene Freigaben) und nachdem die App beendet wurde. Es ist ein Bedienfeld für die Gegenwart, kein Audit-Log — für die Historie nutzen Sie die Sicherheits-Zeitleiste und das 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. Lief die Maschine im Hintergrund, wird sie zuerst auf den Bildschirm geholt, und ihr eingefrorenes Bild färbt sich rot.
3. Ein kritischer Hinweis erscheint mit dem Titel Diese Umgebung könnte kompromittiert sein: „Bromure hat einen ausgehenden Versuch erkannt, ein Sitzungs-Zugangsdatum von „Maschine“ an einen Host zu leaken, für den es nicht ausgestellt wurde. Die VM wurde angehalten.“ Unter Erkannte Lecks: listet er eine Zeile pro Leck — eine Token-Vorschau (etwa sk-a…f9q3), den Namen des Zugangsdatums, den Host, für den es ausgestellt wurde, und den Host, an den es gesendet wurde.
4. Die Erkennung wird als rote Zeile Anmeldedaten-Vermittlung in der Sicherheits-Zeitleiste festgehalten und bei registrierten Installationen als Ereignis credential.exfiltration.

Der Hinweis bietet vier Schaltflächen:

Nur Herunterfahren reagiert auf den Zeilenschalter; Blockieren, Erlauben und Für Untersuchung speichern haben kein Tastaturkürzel, sodass das Fortsetzen einer möglicherweise feindlichen VM — geschweige denn das Senden des Zugangsdatums an sie — immer einen ausdrücklichen Klick erfordert. Es wird immer nur ein Hinweis angezeigt; wiederholte Erkennungen, während er offen ist, werden verworfen (jede bleibt blockiert).

Tipp: Erlauben gibt es für legitime hostübergreifende Setups — etwa einen OpenAI-förmigen Schlüssel, den ein Werkzeug bewusst an den OpenAI-kompatiblen Endpunkt eines anderen Anbieters sendet. Erkennen Sie das Ziel nicht, erlauben Sie es nicht.

Wird die Maschine von einem entfernten Client gespiegelt, erscheint die Frage auf dem Client als ausstehende Abfrage mit Herunterfahren, Blockieren und Erlauben (das Speichern zur Untersuchung braucht eine lokale Ordnerauswahl und wird daher nur auf dem Mac selbst angeboten). Nur die betroffene VM bleibt pausiert; der Host bedient alle anderen Maschinen weiter. Eine unbeantwortete Abfrage fährt die VM nach 3 Minuten herunter.

Eine als kompromittiert markierte Maschine verweigert den Start, bis Sie Abhilfe schaffen. Beim Starten erscheint „To continue, the VM disk image and the persistent home folder must be wiped. Your tokens, ssh keys, and workspace settings are preserved.“ mit Löschen und starten und Abbrechen (der Zeilenschalter bestätigt das Löschen nicht). Beachten Sie die begleitende Warnung: Freigegebene Ordner werden NICHT gelöscht — kam die Kompromittierung über ein Paket oder eine Datei in einem freigegebenen Ordner, ist sie womöglich noch dort; prüfen Sie diese Ordner, bevor Sie weiterarbeiten.

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.

Der Detektor selbst ist immer aktiv. Was Sie pro Maschine abschalten können, ist die Unterbrechung — siehe den nächsten Abschnitt.

Notausgänge

Manche Hosts und Clients funktionieren unter vollständigem Abfangen nicht: ein Server mit privater CA, dem der Host nicht vertraut, ein Client, der das Zertifikat seines Servers pinnt, oder ein legitimes Setup, das den Kompromittierungsalarm immer wieder auslöst. Drei Einstellungen pro Maschine unten im Bereich Schutzmechanismen lockern die Grenze in diesen Fällen, ohne sie abzuschalten. Alle drei gelten sofort, ohne Neustart.

Warnung: Jede dieser Einstellungen tauscht etwas Schutz gegen Kompatibilität. Wählen Sie die engste: den Header pro Anfrage für ein nicht vertrauenswürdiges Zertifikat, Erlauben im Kompromittierungsalarm für ein vertrauenswürdiges Ziel und die maschinenweiten Schalter nur für eine Maschine, die sonst nicht funktioniert.

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 getauscht wird. Öffnen Sie die Sicherheits-Zeitleiste und filtern Sie nach Anmeldedaten-Vermittlung: Jeder Tausch erscheint als Zeile wie sk-a…f9q3 → api.anthropic.com — swapped in …. Ist Tracing für die Maschine aktiviert, können Sie auch Folgendes ausführen:

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:

Beide Token-Kanäle sind einseitig: Der Host kann nur Attrappen in die VM schreiben, und die VM kann nur echte Werte an den Host senden. Es gibt keine Anfrage, mit der die VM ein echtes Token zurückfordern könnte.

Zugehörige CLI-Befehle (vollständige Referenz unter CLI, API & MCP):