DEV Community

Cover image for Bitwardenエージェントアクセス：AIコーディングエージェントと安全な資格情報共有方法
Akira
Akira

Posted on • Originally published at apidog.com

Bitwardenエージェントアクセス：AIコーディングエージェントと安全な資格情報共有方法

Claude Code、Codex、Cursor などの AI コーディングエージェントに実 API を触らせると、最初にぶつかるのが資格情報の扱いです。API キーをチャットに貼るとモデルのコンテキストに残り、.env に置くとエージェントの bash ツールから読めてしまいます。必要なのは「エージェントを信頼する」ことではなく、エージェントに渡す秘密情報を最小化する仕組みです。

今すぐ Apidog を試す

Bitwarden のオープンソースプロジェクト Agent Access は、この問題に対する資格情報共有プロトコル、CLI（aac）、Rust + Python SDK です。パスワードマネージャーとリモートプロセス（エージェント、CI ランナー、スクリプトなど）の間に暗号化トンネルを作り、必要なドメインまたは保管庫アイテムの資格情報だけを渡します。コンシューマー側が保管庫全体を見ることはありません。

この記事では、Agent Access のインストール、aac connect、aac run、Claude Code / Codex / Cursor での使い方、そして AI エージェント API 資格情報を保護する方法 で説明されている資格情報分離パターンとの関係を実装ベースで整理します。

Agent Access とは

Agent Access は Bitwarden が構築したオープンプロトコルとリファレンス実装です。CLI の aac は Noise プロトコル を使ってエンドツーエンド暗号化されたトンネルを作成します。

構成は次の通りです。

  • プロバイダー: 保管庫側。接続要求を待ち受け、返す資格情報を決定する
  • コンシューマー: エージェント、スクリプト、CI ジョブなど。ドメインまたは保管庫アイテム ID で資格情報を要求する
  • 資格情報のスコープ: 単一ドメインまたは単一アイテムに限定される
  • 監査証跡: プロバイダー側とコンシューマー側の両方に残る

Agent Access architecture

現時点では 早期プレビュー です。README では「API とプロトコルは変更される可能性があります」と明記されています。また、「機密性の高い資格情報を LLM や AI エージェントに直接入力することは推奨しません」と警告されています。

実運用で重要になるのは aac run です。これは秘密情報をエージェントのコンテキストに出さず、子プロセスの環境変数として注入します。

なぜ重要なのか

AI コーディングエージェントは、すでにリポジトリの編集だけでなく、テスト実行、API 呼び出し、デプロイまで行います。各ステップには資格情報が必要です。

しかし、資格情報を雑に扱うと漏洩リスクが高くなります。Postman の API キー漏洩事件 が示したように、人間だけでも API キー管理は破綻しがちです。そこにエージェントが加わると、.env、ログ、シェル履歴、プロンプト履歴が新たな漏洩経路になります。

Agent Access の基本方針は次の通りです。

  • 資格情報を実行時に取得する
  • 必要なドメインまたはアイテムだけに限定する
  • 転送中は暗号化する
  • プロセス終了後に秘密情報を残さない
  • LLM のコンテキストに秘密情報を入れない

既存の API キー管理ツール が一般的な秘密情報管理を扱うのに対し、Agent Access はエージェントとリモートプロセスのユースケースに焦点を当てています。

インストール

プラットフォームに合わせて aac をインストールします。

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

最新リリースページ から aac-windows-x86_64.zip をダウンロードし、PATH 上のディレクトリに展開します。

インストール後に確認します。

aac --help
Enter fullscreen mode Exit fullscreen mode

Bitwarden CLI（bw）が PATH にある場合、aac はそれをデフォルトの資格情報プロバイダーとして使います。Bitwarden CLI がない状態で試す場合は、デモプロバイダーとして --provider example を指定します。

クイックスタート: ペアリングして資格情報を取得する

まず、保管庫を持つマシンでリスナーを起動します。通常は開発者のラップトップです。

aac listen
Enter fullscreen mode Exit fullscreen mode

リスナーはペアリングトークンを出力します。

次に、コンシューマー側で接続します。リモートマシン、CI ランナー、または同じホスト上の別ターミナルで実行できます。

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

レスポンス例です。

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

ドメインではなく保管庫アイテム ID で取得する場合は、--id を使います。

aac connect --id <vault-item-id> --output json
Enter fullscreen mode Exit fullscreen mode

--id と --domain は同時に指定できません。どちらか一方を選びます。

保管庫アイテムに TOTP が設定されている場合、TOTP コードも同じペイロードで返されます。

実運用パターン: aac run で環境変数を注入する

aac connect は JSON を返すので、スクリプトからパースして使えます。ただし、AI エージェントや CI でより安全に扱うなら aac run を使います。

aac run は次の処理を行います。

  1. 資格情報を取得する
  2. 指定したフィールドを環境変数として注入する
  3. 子プロセスを実行する
  4. 標準出力、ディスク、親プロセスに秘密情報を出さない

特定フィールドだけを注入する 

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

この例では、保管庫の password を DB_PASSWORD に、username を DB_USER にマッピングします。

すべてのフィールドを注入する 

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

--env-all を使うと、利用可能なフィールドが AAC_ プレフィックス付きで注入されます。

デフォルト注入と個別上書きを組み合わせる 

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

利用可能なフィールドは次の通りです。

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

Bitwarden が AI エージェント向けに推奨しているのは、この aac run パターンです。

エージェントには次のようなコマンドだけを見せます。

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

モデルはパスワードや API キーの値を見ません。秘密情報は deploy.sh のサブプロセスにだけ渡されます。

この考え方は、AI エージェント API 資格情報を保護する方法 で説明されている分離原則と同じです。

Python SDK を使う

CLI ではなくアプリケーションに直接組み込みたい場合は、Python SDK を使えます。

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

Python モジュールは PyO3 をバックエンドに使います。重い処理は Rust 側で実行され、内部では同じ Noise プロトコル実装が使われます。

ただし、AI エージェントに対しては、資格情報を print() したりログに出したりしない設計にしてください。SDK を使う場合でも、秘密情報は下流処理に直接渡すのが基本です。

Rust SDK を使う

Rust SDK も RemoteClient インターフェースを提供しています。リファレンス実装はリポジトリの examples/rust-remote/ にあります。

Rust SDK が向いているケースは次の通りです。

  • 独自 CLI ツールに資格情報取得を組み込む
  • ビルドランナーを実装する
  • コンパイル済みバイナリとして配布する
  • エージェントが呼び出すローカルツールに組み込む

既に API ツールを提供しているチームでは、HashiCorp Vault や Azure Key Vault との統合と併用できます。Agent Access はそれらのエンタープライズ保管庫を置き換えるものではなく、開発者ラップトップや CI ランナーでのエージェント利用に向いた補完レイヤーです。

Claude Code で使う

Claude Code には、資格情報を直接渡さず、aac run でラップしたスクリプトを実行させます。

例として、デプロイスクリプトを用意します。

# deploy.sh
#!/usr/bin/env bash

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

実行権限を付けます。

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

Claude Code には ./deploy.sh を実行させます。プロンプトには API キーを書きません。

./deploy.sh を実行してステージング環境へデプロイしてください。
Enter fullscreen mode Exit fullscreen mode

この場合、Claude Code が見るのはコマンドだけです。秘密情報は run-deploy.sh の子プロセスにだけ渡されます。

Claude Code GitHub Actions のような CI 統合でも同じ考え方を使えます。ランナーに aac をインストールし、保管庫プロバイダーとペアリングして、ジョブ実行時に必要な資格情報だけを取得します。

OpenAI Codex で使う

Codex CLI でも同じです。Codex にはスクリプトを呼ばせ、スクリプト内で aac run を使います。

# test-api.sh
#!/usr/bin/env bash

aac run --domain staging.example.com --env-all -- npm run test:api
Enter fullscreen mode Exit fullscreen mode

Codex への指示は、資格情報ではなくタスクに限定します。

test-api.sh を実行し、失敗した API テストを修正してください。
Enter fullscreen mode Exit fullscreen mode

Codex のツール呼び出しレイヤーにはコマンドが見えますが、秘密情報の値はモデルのコンテキスト外に残ります。

スマホからの Codex のようなワークフローでも、資格情報側はこの分離パターンで扱えます。

Cursor で使う

Cursor のターミナルコマンドや Composer ワークフローでも、aac run でラップしたスクリプトをそのまま使えます。

ローカル編集が中心の場合、リスナーとコンシューマーは同じマシン上で動かすことが多くなります。

aac listen
Enter fullscreen mode Exit fullscreen mode

別ターミナルまたは Cursor から次を実行します。

aac run --domain local.example.com --env-all -- npm run dev
Enter fullscreen mode Exit fullscreen mode

Cursor に .env の中身を読ませるのではなく、必要なコマンドを aac run 経由に寄せるのがポイントです。

OpenClaw で使う

Agent Access は公式の OpenClaw スキル を提供しています。リポジトリには SKILL.md が含まれています。

OpenClaw スタイルのスキルを使っているチームでは、スキル側がプロトコル形式を認識し、資格情報を取得して下流ツールへ渡します。

OpenClaw API キーガイド では、このエコシステムでの資格情報管理をより広く扱っています。

セキュリティモデル

Agent Access のセキュリティ上のポイントは次の 3 つです。

1. Noise によるエンドツーエンド暗号化

コンシューマーとプロバイダー間の通信は Noise プロトコルフレームワーク で暗号化されます。Noise は WireGuard や Signal でも使われるハンドシェイクファミリーです。

2. 資格情報はスコープされる

コンシューマーが取得できるのは、要求した単一ドメインまたは単一保管庫アイテム ID の資格情報だけです。保管庫全体を列挙することはできません。

3. aac run は秘密情報をディスクに書かない

aac run は秘密情報を環境変数として子プロセスに渡します。ファイルに書き込まず、標準出力に出さず、シェル履歴にも残しません。

Agent Access が防がないもの

Agent Access は万能ではありません。次のリスクは残ります。

  • 侵害されたコンシューマープロセス

    エージェントまたは子プロセスが悪意ある動作をすれば、スコープされた資格情報も漏洩し得ます。

  • 侵害されたプロバイダー

    Bitwarden 保管庫自体が侵害されていれば、このレイヤーでは守れません。

  • LLM への直接貼り付け

    API キーをチャットやプロンプトに貼った時点で、Agent Access の外側に漏れます。README でも、機密資格情報を LLM や AI エージェントに直接入力しないよう明記されています。

実装パターン: エージェントが API を変更し、Apidog が契約を検証する

AI エージェントを API 開発に入れる場合、実用的なループは次の形です。

  1. エージェントがコードを変更する

    Claude Code、Codex、Cursor がエンドポイント変更の PR を作る。

  2. CI がテストを実行する

    テストランナーが aac run で API キーを取得し、ステージング環境に対してテストを実行する。

  3. Apidog が契約を検証する

    Apidog で OpenAPI 契約テストを別 CI ステップとして実行する。このステップも aac run 経由にする。

例です。

aac run \
  --domain staging-api.example.com \
  --env API_TOKEN=password \
  -- npm run test:contract
Enter fullscreen mode Exit fullscreen mode

この構成では、エージェントはコードを変更できますが、API キーの値は見ません。契約テストは Apidog 側で実行され、秘密情報は保管庫から必要なプロセスにだけ渡されます。

AI 駆動の API 変更をテストする全体像は、API を呼び出す AI エージェントをテストする方法 でも整理されています。

制限事項

現時点で注意すべき点です。

  • 早期プレビュー

    API とプロトコルは変更される可能性があります。本番ワークフローに固定する場合は、将来の追従コストを見込んでください。

  • デフォルトでは Bitwarden CLI が必要

    デフォルトのプロバイダーは bw です。Bitwarden CLI をインストールするか、検証時は --provider example を使います。

  • 設定ファイルはまだない

    現状はフラグ駆動です。繰り返し使うコマンドはスクリプト化するのが現実的です。

  • LLM プロンプトに秘密情報を貼らない

    Agent Access を入れていても、資格情報をチャットに貼れば保護できません。

FAQ

Agent Access は無料ですか？

はい。CLI、SDK、プロトコルは Bitwarden の GitHub 組織でオープンソースとして公開されています。ただし、保管庫として Bitwarden を使う場合は、Bitwarden の利用条件や料金が適用されます。

Bitwarden 以外でも使えますか？

プロトコルはベンダーニュートラルに設計されています。リファレンス実装には Bitwarden サポートとサンプルプロバイダーが含まれています。他のベンダーが独自プロバイダーを提供する余地があります。

パスワードマネージャーなしで試せますか？

検証目的なら可能です。デモプロバイダーを使います。

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

本番利用では実際のプロバイダーが必要です。

コンシューマープロセスにネットワークアクセスは必要ですか？

はい。コンシューマーはプロバイダーのリスナーに到達できる必要があります。リスナーとコンシューマーが同じホストにある場合は、ローカルだけでも構成できます。

.env と何が違いますか？

.env はディスク上に存在します。誤ってリポジトリにコミットされる可能性があり、エージェントがシェルを実行できるなら読み取れます。

aac run は秘密情報をプロセスメモリ上に限定し、子プロセスにスコープします。プロセス終了後は残りません。

HashiCorp Vault や AWS Secrets Manager の代替ですか？

いいえ。大規模なサービス間秘密情報管理では、HashiCorp Vault や AWS Secrets Manager のようなエンタープライズ向け保管庫が引き続き適しています。

Agent Access は、開発者ラップトップ、AI エージェント、CI ランナーのようなギャップを埋めるための仕組みです。

Anthropic や OpenAI は直接統合していますか？

現時点で発表されていません。現在の統合モデルは、エージェントが呼ぶスクリプトを aac run でラップする形です。

バグ報告や貢献はどこで行いますか？

GitHub リポジトリ で issue、pull request、プロトコル議論を行えます。

まず試す手順

最小構成で試すなら、次の順番です。

  1. aac をインストールする
  2. ラップトップでリスナーを起動する 
aac listen
Enter fullscreen mode Exit fullscreen mode
  1. 別ターミナルでデモプロバイダーを使って接続する 
aac connect --provider example --domain test.com --output json
Enter fullscreen mode Exit fullscreen mode
  1. JSON が返ることを確認する
  2. デモプロバイダーを bw に置き換える
  3. 実際のスクリプトを aac run でラップする
  4. API キーを AI エージェントに貼り付ける運用をやめる

API テスト側では、Agent Access と Apidog を組み合わせると責務を分離できます。

  • 保管庫が秘密情報を保持する
  • Agent Access が実行時に必要最小限の資格情報を渡す
  • Apidog が API 契約を検証する
  • AI エージェントはコード変更に集中する

この形にすると、エージェントを開発ワークフローに入れつつ、資格情報をプロンプト、.env、ログ、シェル履歴から切り離せます。

Top comments (0)