Accès Sécurisé Agent Bitwarden : Partage de Mots de Passe Coffre-fort avec Agents IA

Si vous utilisez Claude Code, Codex ou Cursor avec quoi que ce soit qui touche une API réelle, vous avez un problème : l'agent a besoin d'identifiants et votre gestionnaire de mots de passe veut les garder sous clé. Les solutions de contournement habituelles sont mauvaises. Coller une clé API dans un chat et elle atterrit pour toujours dans une fenêtre de contexte du modèle. Déposer des secrets dans un fichier .env et l'outil bash de l'agent les `cat` et les expédie n'importe où. La plupart des équipes se contentent de baisser leurs exigences.

Le nouveau projet open-source de Bitwarden, Agent Access, est la première tentative sérieuse de résoudre ce problème. Il s'agit d'un protocole de partage d'identifiants, d'un CLI (aac) et d'un SDK Rust + Python qui construit un tunnel chiffré entre votre gestionnaire de mots de passe et un processus distant : un agent, un exécuteur CI, un script. L'agent obtient les secrets dont il a besoin, limités à un seul domaine ou élément de coffre-fort, sans jamais voir votre coffre-fort.

Ce guide explique ce qu'Agent Access offre, comment l'installer, comment utiliser aac connect et aac run, comment il s'intègre aux flux de travail de Claude Code, Codex et Cursor, et comment il se positionne par rapport aux modèles d'hygiène des identifiants abordés dans Comment sécuriser les identifiants API des agents IA.

Ce qu'est Agent Access (en un paragraphe)

Agent Access est un protocole ouvert et une implémentation de référence construits par Bitwarden, mais conçus pour être adoptés par n'importe quel gestionnaire de mots de passe. Le CLI (aac) crée un tunnel chiffré de bout en bout en utilisant le protocole Noise. Un « fournisseur » écoute les demandes de connexion ; un « consommateur » (votre agent, votre script, votre tâche CI) se connecte au fournisseur et demande des identifiants par domaine ou par ID d'élément de coffre-fort. Le fournisseur décide quoi renvoyer. Le consommateur ne voit jamais l'intégralité du coffre-fort. Le fournisseur ne voit jamais ce que le consommateur fait avec les identifiants. Des journaux d'audit existent des deux côtés.

Il est actuellement en **préversion**. Le README du projet avertit que « les API et les protocoles sont sujets à modification » et « nous ne recommandons pas d'entrer des identifiants sensibles directement dans les LLM ou les agents IA ». Le modèle que Bitwarden recommande à la place est le point central de la moitié de ce guide : l'injection d'environnement via aac run, qui insère les secrets dans un processus sans les exposer à la fenêtre de contexte de l'agent.

Pourquoi cela est important en 2026

Les agents de codage IA ont dépassé les bacs à sable. Claude Code, Codex, Cursor et les autres lisent désormais votre dépôt, exécutent vos tests, appellent vos API, déploient votre code. Chacune de ces étapes nécessite des identifiants. L'incident Postman des clés API exposées a montré à quel point l'hygiène des identifiants se dégrade lorsque les humains seuls sont négligents ; les humains plus les agents, c'est pire.

La bonne réponse n'est pas « faire plus confiance à l'agent » ; c'est « donner moins à l'agent ». Agent Access le fait au niveau du protocole : identifiants à portée limitée, chiffrés en transit, récupérés à l'exécution, et disparus à la fin du processus. Comparé aux pratiques actuelles (API Key Management Tools couvre le reste du paysage), Agent Access est la première solution construite spécifiquement pour le cas agentique.

Installation

Choisissez votre plateforme.

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)

Téléchargez `aac-windows-x86_64.zip` depuis la page de la dernière version et extrayez-le dans n'importe quel répertoire de votre PATH.

Vérifiez l'installation avec `aac --help`. Si le CLI Bitwarden (`bw`) est également dans votre PATH, `aac` l'utilisera comme fournisseur d'identifiants par défaut ; sinon, passez `--provider example` pour utiliser le fournisseur de démonstration intégré pendant que vous expérimentez.

Démarrage rapide : coupler et récupérer un identifiant

Deux commandes. Exécutez `aac listen` sur la machine qui contient votre coffre-fort, généralement votre ordinateur portable :

aac listen

L'écouteur affiche un jeton de couplage. Côté consommateur (la machine distante, l'exécuteur CI, ou simplement un autre shell sur le même hôte pendant que vous testez), couplez et récupérez en un seul appel :

aac connect --token <jeton-de-couplage> --domain github.com --output json

Vous obtenez quelque chose comme :

{
  "credential": {
    "notes": null,
    "password": "alligator5",
    "totp": null,
    "uri": "https://github.com",
    "username": "example"
  },
  "domain": "github.com",
  "success": true
}

Cette structure JSON est le contrat stable du protocole. Votre script peut l'analyser comme il le souhaite. Pour récupérer par ID d'élément de coffre-fort au lieu du domaine :

aac connect --id <id-element-coffre-fort> --output json

Les options `--id` et `--domain` sont mutuellement exclusives ; choisissez-en une. Les codes TOTP transitent par la même charge utile si l'élément de coffre-fort en a un configuré.

La fonctionnalité phare : `aac run` pour l'injection d'environnement

aac connect est bien quand votre script sait comment gérer le JSON. Le modèle plus large est aac run : il récupère un identifiant et exécute votre processus enfant avec les secrets injectés en tant que variables d'environnement. Jamais vers la sortie standard, jamais sur le disque, jamais visible par ce qui a lancé aac.

Injecter des champs spécifiques :

aac run --domain example.com --env DB_PASSWORD=motdepasse --env DB_USER=nomutilisateur -- psql

Injecter tous les champs avec un préfixe AAC_ :

aac run --domain example.com --env-all -- deploy.sh

Combiner les valeurs par défaut avec des remplacements :

aac run --domain example.com --env-all --env CUSTOM_PW=motdepasse -- deploy.sh

Les champs disponibles sont `username`, `password`, `totp`, `uri`, `notes`, `domain` et `credential_id`.

C'est le modèle que Bitwarden recommande activement pour l'utilisation d'agents IA : vous dirigez Claude Code ou Codex vers un script qui appelle aac run, et le secret n'apparaît jamais dans l'historique de conversation de l'agent. Le modèle voit la commande aac run --domain api.stripe.com --env-all -- ./deploy.sh, et non le mot de passe. Si l'agent demande plus tard « quelle est la valeur de `$STRIPE_API_KEY` ? », la réponse est « je ne peux pas la voir » car elle était limitée au sous-processus `deploy.sh`.

C'est le même principe d'isolation couvert dans Comment sécuriser les identifiants API des agents IA, concrétisé par un outil réel.

SDK Python et Rust

Si une invocation CLI ne suffit pas (par exemple, si vous intégrez Agent Access dans votre propre application), il existe des liaisons de premier ordre.

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

Le module Python est basé sur PyO3, de sorte que le gros du travail reste en Rust et que vous bénéficiez de la même implémentation du protocole Noise sous le capot.

Rust

Le SDK Rust expose la même interface `RemoteClient` en tant que bibliothèque de premier ordre. Des implémentations de référence se trouvent sous `examples/rust-remote/` dans le dépôt. Utilisez-le lorsque vous écrivez directement le consommateur en Rust. Courant dans les outils CLI, les exécuteurs de builds et tout service qui souhaite une distribution binaire compilée.

Pour les équipes d'applications qui déploient déjà des outils API, le modèle SDK s'intègre parfaitement aux intégrations de HashiCorp Vault ou Azure Key Vault. Agent Access ne remplace pas ces solutions au niveau entreprise, mais il convient mieux aux cas d'utilisation sur ordinateur de développeur et exécuteur CI.

Intégration avec les agents de codage IA

Claude Code

Reliez aac run au script appelé par Claude Code. Exemple pour une tâche de déploiement :

# deploy.sh
#!/usr/bin/env bash
aac run --domain prod.example.com --env-all -- ./run-deploy.sh

Ajoutez ce script à votre projet, pointez votre flux de travail Claude Code vers celui-ci, et l'agent appellera `./deploy.sh` sans identifiants dans l'invite. L'intégration Claude Code GitHub Actions étend le même modèle à la CI : installez `aac` dans l'exécuteur, couplez-le avec un fournisseur de coffre-fort Bitwarden exécuté sur un plan de contrôle, et vos GitHub Actions hériteront des identifiants à portée limitée au moment de la tâche.

OpenAI Codex

Le même modèle fonctionne pour le CLI de Codex. La couche d'appel d'outils de Codex expose des commandes au modèle ; le script appelé par le modèle accède à aac run et les secrets restent en dehors du contexte du modèle. Le récent article Codex depuis votre téléphone couvre la surface plus large de Codex ; c'est l'angle des identifiants qui s'y associe.

Cursor

Pour les commandes de terminal et les flux de travail Composer de Cursor, les mêmes scripts enveloppés de aac run fonctionnent sans modification. La force de Cursor est l'édition locale, donc l'écouteur s'exécute généralement sur la même machine.

OpenClaw (compétence de l'écosystème Anthropic)

Agent Access fournit une **compétence OpenClaw** officielle prête à l'emploi (un fichier `SKILL.md` se trouve dans le dépôt). Pour les équipes utilisant des compétences de style OpenClaw, c'est l'intégration la plus peaufinée à ce jour : la compétence connaît la forme du protocole, récupère les identifiants et les transmet à l'outil en aval que la compétence expose. Le guide des clés API OpenClaw couvre l'histoire plus large de la gestion des identifiants pour cet écosystème.

Modèle de sécurité en termes simples

Trois affirmations à vérifier :

Chiffrement de bout en bout via Noise. Le trafic entre le consommateur et le fournisseur est chiffré avec le cadre de protocole Noise, la même famille de poignées de main que celle utilisée par WireGuard et Signal. La couche de transport n'est pas le maillon faible.
Identifiants à portée limitée. Le consommateur n'obtient que ce qu'il a demandé (un domaine ou un ID d'élément de coffre-fort). Il ne peut pas énumérer le coffre-fort.
Aucun secret sur le disque du consommateur par défaut. aac run injecte les secrets via des variables d'environnement dans un processus enfant ; rien n'est écrit dans un fichier, rien n'apparaît dans la sortie standard, rien ne se retrouve dans l'historique du shell.

Ce qu'Agent Access ne protège pas contre :

Un processus consommateur compromis. Si l'agent est malveillant ou compromis, les identifiants à portée limitée fuient toujours. La défense est la portée, pas le protocole.
Un fournisseur compromis. Si votre coffre-fort Bitwarden lui-même est compromis, cette couche ne vous sert à rien.
L'entrée directe de secrets dans la fenêtre de contexte du LLM. Le README est explicite à ce sujet : « nous ne recommandons pas d'entrer des identifiants sensibles directement dans les LLM ou les agents IA ». aac run est la solution de contournement.

Un modèle courant : l'agent appelle l'API, Apidog la teste

Voici la boucle dans laquelle la plupart des équipes s'installeront :

L'agent écrit le code. Claude Code, Codex ou Cursor ouvre une PR touchant un point de terminaison.
La CI exécute les tests. Votre exécuteur de tests appelle aac run pour récupérer la clé API, exécute la suite de tests sur un déploiement de préproduction.
Apidog vérifie le contrat. Apidog exécute le test de contrat OpenAPI en tant qu'étape CI séparée, également via aac run, et aussi sans que l'agent ne voie la clé.

Le résultat : l'agent déploie le code, le contrat est respecté, le secret ne quitte jamais le coffre-fort. Le manuel plus large sur le test des changements pilotés par l'IA se trouve dans Comment tester les agents IA qui appellent vos API.

Limitations et avertissements

Préversion. Les API et les protocoles sont sujets à modification. N'ancrez pas un flux de travail de production sur le protocole v0 sans prévoir un budget pour une réécriture ultérieure.
Le CLI Bitwarden est requis par défaut. Le fournisseur par défaut est `bw` ; installez le CLI Bitwarden d'abord, ou passez `--provider example` pour le fournisseur de démonstration pendant les tests.
Pas encore de fichier de configuration. Agent Access est actuellement piloté par des drapeaux. Les invocations répétées nécessitent des scripts pour les gérer.
Ne collez pas de secrets dans les invites LLM. Même avec Agent Access installé, si vous copiez un identifiant dans une fenêtre de chat, aucun protocole ne peut vous sauver.

Questions fréquentes

Agent Access est-il gratuit ?

Oui. Le CLI, les SDK et le protocole sont open source sous l'organisation Bitwarden sur GitHub. Vous payez toujours pour Bitwarden si vous l'utilisez comme votre coffre-fort.

Fonctionne-t-il avec d'autres gestionnaires de mots de passe que Bitwarden ?

Le protocole est conçu pour être neutre vis-à-vis des fournisseurs. L'implémentation de référence est livrée avec le support Bitwarden et un fournisseur d'exemple ; d'autres fournisseurs sont censés livrer leurs propres fournisseurs au fil du temps.

Puis-je l'utiliser sans aucun gestionnaire de mots de passe ?

Pour les tests, oui ; passez `--provider example` pour utiliser le fournisseur de démonstration intégré. Pour la production, vous avez besoin d'un vrai fournisseur (Bitwarden aujourd'hui, d'autres sur la feuille de route).

Le processus consommateur a-t-il besoin d'un accès réseau ?

Le consommateur a besoin d'un accès réseau pour atteindre l'écouteur du fournisseur. Les configurations locales uniquement fonctionnent si l'écouteur et le consommateur sont sur le même hôte.

En quoi cela diffère-t-il d'un fichier `.env` ?

Un fichier `.env` se trouve sur le disque, est accidentellement intégré aux dépôts et est lisible par tout ce que l'agent peut exécuter. aac run conserve le secret uniquement dans la mémoire du processus, limité au sous-processus, et il disparaît à la fin de celui-ci.

Remplace-t-il HashiCorp Vault ou AWS Secrets Manager ?

Non. Les coffres-forts d'entreprise restent le bon outil pour les secrets de service à service à grande échelle. Agent Access comble le fossé des ordinateurs portables de développeurs et des exécuteurs CI, où un coffre-fort d'entreprise complet serait excessif.

Anthropic, OpenAI ou d'autres fournisseurs d'agents l'intégreront-ils directement ?

Non annoncé. Le modèle d'intégration actuel est de « envelopper vos scripts dans aac run ». Un support direct de premier ordre de la part des fournisseurs d'agents est la prochaine étape naturelle, mais n'est pas encore déployé.

Où puis-je signaler des bugs ou contribuer ?

Le dépôt GitHub. Les problèmes, les PR et les discussions sur le protocole s'y déroulent tous.

Essayez-le maintenant

Installez `aac`, exécutez `aac listen` sur votre ordinateur portable, exécutez `aac connect --provider example --domain test.com --output json` depuis un autre terminal. Confirmez que le JSON est renvoyé. C'est la plus petite boucle de bout en bout. À partir de là, remplacez le fournisseur d'exemple par `bw`, enveloppez un script réel dans aac run, et arrêtez de coller des clés API dans vos agents IA.

Associez Agent Access à Apidog pour le côté test API du flux de travail, et vous obtenez une séparation nette : le coffre-fort contient le secret, Apidog teste le contrat, l'agent déploie le code, et aucun identifiant ne quitte votre machine en texte brut.

bouton