Wenn Sie Claude Code, Codex oder Cursor mit irgendetwas verwenden, das eine echte API berührt, haben Sie ein Problem: Der Agent benötigt Anmeldeinformationen und Ihr Passwortmanager möchte sie gesperrt halten. Die üblichen Problemumgehungen sind schlecht. Fügen Sie einen API-Schlüssel in einen Chat ein, und er landet für immer in einem Modellkontextfenster. Legen Sie Geheimnisse in eine .env-Datei, und das bash-Tool des Agenten wird sie fröhlich cat-en und irgendwohin versenden. Die meisten Teams senken einfach ihre Standards.
Bitwardens neues Open-Source-Projekt, Agent Access, ist der erste ernsthafte Versuch, dies zu beheben. Es ist ein Protokoll zum Teilen von Anmeldeinformationen, eine CLI (aac) und ein Rust + Python SDK, das einen verschlüsselten Tunnel zwischen Ihrem Passwortmanager und einem Remote-Prozess aufbaut: einem Agenten, einem CI-Runner, einem Skript. Der Agent erhält die benötigten Geheimnisse, die auf eine einzelne Domäne oder ein Tresorelement beschränkt sind, ohne jemals Ihren Tresor zu sehen.
Dieser Leitfaden beschreibt, was Agent Access liefert, wie man es installiert, wie man aac connect und aac run verwendet, wie es in Claude Code-, Codex- und Cursor-Workflows passt und wo es neben den in Wie man API-Anmeldeinformationen von KI-Agenten sichert behandelten Mustern zur Anmeldeinformationshygiene steht.
Was Agent Access ist (ein Absatz)
Agent Access ist ein offenes Protokoll plus Referenzimplementierung, das von Bitwarden entwickelt wurde, aber für die Übernahme durch jeden Passwortmanager konzipiert ist. Die CLI (aac) erstellt einen Ende-zu-Ende-verschlüsselten Tunnel unter Verwendung des Noise-Protokolls. Ein „Provider“ lauscht auf Verbindungsanfragen; ein „Consumer“ (Ihr Agent, Ihr Skript, Ihr CI-Job) verbindet sich mit dem Provider und fragt nach Anmeldeinformationen nach Domäne oder Tresorelement-ID. Der Provider entscheidet, was zurückgesendet werden soll. Der Consumer sieht niemals den vollständigen Tresor. Der Provider sieht niemals, was der Consumer mit den Anmeldeinformationen macht. Audit-Trails existieren auf beiden Seiten.
Es befindet sich derzeit in der frühen Vorschau. Das Projekt-README warnt, dass „APIs und Protokolle Änderungen unterliegen“ und „wir nicht empfehlen, sensible Anmeldeinformationen direkt in LLMs oder KI-Agenten einzugeben.“ Das von Bitwarden stattdessen empfohlene Muster ist der Schwerpunkt der Hälfte dieses Leitfadens: die Umgebungsinjektion über aac run, die Geheimnisse in einen Prozess bringt, ohne sie dem Kontextfenster des Agenten zugänglich zu machen.
Warum das im Jahr 2026 wichtig ist
KI-Programmieragenten sind über Sandboxes hinausgewachsen. Claude Code, Codex, Cursor und die anderen lesen jetzt Ihr Repo, führen Ihre Tests aus, greifen auf Ihre APIs zu, stellen Ihren Code bereit. Jeder dieser Schritte benötigt Anmeldeinformationen. Der Vorfall mit den offengelegten API-Schlüsseln bei Postman zeigte, wie schlecht die Hygiene von Anmeldeinformationen skaliert, wenn Menschen allein schlampig sind; Menschen plus Agenten ist schlimmer.
Die richtige Antwort ist nicht „dem Agenten mehr vertrauen“; es ist „dem Agenten weniger geben.“ Agent Access tut dies auf Protokollebene: bereichsbezogene Anmeldeinformationen, verschlüsselt während der Übertragung, zur Laufzeit abgerufen, verschwunden, wenn der Prozess beendet wird. Im Vergleich zur aktuellen Praxis (API Key Management Tools deckt den Rest der Landschaft ab) ist Agent Access das erste, was speziell für den Agentenfall entwickelt wurde.
Installation
Wählen Sie Ihre Plattform.
macOS (Apple Silicon)
curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-aarch64.tar.gz | tar xz
sudo mv aac /usr/local/bin/
macOS (Intel)
curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/
Linux (x86_64)
curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-linux-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/
Windows (x86_64)
Laden Sie `aac-windows-x86_64.zip` von der neuesten Release-Seite herunter und entpacken Sie es in ein beliebiges Verzeichnis in Ihrem PATH.
Überprüfen Sie die Installation mit `aac --help`. Wenn die Bitwarden CLI (bw) ebenfalls in Ihrem PATH ist, wird aac sie als Standard-Anmeldeinformationsprovider verwenden; andernfalls übergeben Sie --provider example, um den integrierten Demo-Provider während des Experimentierens zu verwenden.
Schnellstart: Anmeldeinformationen koppeln und abrufen
Zwei Befehle. Führen Sie aac listen auf dem Rechner aus, der Ihren Tresor enthält, typischerweise Ihr Laptop:
aac listen
Der Listener gibt ein Kopplungs-Token aus. Auf der Consumer-Seite (der Remote-Maschine, dem CI-Runner oder einfach einer anderen Shell auf demselben Host, während Sie testen) koppeln und holen Sie in einem Aufruf:
aac connect --token <pairing-token> --domain github.com --output json
Sie erhalten etwas Ähnliches zurück:
{
"credential": {
"notes": null,
"password": "alligator5",
"totp": null,
"uri": "https://github.com",
"username": "example"
},
"domain": "github.com",
"success": true
}
Diese JSON-Struktur ist der stabile Vertrag des Protokolls. Ihr Skript kann sie nach Belieben parsen. Um stattdessen nach Tresorelement-ID statt nach Domäne abzurufen:
aac connect --id <vault-item-id> --output json
--id und --domain schließen sich gegenseitig aus; wählen Sie eines. TOTP-Codes fließen durch dieselbe Nutzlast, wenn das Tresorelement einen konfiguriert hat.
Das Killer-Feature: aac run für die Umgebungsinjektion
aac connect ist in Ordnung, wenn Ihr Skript weiß, wie JSON zu verarbeiten ist. Das größere Muster ist aac run: Es ruft Anmeldeinformationen ab und führt Ihren Kindprozess aus, wobei die Geheimnisse als Umgebungsvariablen injiziert werden. Niemals in stdout, niemals auf die Festplatte, niemals sichtbar für das, was aac gestartet hat.
Spezifische Felder injizieren:
aac run --domain example.com --env DB_PASSWORD=password --env DB_USER=username -- psql
Jedes Feld mit einem AAC_-Präfix injizieren:
aac run --domain example.com --env-all -- deploy.sh
Standardwerte mit Überschreibungen kombinieren:
aac run --domain example.com --env-all --env CUSTOM_PW=password -- deploy.sh
Die verfügbaren Felder sind username, password, totp, uri, notes, domain und credential_id.
Dies ist das Muster, das Bitwarden aktiv für den Einsatz von KI-Agenten empfiehlt: Sie verweisen Claude Code oder Codex auf ein Skript, das aac run aufruft, und das Geheimnis erscheint niemals im Transkript des Agenten. Das Modell sieht den Befehl aac run --domain api.stripe.com --env-all -- ./deploy.sh, nicht das Passwort. Wenn der Agent später fragt „was ist der Wert von $STRIPE_API_KEY?“, lautet die Antwort „Ich kann es nicht sehen“, da es auf den deploy.sh-Unterprozess beschränkt war.
Dies ist dasselbe Isolationsprinzip, das in Wie man API-Anmeldeinformationen von KI-Agenten sichert behandelt wird, konkretisiert mit einem echten Tool.
Python- und Rust-SDKs
Wenn ein CLI-Aufruf nicht ausreicht (z. B. wenn Sie Agent Access in Ihre eigene Anwendung einbetten), gibt es erstklassige Bindungen.
Python
from agent_access import RemoteClient
client = RemoteClient("python-remote")
client.connect(token="ABC-DEF-GHI")
cred = client.request_credential("example.com")
print(cred.username, cred.password)
client.close()
Das Python-Modul basiert auf PyO3, sodass die rechenintensive Arbeit in Rust verbleibt und Sie dieselbe Noise-Protokollimplementierung unter der Haube erhalten.
Rust
Das Rust-SDK stellt dieselbe RemoteClient-Schnittstelle als erstklassige Bibliothek bereit. Referenzimplementierungen befinden sich unter examples/rust-remote/ im Repository. Verwenden Sie es, wenn Sie den Consumer direkt in Rust schreiben. Üblich bei CLI-Tools, Build-Runnern und jedem Dienst, der eine kompilierte Binärverteilung wünscht.
Für Anwendungsteams, die bereits API-Tools bereitstellen, passt das SDK-Muster sauber neben HashiCorp Vault- oder Azure Key Vault-Integrationen. Agent Access ist kein Ersatz für diese auf Unternehmensebene, aber es passt besser zu den Anwendungsfällen von Entwickler-Laptops und CI-Runnern.
Integration mit KI-Programmieragenten
Claude Code
Verdrahten Sie aac run in das Skript, das Claude Code aufruft. Beispiel für eine Bereitstellungsaufgabe:
# deploy.sh
#!/usr/bin/env bash
aac run --domain prod.example.com --env-all -- ./run-deploy.sh
Fügen Sie dieses Skript Ihrem Projekt hinzu, richten Sie Ihren Claude Code Workflow darauf aus, und der Agent ruft ./deploy.sh ohne Anmeldeinformationen in der Eingabeaufforderung auf. Die Claude Code GitHub Actions-Integration erweitert dasselbe Muster auf CI: Installieren Sie aac im Runner, koppeln Sie es mit einem Bitwarden-Tresor-Provider, der auf einer Steuerungsebene läuft, und Ihre GitHub Actions erben die bereichsbezogenen Anmeldeinformationen zur Jobzeit.
OpenAI Codex
Dasselbe Muster funktioniert für die CLI von Codex. Die Tool-Call-Schicht von Codex leitet Befehle an das Modell weiter; das Skript, das das Modell aufruft, greift in aac run und die Geheimnisse bleiben außerhalb des Kontextes des Modells. Der kürzlich erschienene Beitrag Codex von Ihrem Telefon aus behandelt die breitere Oberfläche von Codex; dies ist der Anmeldeinformationswinkel, der dazu passt.
Cursor
Für die Terminalbefehle und Composer-Workflows von Cursor funktionieren die gleichen mit aac run umhüllten Skripte ohne Änderungen. Cursors Stärke liegt in der lokalen Bearbeitung, daher läuft der Listener typischerweise auf demselben Rechner.
OpenClaw (Anthropic-Ökosystem-Fähigkeit)
Agent Access liefert eine offizielle OpenClaw-Fähigkeit sofort einsatzbereit (eine SKILL.md befindet sich im Repo). Für Teams, die OpenClaw-ähnliche Fähigkeiten verwenden, ist dies die heute am weitesten entwickelte Integration: Die Fähigkeit kennt die Protokollform, ruft die Anmeldeinformationen ab und übergibt sie an jedes nachgeschaltete Tool, das die Fähigkeit bereitstellt. Der OpenClaw API-Schlüssel-Leitfaden behandelt die umfassendere Geschichte des Anmeldeinformationsmanagements für dieses Ökosystem.
Sicherheitsmodell in einfachen Worten
Drei Behauptungen, die es wert sind, überprüft zu werden:
- Ende-zu-Ende-Verschlüsselung über Noise. Der Datenverkehr zwischen Consumer und Provider wird mit dem Noise-Protokoll-Framework verschlüsselt, derselben Handshake-Familie, die WireGuard und Signal verwenden. Die Transportschicht ist nicht das schwächste Glied.
- Bereichsbezogene Anmeldeinformationen. Der Consumer erhält immer nur das, wonach er gefragt hat (eine Domäne oder eine Tresorelement-ID). Er kann den Tresor nicht aufzählen.
- Standardmäßig keine Geheimnisse auf der Festplatte des Consumers.
aac runleitet Geheimnisse über Umgebungsvariablen in einen Kindprozess; es wird nichts in eine Datei geschrieben, nichts erscheint in stdout, nichts landet in der Shell-Historie.
Wovor Agent Access nicht schützt:
- Ein kompromittierter Consumer-Prozess. Wenn der Agent bösartig oder kompromittiert ist, sickern bereichsbezogene Anmeldeinformationen immer noch durch. Die Verteidigung ist der Geltungsbereich, nicht das Protokoll.
- Ein kompromittierter Provider. Wenn Ihr Bitwarden-Tresor selbst kompromittiert ist, nützt Ihnen diese Schicht nichts.
- Direktes Eingeben von Geheimnissen in das LLM-Kontextfenster. Das README ist diesbezüglich explizit: „wir empfehlen nicht, sensible Anmeldeinformationen direkt in LLMs oder KI-Agenten einzugeben.“
aac runist die Problemumgehung.
Ein gängiges Muster: Agent ruft API auf, Apidog testet sie
Hier ist der Ablauf, in den sich die meisten Teams einfinden werden:
- Agent schreibt den Code. Claude Code, Codex oder Cursor öffnet einen PR, der einen Endpunkt betrifft.
- CI führt die Tests aus. Ihr Test-Runner ruft
aac runauf, um den API-Schlüssel abzurufen, und führt die Testsuite gegen eine Staging-Bereitstellung aus. - Apidog verifiziert den Vertrag. Apidog führt den OpenAPI-Vertragstest als separaten CI-Schritt aus, ebenfalls über
aac run, ebenfalls ohne dass der Agent den Schlüssel sieht.
Das Ergebnis: Agent liefert Code, Vertrag hält, Geheimnis verlässt niemals den Tresor. Das umfassendere Playbook zum Testen von KI-gesteuerten Änderungen finden Sie unter Wie man KI-Agenten testet, die Ihre APIs aufrufen.
Einschränkungen und Warnungen
- Frühe Vorschau. APIs und Protokolle können sich ändern. Binden Sie einen Produktions-Workflow nicht an das v0-Protokoll ohne Budget für eine spätere Überarbeitung.
- Bitwarden CLI standardmäßig erforderlich. Der Standard-Provider ist
bw; installieren Sie zuerst die Bitwarden CLI, oder übergeben Sie--provider examplefür den Demo-Provider während des Testens. - Noch keine Konfigurationsdatei. Agent Access ist derzeit flag-gesteuert. Wiederholte Aufrufe müssen durch Skripte automatisiert werden.
- Fügen Sie keine Geheimnisse in LLM-Prompts ein. Selbst wenn Agent Access installiert ist, kann Sie kein Protokoll retten, wenn Sie Anmeldeinformationen in ein Chatfenster kopieren.
Häufig gestellte Fragen
Ist Agent Access kostenlos?
Ja. Die CLI, SDKs und das Protokoll sind Open Source unter der Bitwarden GitHub Organisation. Sie zahlen weiterhin für Bitwarden, wenn Sie es als Ihren Tresor verwenden.
Funktioniert es auch mit anderen Passwortmanagern als Bitwarden?
Das Protokoll ist herstellerneutral konzipiert. Die Referenzimplementierung wird mit Bitwarden-Unterstützung und einem Beispiel-Provider geliefert; es wird erwartet, dass andere Hersteller im Laufe der Zeit ihre eigenen Provider liefern werden.
Kann ich es ganz ohne Passwortmanager verwenden?
Für Tests ja; übergeben Sie --provider example, um den integrierten Demo-Provider zu verwenden. Für die Produktion benötigen Sie einen echten Provider (Bitwarden heute, andere auf der Roadmap).
Benötigt der Consumer-Prozess Netzwerkzugriff?
Der Consumer benötigt Netzwerkzugriff, um den Listener des Providers zu erreichen. Lokale Setups funktionieren, wenn Listener und Consumer auf demselben Host sind.
Wie unterscheidet sich das von einer .env-Datei?
Eine .env-Datei liegt auf der Festplatte, wird versehentlich in Repositories eingecheckt und ist von allem lesbar, was der Agent ausführen kann. aac run hält das Geheimnis nur im Prozessspeicher, beschränkt auf den Unterprozess, und verschwindet, wenn dieser beendet wird.
Ersetzt es HashiCorp Vault oder AWS Secrets Manager?
Nein. Unternehmens-Tresore sind immer noch das richtige Werkzeug für Service-zu-Service-Geheimnisse im großen Maßstab. Agent Access füllt die Lücke bei Entwickler-Laptops und CI-Runnern, wo ein vollständiger Unternehmens-Tresor überdimensioniert wäre.
Werden Anthropic, OpenAI oder andere Agenten-Anbieter dies direkt integrieren?
Nicht angekündigt. Das aktuelle Integrationsmodell ist „wickeln Sie Ihre Skripte in aac run ein.“ Direkte erstklassige Unterstützung von den Agenten-Anbietern ist der natürliche nächste Schritt, wird aber noch nicht ausgeliefert.
Wo melde ich Fehler oder trage bei?
Das GitHub-Repo. Probleme, PRs und Protokolldiskussionen finden alle dort statt.
Jetzt ausprobieren
Installieren Sie aac, führen Sie aac listen auf Ihrem Laptop aus, führen Sie aac connect --provider example --domain test.com --output json von einem anderen Terminal aus. Bestätigen Sie, dass das JSON zurückkommt. Das ist die kleinste Ende-zu-Ende-Schleife. Ersetzen Sie von dort den Beispiel-Provider durch bw, wickeln Sie ein echtes Skript in aac run ein und hören Sie auf, API-Schlüssel in Ihre KI-Agenten einzufügen.
Koppeln Sie Agent Access mit Apidog für die API-Testseite des Workflows, und Sie haben eine saubere Trennung: Der Tresor enthält das Geheimnis, Apidog testet den Vertrag, der Agent liefert den Code, und keine Anmeldeinformationen verlassen Ihre Maschine im Klartext.