DEV Community

Cover image for Accès Sécurisé Agent Bitwarden : Partage de Mots de Passe Coffre-fort avec Agents IA
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

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 une API réelle, le problème arrive vite : l’agent a besoin d’identifiants, mais votre gestionnaire de mots de passe doit les protéger. Coller une clé API dans un chat l’inscrit dans le contexte du modèle. Mettre des secrets dans un fichier .env les rend lisibles par les commandes que l’agent peut exécuter. La bonne approche consiste à fournir uniquement le secret nécessaire, au bon processus, au bon moment.

Essayez Apidog aujourd’hui

Le projet open source de Bitwarden, Agent Access, propose une réponse concrète : un protocole de partage d’identifiants, un CLI (aac) et un SDK Rust + Python pour créer un tunnel chiffré entre un gestionnaire de mots de passe et un processus distant — agent IA, runner CI ou script local.

L’objectif : permettre à l’agent d’obtenir uniquement les secrets nécessaires, limités à un domaine ou à un élément de coffre-fort, sans jamais exposer l’intégralité du coffre-fort.

Ce guide montre comment installer Agent Access, utiliser aac connect et aac run, l’intégrer à Claude Code, Codex et Cursor, puis appliquer ce modèle aux workflows API décrits dans Comment sécuriser les identifiants API des agents IA.

Ce qu’est Agent Access

Agent Access est un protocole ouvert et une implémentation de référence créés par Bitwarden, mais pensés pour être adoptés par d’autres gestionnaires de mots de passe.

Le CLI aac établit un tunnel chiffré de bout en bout avec le protocole Noise.

Le modèle repose sur deux rôles :

  • Fournisseur : le processus qui a accès au coffre-fort et répond aux demandes.
  • Consommateur : l’agent, le script ou le runner CI qui demande un identifiant précis.

Le consommateur demande un identifiant par :

  • domaine ;
  • ou ID d’élément de coffre-fort.

Le fournisseur décide quoi renvoyer. Le consommateur ne peut pas parcourir le coffre-fort. Des journaux d’audit existent des deux côtés.

Agent Access

Agent Access est actuellement en préversion. Le README indique que les API et protocoles peuvent changer, et rappelle qu’il ne faut pas entrer directement des identifiants sensibles dans les LLM ou agents IA.

Le modèle recommandé est donc l’injection d’environnement via aac run : le secret est transmis au sous-processus qui en a besoin, sans passer par la fenêtre de contexte du modèle.

Pourquoi c’est important

Les agents de codage IA ne se limitent plus à suggérer du code. Claude Code, Codex, Cursor et d’autres outils peuvent :

  • lire un dépôt ;
  • exécuter des tests ;
  • appeler des API ;
  • lancer des scripts ;
  • déclencher des déploiements.

Chaque étape peut nécessiter des identifiants. L’incident Postman des clés API exposées a montré à quel point l’hygiène des secrets peut se dégrader dans les workflows humains. Avec des agents capables d’exécuter des commandes, le risque augmente.

La réponse n’est pas de faire davantage confiance à l’agent. C’est de lui donner moins.

Agent Access applique ce principe au niveau du protocole :

  • secrets limités à une portée précise ;
  • chiffrement en transit ;
  • récupération à l’exécution ;
  • disparition à la fin du processus.

Par rapport aux pratiques existantes listées dans API Key Management Tools, Agent Access cible spécifiquement les workflows agentiques.

Installation

Choisissez le binaire adapté à 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/
Enter fullscreen mode Exit fullscreen mode

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/
Enter fullscreen mode Exit fullscreen mode

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/
Enter fullscreen mode Exit fullscreen mode

Windows x86_64

Téléchargez aac-windows-x86_64.zip depuis la page des releases, puis extrayez le binaire dans un répertoire présent dans votre PATH.

Vérifiez l’installation :

aac --help
Enter fullscreen mode Exit fullscreen mode

Si le CLI Bitwarden (bw) est disponible dans votre PATH, aac l’utilise comme fournisseur par défaut.

Pour tester sans Bitwarden, utilisez le fournisseur de démonstration :

aac connect --provider example --domain test.com --output json
Enter fullscreen mode Exit fullscreen mode

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

Le flux minimal utilise deux terminaux.

Dans le premier terminal, lancez l’écouteur sur la machine qui contient le coffre-fort :

aac listen
Enter fullscreen mode Exit fullscreen mode

La commande affiche un jeton de couplage.

Dans un second terminal, côté consommateur, connectez-vous avec ce jeton et demandez un identifiant pour un domaine :

aac connect --token <jeton-de-couplage> --domain github.com --output json
Enter fullscreen mode Exit fullscreen mode

Réponse typique :

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

Votre script peut ensuite analyser ce JSON et utiliser les champs nécessaires.

Pour récupérer un identifiant par ID d’élément de coffre-fort :

aac connect --id <id-element-coffre-fort> --output json
Enter fullscreen mode Exit fullscreen mode

--id et --domain sont mutuellement exclusifs. Choisissez l’un des deux.

Les champs TOTP sont inclus dans la même charge utile si l’élément de coffre-fort en contient un.

Utiliser aac run pour injecter des secrets

aac connect est utile si votre script sait gérer du JSON.

Pour les workflows d’agents IA, aac run est souvent plus sûr et plus simple : il récupère un identifiant, puis exécute un processus enfant avec les secrets injectés comme variables d’environnement.

Les secrets ne sont pas :

  • écrits sur disque ;
  • imprimés sur stdout ;
  • visibles dans l’historique shell ;
  • exposés dans le contexte du modèle.

Injecter des champs spécifiques 

aac run \
  --domain example.com \
  --env DB_PASSWORD=motdepasse \
  --env DB_USER=nomutilisateur \
  -- psql
Enter fullscreen mode Exit fullscreen mode

Injecter tous les champs avec un préfixe AAC_ 

aac run --domain example.com --env-all -- ./deploy.sh
Enter fullscreen mode Exit fullscreen mode

Combiner valeurs par défaut et remplacements 

aac run \
  --domain example.com \
  --env-all \
  --env CUSTOM_PW=motdepasse \
  -- ./deploy.sh
Enter fullscreen mode Exit fullscreen mode

Champs disponibles :

  • username
  • password
  • totp
  • uri
  • notes
  • domain
  • credential_id

Exemple de modèle recommandé avec un agent :

aac run --domain api.stripe.com --env-all -- ./deploy.sh
Enter fullscreen mode Exit fullscreen mode

L’agent voit la commande, mais pas la valeur du secret. Le secret est uniquement disponible pour le sous-processus deploy.sh.

C’est le même principe d’isolation que dans Comment sécuriser les identifiants API des agents IA, appliqué avec un outil concret.

SDK Python et Rust

Si l’invocation CLI ne suffit pas, Agent Access fournit aussi des SDK.

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()
Enter fullscreen mode Exit fullscreen mode

Le module Python repose sur PyO3. L’implémentation principale reste en Rust, avec le même protocole Noise sous le capot.

Rust

Le SDK Rust expose également RemoteClient.

Les exemples de référence se trouvent dans le dépôt, sous :

examples/rust-remote/
Enter fullscreen mode Exit fullscreen mode

Utilisez le SDK Rust si vous développez :

  • un CLI ;
  • un runner de build ;
  • un service distribué sous forme de binaire compilé ;
  • un consommateur Agent Access intégré à votre propre outil.

Pour les équipes qui utilisent déjà des outils de gestion de secrets, ce modèle complète les intégrations comme HashiCorp Vault ou Azure Key Vault. Agent Access ne remplace pas nécessairement ces solutions d’entreprise, mais il s’adapte bien aux postes développeur et aux runners CI.

Intégration avec les agents de codage IA

Claude Code

Créez un script que Claude Code peut appeler, puis encapsulez l’accès au secret avec aac run.

Exemple :

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

Rendez le script exécutable :

chmod +x deploy.sh
Enter fullscreen mode Exit fullscreen mode

Puis demandez à Claude Code d’exécuter :

./deploy.sh
Enter fullscreen mode Exit fullscreen mode

L’agent ne reçoit aucun identifiant dans l’invite. Le secret est uniquement transmis à run-deploy.sh.

Pour la CI, le même modèle peut être appliqué avec l’intégration Claude Code GitHub Actions :

  1. installez aac dans le runner ;
  2. couplez le runner avec le fournisseur ;
  3. exécutez vos scripts via aac run.

OpenAI Codex

Le même modèle fonctionne avec le CLI Codex.

Exposez au modèle une commande ou un script contrôlé :

./test-api.sh
Enter fullscreen mode Exit fullscreen mode

Puis encapsulez les secrets dans ce script :

# test-api.sh
#!/usr/bin/env bash
aac run --domain staging.example.com --env-all -- ./run-api-tests.sh
Enter fullscreen mode Exit fullscreen mode

La couche d’appel d’outils de Codex voit la commande, pas la valeur du secret.

L’article Codex depuis votre téléphone couvre la surface plus large de Codex ; Agent Access ajoute ici la couche de protection des identifiants.

Cursor

Pour Cursor, utilisez le même pattern avec les commandes de terminal et les workflows Composer.

Exemple :

# local-check.sh
#!/usr/bin/env bash
aac run --domain dev.example.com --env-all -- npm test
Enter fullscreen mode Exit fullscreen mode

Cursor peut appeler ./local-check.sh, mais les secrets restent limités au sous-processus.

Comme Cursor travaille souvent localement, l’écouteur aac listen s’exécute généralement sur la même machine que le consommateur.

OpenClaw

Agent Access fournit une compétence OpenClaw officielle prête à l’emploi. Le dépôt contient un fichier SKILL.md.

Pour les équipes utilisant des compétences de style OpenClaw, cette intégration permet à la compétence de :

  1. connaître la forme du protocole ;
  2. récupérer l’identifiant ;
  3. le transmettre à l’outil aval exposé par la compétence.

Le guide des clés API OpenClaw couvre le sujet plus large de la gestion des identifiants dans cet écosystème.

Modèle de sécurité

Agent Access repose sur trois garanties principales.

1. Chiffrement de bout en bout

Le trafic entre consommateur et fournisseur est chiffré avec le framework Noise, la même famille de protocoles utilisée par des outils comme WireGuard et Signal.

2. Identifiants à portée limitée

Le consommateur demande un domaine ou un ID d’élément précis. Il ne peut pas énumérer tout le coffre-fort.

3. Pas de secret sur disque par défaut

Avec aac run, les secrets sont injectés comme variables d’environnement dans un sous-processus. Ils ne sont pas écrits dans un fichier et ne sont pas affichés dans la sortie standard.

Ce qu’Agent Access ne résout pas

Agent Access réduit la surface d’exposition, mais ne supprime pas tous les risques.

Il ne protège pas contre :

  • un processus consommateur compromis : si le script ou l’agent est malveillant, il peut toujours exfiltrer les secrets auxquels il a accès ;
  • un fournisseur compromis : si le coffre-fort lui-même est compromis, le protocole ne suffit plus ;
  • les secrets collés dans une invite LLM : si vous copiez une clé dans un chat, Agent Access ne peut pas l’effacer du contexte.

La défense principale reste la portée minimale : donnez au processus uniquement ce dont il a besoin.

Workflow API courant : agent, CI et Apidog

Un workflow pratique pour une équipe API ressemble à ceci :

  1. L’agent écrit le code

    Claude Code, Codex ou Cursor modifie un endpoint et ouvre une PR.

  2. La CI exécute les tests

    Le runner appelle aac run pour récupérer une clé API à portée limitée, puis lance les tests sur un environnement de préproduction.

  3. Apidog vérifie le contrat

    Apidog exécute les tests de contrat OpenAPI comme étape CI séparée, également via aac run.

Exemple de script CI :

#!/usr/bin/env bash
set -euo pipefail

aac run \
  --domain staging.example.com \
  --env-all \
  -- ./run-contract-tests.sh
Enter fullscreen mode Exit fullscreen mode

Résultat :

  • l’agent peut déclencher le workflow ;
  • la CI peut tester l’API ;
  • Apidog peut valider le contrat ;
  • le secret reste hors du contexte du modèle.

Le guide Comment tester les agents IA qui appellent vos API détaille cette approche côté test.

Limitations

Avant de l’adopter, gardez ces points en tête.

  • Préversion : les API et protocoles peuvent changer. Évitez de verrouiller un workflow critique sans prévoir de maintenance.
  • CLI Bitwarden requis par défaut : le fournisseur par défaut repose sur bw. Installez le CLI Bitwarden ou utilisez --provider example pour tester.
  • Pas encore de fichier de configuration : les invocations reposent principalement sur des flags. Utilisez des scripts pour standardiser les commandes.
  • Aucun outil ne protège un secret collé dans une invite : ne copiez jamais d’identifiants dans un chat LLM.

FAQ

Agent Access est-il gratuit ?

Oui. Le CLI, les SDK et le protocole sont open source dans l’organisation Bitwarden sur GitHub. Si vous utilisez Bitwarden comme coffre-fort, votre usage de Bitwarden reste soumis à son modèle habituel.

Fonctionne-t-il avec d’autres gestionnaires de mots de passe ?

Le protocole est conçu pour être neutre vis-à-vis des fournisseurs. L’implémentation de référence prend en charge Bitwarden et un fournisseur d’exemple. D’autres fournisseurs pourront implémenter leurs propres intégrations.

Puis-je l’utiliser sans gestionnaire de mots de passe ?

Pour tester, oui :

aac connect --provider example --domain test.com --output json
Enter fullscreen mode Exit fullscreen mode

Pour un usage réel, utilisez un fournisseur de secrets adapté, comme Bitwarden aujourd’hui.

Le processus consommateur a-t-il besoin du réseau ?

Oui, il doit pouvoir atteindre l’écouteur du fournisseur. Un usage local fonctionne si l’écouteur et le consommateur sont sur la même machine.

En quoi est-ce différent d’un fichier .env ?

Un fichier .env est stocké sur disque, peut être commité par erreur et peut être lu par tout processus que l’agent peut lancer.

Avec aac run, le secret est injecté uniquement dans le sous-processus ciblé et disparaît à la fin de son exécution.

Agent Access remplace-t-il HashiCorp Vault ou AWS Secrets Manager ?

Non. Les coffres-forts d’entreprise restent adaptés aux secrets service-à-service à grande échelle. Agent Access couvre surtout les workflows de développeurs, d’agents et de runners CI où il faut transmettre un secret limité à un processus spécifique.

Anthropic, OpenAI ou d’autres fournisseurs l’intègrent-ils directement ?

Aucune intégration directe n’est annoncée. Le modèle actuel consiste à envelopper vos scripts avec aac run.

Où signaler des bugs ou contribuer ?

Sur le dépôt GitHub Agent Access. Les issues, PR et discussions de protocole y sont centralisées.

Essayez-le maintenant

Testez la boucle minimale :

aac listen
Enter fullscreen mode Exit fullscreen mode

Puis, dans un autre terminal :

aac connect --provider example --domain test.com --output json
Enter fullscreen mode Exit fullscreen mode

Ensuite :

  1. remplacez le fournisseur d’exemple par Bitwarden ;
  2. enveloppez un script réel avec aac run ;
  3. retirez les clés API des prompts, fichiers .env et historiques shell.

Associez Agent Access à Apidog pour la partie test API : le coffre-fort garde le secret, Apidog teste le contrat, l’agent exécute le workflow, et aucun identifiant n’est exposé en clair.

Top comments (0)