Zugangsdaten

Der Bereich Zugangsdaten ist der Ort, an dem Sie einem Arbeitsbereich die Geheimnisse geben, die sein Agent benötigt — Git-Token, SSH-Schlüssel, Cloud-Zugangsdaten, Datenbank-Passwörter — ohne dass eines dieser Geheimnisse jemals in die VM gelangt. Jeder Wert, den Sie hier eintippen, wird verschlüsselt auf Ihrem Mac gespeichert. Innerhalb der Sandbox sieht der Agent nur ein strukturerhaltendes Fake (zum Beispiel brm_…); wenn eine Anfrage Ihren Mac tatsächlich verlässt, tauscht der host-seitige Proxy das Fake zurück gegen den echten Wert, begrenzt auf den Ziel-Host.

Diese Seite ist die feldweise Referenz für den Bereich. Der Mechanismus dahinter — die Übertragungsgrenze, die deterministischen Fakes, die Host-Begrenzung, der fail-closed AWS-Resigner und der Kompromittierungsdetektor — ist vollständig in Zugangsdaten & die Übertragungsgrenze dokumentiert. Lesen Sie dieses Kapitel für das Sicherheitsmodell; lesen Sie diese Seite, um die Felder auszufüllen. Die Steuerungen für Freigabe und Schreibrichtlinie pro Zugangsdatum liegen nun im Bereich Schutzmechanismen, nicht hier.

Hinweis: Der Screenshot oben stammt aus der Zeit vor dem Redesign und zeigt möglicherweise noch den älteren Stapel aus einklappbaren Abschnitten. Der aktuelle Bereich zeigt nur die Zugangsdaten, die Sie konfiguriert haben, gruppiert unter Kategorie-Überschriften, plus die beiden unten beschriebenen Schaltflächen.

Der Bereich öffnet sich mit Git-Identität oben angeheftet, gefolgt von einer Liste der Zugangsdaten, die Sie bereits konfiguriert haben — sonst nichts. Jedes konfigurierte Zugangsdatum ist eine Zeile; die leeren Familien, die früher eingeklappt auf dem Bereich saßen, sind verschwunden. Zwei Schaltflächen am unteren Rand, Zugangsdatum hinzufügen und env-Datei importieren…, sind die Art und Weise, wie Sie weitere hinzufügen. Nichts wird angewendet, bis Sie auf Sichern klicken.

Git-Identität

Die beiden Felder oben setzen die Git-Autoren-Identität, die in die ~/.gitconfig innerhalb der VM geschrieben wird:

• user.name — Platzhalter Ihr Name.
• user.email — Platzhalter [email protected].

Die Beschriftung lautet: Wird in ~/.gitconfig in der VM geschrieben. Lassen Sie beide leer, um die Standardwerte von git beizubehalten. Diese sind keine Geheimnisse und werden nicht ausgetauscht — sie sind reine Konfiguration, damit die Commits, die der Agent erstellt, korrekt zugeordnet werden. Ein leeres Feld lässt den jeweiligen git-Standardwert unangetastet.

Die Liste der konfigurierten Zugangsdaten

Unter der Git-Identität listet der Bereich nur die Zugangsdaten auf, die tatsächlich beim Start einer Sitzung einen Austausch erzeugen, gruppiert unter Kategorie-Überschriften:

Jede Zeile zeigt ein Symbol, einen Titel und den Host oder die Hosts, auf die das Zugangsdatum begrenzt ist (bei einem Git-Token user@host; bei einer Datenbank oder Registry deren Host; bei AWS amazonaws.com; und so weiter). Ein ⋯-Menü rechts — ebenfalls durch Klicken auf die Zeile erreichbar — bietet Bearbeiten… und Entfernen:

• Bearbeiten… öffnet den Editor dieses Zugangsdatums erneut, damit Sie seine Felder ändern oder anzeigen können.
• Entfernen löscht das Zugangsdatum aus dem Arbeitsbereich. (Es gibt kein Rückgängig außer dem erneuten Hinzufügen; nichts wird von der Festplatte entfernt, bis Sie Sichern.)

Zeilen unter AGENTEN sind die eine Ausnahme: Ihr Menü lautet In Agenten bearbeiten… und hat kein Entfernen, weil Agenten-Schlüssel dem Bereich Agenten gehören. Die Auswahl wechselt den Editor zu diesem Bereich.

Wenn ein Arbeitsbereich überhaupt keine Zugangsdaten hat, wird die Liste durch einen leeren Zustand ersetzt — Noch keine Zugangsdaten — der Sie daran erinnert, dass echte Werte auf Ihrem Mac bleiben und die VM immer nur ein Fake hält.

Ein Zugangsdatum hinzufügen

Klicken Sie auf Zugangsdatum hinzufügen, um das Auswahlblatt zu öffnen. Es listet jeden Zugangsdaten-Typ auf, den die App hinzufügen kann; jeder Eintrag öffnet den Editor dieses Typs:

Agenten-API-Schlüssel sind bewusst nicht in dieser Auswahl; ein Fußzeilen-Hinweis erinnert Sie daran, dass Anthropic-, OpenAI- und xAI-Schlüssel im Bereich Agenten konfiguriert werden. Jeder Editor ist ein Blatt mit einer Schaltfläche Fertig; die Felder für jeden Typ werden in den folgenden Abschnitten beschrieben.

Eine env-Datei importieren

Klicken Sie auf env-Datei importieren…, um Zugangsdaten aus einer bestehenden .env-Datei — oder einer ~/.bashrc — zu ziehen. Der Parser liest einfache KEY=VALUE- und export KEY=VALUE-Zuweisungen, entfernt umgebende Anführungszeichen und nachfolgende # comments und nimmt die letzte Zuweisung, wenn ein Name wiederholt wird. Er führt niemals eine Shell aus: Jeder Wert, der eine Interpolation erfordern würde (eine $VAR-Referenz oder eine $(…)-Befehlssubstitution), wird übersprungen, anstatt falsch importiert zu werden, sodass es sicher ist, ihn auf eine echte .bashrc zu richten.

Die Variablen der Datei werden dann in einem Prüfblatt mit dem Titel Importieren aus <filename> angezeigt, aufgeteilt in zwei Gruppen. Jeder Wert ist in diesem Blatt maskiert.

Erkannte Variablen werden automatisch ihrem Zugangsdaten-Typ zugeordnet:

Jede erkannte Zeile hat ein Kontrollkästchen. Ein Git-Token fragt zusätzlich nach einem Git-Benutzernamen (Platzhalter you), damit das Zugangsdatum vollständig ist. Wenn eine Variable auf etwas abgebildet wird, das der Arbeitsbereich bereits konfiguriert hat, wird ihre Zeile mit Bereits konfiguriert — zum Überschreiben ankreuzen. gekennzeichnet und nicht angekreuzt gelassen, sodass ein erneuter Import niemals stillschweigend ein bestehendes Geheimnis überschreibt.

Nicht erkannte Variablen können als generische Sonstiger API-Schlüssel-Token importiert werden. Jede Zeile trägt ein Feld Host(s) — eine durch Kommas getrennte Liste von Hostnamen, auf denen das Fake ausgetauscht werden soll (mehrere Hosts erlaubt; leer bedeutet beliebiger Host). Der Name der Umgebungsvariable wird sowohl als Name des Tokens als auch als Variable, unter der das Fake exportiert wird, wiederverwendet.

Die Schaltfläche lautet N Zugangsdaten importieren und spiegelt nur die Zeilen wider, die Sie angekreuzt gelassen haben. Der Import führt die Auswahlen in den Bereich zusammen; Sie klicken weiterhin auf Sichern, um sie dauerhaft zu speichern.

SSH-Schlüssel

Der SSH-Schlüssel-Editor verwaltet die Schlüssel, mit denen sich der Arbeitsbereich über SSH authentifizieren kann. Private Schlüssel-Bytes gelangen niemals in die VM: Das Signieren wird über eine In-Process-ssh-agent-Brücke über vsock bereitgestellt, sodass der Gast Signaturen anfordern, aber den Schlüssel niemals lesen kann.

Es gibt zwei Quellen für Schlüssel:

• Das eigene ed25519-Schlüsselpaar des Arbeitsbereichs. Neue Arbeitsbereiche tragen einen vorab angekreuzten Umschalter ed25519-Schlüsselpaar generieren (es sei denn, Ihre Einstellungsvorlage stellt bereits einen Schlüssel bereit). Sobald ein Schlüssel existiert, zeigt der Editor seinen öffentlichen Schlüssel mit den Schaltflächen Kopieren und GitHub-Schlüsselseite öffnen (zum Einfügen in github.com/settings/keys) und einen Umschalter Neu generieren.
• Importierte SSH-Schlüssel. Unter Importierte SSH-Schlüssel klicken Sie auf Importieren…, um einen Dateiauswähler zu öffnen; ein Blatt fragt dann nach einer Bezeichnung und, falls der Schlüssel verschlüsselt ist, nach einer Passphrase. Passphrasen werden im macOS-Schlüsselbund gespeichert, und importierte Schlüssel werden bei jedem Sitzungsstart in den ssh-agent pro Arbeitsbereich geladen. RSA-, ed25519- und ecdsa-Schlüssel werden unterstützt.

Git-Token (GitHub, GitLab, Bitbucket)

Der Git-Token-Editor hält persönliche Zugangstoken für git über HTTPS, aufgeteilt in die Gruppen GitHub, GitLab und Bitbucket. Wie seine Beschriftung es ausdrückt: Persönliche Zugangstoken werden verschlüsselt auf dem Host gespeichert, und der Proxy tauscht sie in ausgehende Anfragen ein, sodass die VM immer nur das Fake hält. gh und glab übernehmen GH_TOKEN / GITLAB_TOKEN automatisch.

Klicken Sie auf Token hinzufügen in einer Gruppe, um eine Zeile hinzuzufügen. Jede Zeile nimmt einen Host, einen Benutzernamen und ein Persönliches Zugangstoken (mit einer Anzeigen-Auge-Schaltfläche und einem Link zur Token-Seite dieser Forge). Das Fake wird in die ~/.git-credentials und in die gh / glab CLI-Konfigurationen innerhalb der VM geschrieben. Das Host-Feld ermöglicht es Ihnen, einen Eintrag auf github.com, gitlab.com oder eine selbst gehostete GitLab-/Gitea-/Bitbucket-Instanz zu richten.

Linear

Der Linear-API-Schlüssel-Editor nimmt einen einzelnen persönlichen API-Schlüssel (Platzhalter in der Form lin_api_…, mit einem Link Linear-API-Einstellungen öffnen). Er wird als LINEAR_API_KEY in die VM injiziert, was das Linear-SDK, MCP-Server und CLI-Tools automatisch übernehmen, und wird nur bei Anfragen an linear.app (einschließlich api.linear.app und mcp.linear.app) fake-gegen-echt ausgetauscht. Ein Linear-Schlüssel im Arbeitsbereich ist zudem die Voraussetzung für Trigger der geplanten Automatisierung für Linear-Issues.

Kubernetes

Der Kubernetes-Editor hält eine Zeile pro Cluster-Kontext. Bromure Agentic Coding baut eine synthetische ~/.kube/config innerhalb der VM, sodass kubectl mit dem Proxy spricht, niemals direkt mit dem API-Server; die echte Identität bleibt auf dem Host.

Jeder Kontext hat einen Namen, eine Server-URL, ein optionales CA-Zertifikat (PEM, verwendet, damit der Proxy den vorgelagerten API-Server verifizieren kann), einen Namespace und eine Authentifizierungsmethode, die mit einer segmentierten Steuerung gewählt wird:

• Bearer-Token — ein statisches Token, an der Übertragungsgrenze gegen den echten Wert ausgetauscht.
• Client-Zertifikat — das echte Zertifikat und der Schlüssel werden auf dem Host für vorgelagertes gegenseitiges TLS registriert; die VM erhält ein Wegwerf-selbstsigniertes Zertifikat.
• Exec-Plugin — ein Befehl, Args und ein Aktualisierungs-Schrittzähler (1–60 Minuten). Das Plugin läuft auf dem Host bei jedem Aktualisierungsintervall, und das frische Token wird in die Austausch-Zuordnung eingespeist; das kubectl der VM führt das Plugin niemals aus.

Ein Abzeichen auf jeder Zeile zeigt, welcher Typ (Token / Zertifikat / Exec) es ist. Verwenden Sie Datei importieren…, um eine bestehende kubeconfig in eine Zeile pro Kontext zu parsen, oder Kontext hinzufügen, um einen von Hand hinzuzufügen. Die passende Schreibrichtlinie pro Kontext wird im Bereich Schutzmechanismen festgelegt.

DigitalOcean

Der DigitalOcean-Token-Editor nimmt ein einzelnes persönliches Zugangstoken (Platzhalter in der Form dop_v1_…, mit einem Link zur DigitalOcean-Token-Seite). Es wird als DIGITALOCEAN_ACCESS_TOKEN injiziert und in ~/.config/doctl/config.yaml geschrieben, sodass doctl auth init unnötig ist. Das Token wird bei Anfragen an digitalocean.com fake-gegen-echt ausgetauscht, und ein zweiter Austausch-Eintrag deckt die base64-Basic-auth-Form ab, die verwendet wird, wenn sich docker login oder doctl registry login gegenüber registry.digitalocean.com authentifiziert.

AWS

Der AWS-Zugangsdaten-Editor konfiguriert Zugangsdaten für die aws-CLI, die SDKs, terraform und den Bedrock-Auth-Modus von Claude Code. Das echte Geheimnis erreicht die VM niemals — der Host signiert SigV4-Anfragen mit dem echten Material neu, und eine Anfrage, die den Proxy umgeht, erhält eine InvalidSignatureException von AWS. Eine segmentierte Steuerung Auth-Methode wählt zwischen:

• Statische Schlüssel — Access Key ID, Secret Access Key, ein optionales Session-Token (nur STS) und eine Standard-Region, plus einem Link IAM-Zugangsdatenseite öffnen.
• SSO / Identity Center — ein Ordnerauswähler Zugriff auf ~/.aws gewähren, dann ein SSO-Profil-Auswähler, der aus den in Ihrer ~/.aws/config gefundenen Profilen befüllt wird (mit einer Aktualisierungs-Schaltfläche). Temporäre Rollen-Zugangsdaten werden auf dem Host aufgelöst, wobei aws sso login in Ihrem Browser ausgelöst wird, wenn das zwischengespeicherte Token abgelaufen ist.

Die vollständige AWS-Handhabung — der credential_process-Helfer, der Resigner und seine Grenzen — steht in Zugangsdaten & die Übertragungsgrenze.

Container-Registrys

Der Container-Registry-Editor hält HTTP-Basic-auth pro Registry für docker pull / docker push. Wie die Beschriftung erklärt, wird das echte Passwort niemals in die VM geschrieben — bromure legt ein Fake base64("<user>:<derived>") in ~/.docker/config.json ab, und der Proxy ersetzt den echten Wert an der Übertragungsgrenze, wenn die Anfrage den passenden Registry-Host erreicht.

Das Menü Hinzufügen bietet Voreinstellungen — Docker Hub (docker.io), GitHub Container Registry (ghcr.io), GitLab Container Registry (registry.gitlab.com), Quay (quay.io) und Anderer Host… — plus config.json importieren…, das Einträge aus einer bestehenden ~/.docker/config.json zieht. Der Import überspringt credsStore / credHelpers-Einträge (ihre Passwörter liegen im OS-Schlüsselbund statt in der Datei) und meldet, wie viele übersprungen wurden. Jede Registry-Zeile nimmt einen Host, einen Benutzernamen und ein Passwort oder Token. Die passende push/pull/delete-Schreibrichtlinie wird im Bereich Schutzmechanismen festgelegt.

Datenbanken (MongoDB, ClickHouse, Elasticsearch)

Der Datenbank-Editor hält eine Zeile pro HTTPS-Endpunkt, gruppiert nach Engine. Das Fake wird unter den von Ihnen aufgeführten Umgebungsvariablennamen exportiert und wird gegen den echten Wert ausgetauscht, wo immer es erscheint — Header, Query-Parameter oder Anfrage-Body.

Jede Endpunkt-Zeile hat:

• Name — optionaler Anzeigename.
• Host — der reine Hostname; er begrenzt sowohl den Austausch als auch den Schutzmechanismus des Endpunkts.
• Authentifizierung — eine segmentierte Steuerung: Benutzername + Passwort, API-Schlüssel oder Bearer-Token. MongoDB verwendet standardmäßig API-Schlüssel; ClickHouse und Elasticsearch verwenden standardmäßig Benutzername + Passwort.
• Benutzername — nur für Basic-auth.
• Geheimnis — mit einer Anzeigen-Auge-Schaltfläche.
• Umgebungsvariable(n) — eine durch Kommas getrennte Liste der Namen, unter denen das Fake exportiert werden soll.

Neue Datenbank-Endpunkte setzen ihre Schreibrichtlinie pro Endpunkt standardmäßig auf Vor dem Schreiben nachfragen, festgelegt im Bereich Schutzmechanismen — die engine-spezifische Klassifizierung (welche Mongo-Aktionen, welche SQL-Schlüsselwörter, welche Elasticsearch-Pfade als Schreibvorgänge zählen) lebt dort.

Sonstige API-Schlüssel

Der Sonstiger API-Schlüssel-Editor ist die Ausweichmöglichkeit für jeden Dienst, den Bromure Agentic Coding nicht automatisch handhabt. Jeder Eintrag ist eine manuelle Austauschregel:

• Name — eine Bezeichnung für den Eintrag.
• Echtes Geheimnis — maskiert (Platzhalter in der Form sk_live_…).
• Umgebungsvariable — der Name, unter dem das Fake innerhalb der VM exportiert wird. Lässt man dies leer, wird nichts exportiert; Sie würden dann das Fake aus dem Begrüßungsbanner der Sitzung kopieren.
• API-Host (optional) — der Host oder die Hosts, auf die der Austausch begrenzt ist (exakt-oder-Subdomain, durch Kommas getrennt). Leer bedeutet "auf jedem Host injizieren".

Die VM sieht ein geprägtes brm_…-Fake, und der Proxy tauscht es an der Übertragungsgrenze zurück.

Warnung: Ein leerer API-Host wird bewusst niemals durch den Kompromittierungsdetektor abgeschirmt — es ist eine explizite Wahl "auf jedem Host injizieren". Um ein unbegrenztes Geheimnis unter Kontrolle zu halten, geben Sie ihm entweder einen Host oder schalten Sie im Bereich Schutzmechanismen Vor Verwendung nachfragen dafür ein.

Freigabe- und Schreibrichtlinien liegen in Schutzmechanismen

Es gibt keine Freigabe zur Verwendung erforderlich-Kontrollkästchen mehr im Bereich Zugangsdaten. Das Zustimmungs-Gate pro Zugangsdatum — jetzt als Vor Verwendung nachfragen dargestellt — und die Schreibrichtlinie jedes Dienstes liegen beide im Bereich Schutzmechanismen, der eine Zeile pro konfiguriertem Zugangsdatum auflistet. Konfigurieren Sie das Geheimnis hier; entscheiden Sie dort, wie der Agent es verwenden darf.

Wie der Bereich gespeichert wird

Alles in diesem Bereich ist ein Geheimnis, daher wird es beim Sichern aus der Klartext-profile.json in die verschlüsselte secrets.enc des Arbeitsbereichs ausgelagert (AES-GCM, verschlüsselt aus dem macOS-Schlüsselbund, Berechtigungen 600). Die automatisch gehandhabten Anbieter — Anthropic, OpenAI, GitHub, GitLab, DigitalOcean, Kubernetes — benötigen keine manuelle Eingabe über das hinaus, was Sie hier konfigurieren; der eigene API-Schlüssel des primären Agenten wird im Bereich Agenten festgelegt.

Einstellungsreferenz

Vor Verwendung nachfragen pro Zugangsdatum und Schreibrichtlinien werden im Bereich Schutzmechanismen festgelegt.

Verwandte Kapitel

• Zugangsdaten & die Übertragungsgrenze — das vollständige Sicherheitsmodell hinter diesem Bereich.
• Agenten — der API-Schlüssel des primären Agenten und die Abonnement-/Bedrock-Auth-Modi.
• Schutzmechanismen — Freigabe pro Zugangsdatum und Schreibrichtlinien pro Dienst für dieselben Geheimnisse.
• Einstellungsreferenz — alle Bereiche auf einen Blick.