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

Claude Code、Codex、または Cursor を実際の API に触れるものと一緒に使用すると問題が発生します。エージェントには資格情報が必要ですが、パスワードマネージャーはそれらをロックしたままにしたいからです。一般的な回避策は良くありません。API キーをチャットに貼り付けると、モデルのコンテキストウィンドウに永遠に残ります。秘密情報を .env ファイルに保存すると、エージェントの bash ツールが喜んでそれらを cat で読み取り、どこかへ送ってしまいます。ほとんどのチームは単に基準を下げているだけです。

Bitwarden の新しいオープンソースプロジェクトである Agent Access は、この問題を解決するための初めての本格的な試みです。これは、パスワードマネージャーとリモートプロセス（エージェント、CI ランナー、スクリプトなど）の間に暗号化されたトンネルを構築する資格情報共有プロトコル、CLI（aac）、および Rust + Python SDK です。エージェントは、単一のドメインまたは保管庫アイテムに限定された必要な秘密情報を、保管庫自体を見るこなく取得できます。

このガイドでは、Agent Access が提供するもの、そのインストール方法、aac connect と aac run の使用方法、Claude Code、Codex、Cursor のワークフローへの適合方法、および AI エージェント API 資格情報を保護する方法で説明されている資格情報管理パターンとの関連性について説明します。

Agent Access とは（1段落）

Agent Access は、Bitwarden によって構築されましたが、任意のパスワードマネージャーが採用できるように設計されたオープンプロトコルとリファレンス実装です。CLI（aac）は、Noise プロトコルを使用してエンドツーエンドで暗号化されたトンネルを作成します。「プロバイダー」は接続要求をリッスンし、「コンシューマー」（エージェント、スクリプト、CI ジョブなど）はプロバイダーに接続し、ドメインまたは保管庫アイテム ID で資格情報を要求します。プロバイダーは何を返送するかを決定します。コンシューマーが保管庫全体を見ることは決してありません。プロバイダーは、コンシューマーが資格情報をどう利用するかを認識することはありません。監査証跡は両側に存在します。

これは現在、早期プレビュー段階にあります。プロジェクトの README には、「API とプロトコルは変更される可能性があります」および「機密性の高い資格情報を LLM や AI エージェントに直接入力することは推奨しません」と警告されています。Bitwarden が代わりに推奨するパターンは、このガイドの半分を占めるテーマです。それは aac run を介した環境インジェクションであり、これによりエージェントのコンテキストウィンドウに秘密情報を公開することなく、プロセスに秘密情報を渡します。

なぜ2026年にこれが重要なのか

AI コーディングエージェントはサンドボックスを越え始めました。Claude Code、Codex、Cursor などは、現在リポジトリを読み込み、テストを実行し、API を叩き、コードをデプロイします。これらの各ステップには資格情報が必要です。Postman の API キー漏洩事件は、人間だけでもずさんな場合に資格情報管理がどれほどひどく破綻するかを示しました。人間とエージェントが一緒になると、さらに悪化します。

正しい答えは「エージェントをもっと信頼する」ことではなく、「エージェントに与えるものを減らす」ことです。Agent Access はプロトコルレベルでこれを実現します。範囲限定された資格情報、転送中に暗号化され、実行時にフェッチされ、プロセスが終了すると消滅します。現在の慣行（API キー管理ツールがその他の状況をカバーしています）と比較すると、Agent Access はエージェントのケースに特化して構築された最初のものです。

インストール

プラットフォームを選択してください。

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)

最新リリースページから aac-windows-x86_64.zip をダウンロードし、PATH 上の任意のディレクトリに展開してください。

aac --help でインストールを確認します。Bitwarden CLI（bw）も PATH に含まれている場合、aac はそれをデフォルトの資格情報プロバイダーとして使用します。そうでない場合は、実験中に組み込みのデモプロバイダーを使用するために --provider example を渡してください。

クイックスタート: 資格情報のペアリングとフェッチ

2つのコマンドです。保管庫を保持しているマシン（通常はラップトップ）で aac listen を実行します。

aac listen

リスナーがペアリングトークンを出力します。コンシューマー側（リモートマシン、CI ランナー、またはテスト中に同じホスト上の別のシェル）で、1回の呼び出しでペアリングとフェッチを行います。

aac connect --token <pairing-token> --domain github.com --output json

次のようなものが返されます。

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

この JSON 形式はプロトコルの安定した契約です。スクリプトは好きなようにパースできます。ドメインではなく保管庫アイテム ID でフェッチするには、次のようにします。

aac connect --id <vault-item-id> --output json

--id と --domain は相互排他的です。いずれかを選択してください。保管庫アイテムに TOTP が設定されている場合、TOTP コードも同じペイロードを通じて流れます。

目玉機能: 環境インジェクションのための `aac run`

スクリプトが JSON の処理方法を知っている場合は、aac connect で問題ありません。しかし、より重要なパターンは aac run です。これは資格情報をフェッチし、秘密情報を環境変数として注入して子プロセスを実行します。標準出力にも、ディスクにも、aac を起動したプロセスにも決して表示されません。

特定のフィールドを注入する：

aac run --domain example.com --env DB_PASSWORD=password --env DB_USER=username -- psql

すべてのフィールドに AAC_ プレフィックスを付けて注入する：

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

デフォルトと上書きを組み合わせる：

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

利用可能なフィールドは username、password、totp、uri、notes、domain、および credential_id です。

これは Bitwarden が AI エージェントの使用に積極的に推奨するパターンです。Claude Code や Codex を aac run を呼び出すスクリプトに向けることで、秘密情報がエージェントのトランスクリプトに現れることはありません。モデルはパスワードではなく、aac run --domain api.stripe.com --env-all -- ./deploy.sh というコマンドを見ます。もしエージェントが後で「$STRIPE_API_KEY の値は何ですか？」と尋ねても、その答えは「見えません」となります。これは、その値が deploy.sh サブプロセスに限定されていたためです。

これは、AI エージェント API 資格情報を保護する方法で説明されている分離原則と同じもので、実際のツールで具体化されています。

Python および Rust SDK

CLI の呼び出しだけでは不十分な場合（例えば、Agent Access を独自のアプリケーションに組み込む場合など）は、ファーストクラスのバインディングがあります。

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

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

Rust

Rust SDK は、ファーストクラスライブラリとして同じ RemoteClient インターフェースを公開しています。リファレンス実装はリポジトリの examples/rust-remote/ 以下にあります。コンシューマーを Rust で直接記述する場合に使用してください。CLI ツール、ビルドランナー、およびコンパイル済みバイナリ配布を必要とするあらゆるサービスで一般的です。

すでに API ツールを提供しているアプリケーションチームにとって、SDK パターンは HashiCorp Vault や Azure Key Vault との統合と並んでうまく機能します。Agent Access はエンタープライズ層におけるそれらの代替品ではありませんが、開発者のラップトップや CI ランナーのユースケースにはより適しています。

AI コーディングエージェントとの統合

Claude Code

Claude Code が呼び出すスクリプトに aac run を組み込みます。デプロイタスクの例：

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

このスクリプトをプロジェクトに追加し、Claude Code ワークフローをそれに向けさせると、エージェントはプロンプトに資格情報なしで ./deploy.sh を呼び出します。Claude Code GitHub Actions 統合は、同じパターンを CI に拡張します。ランナーに aac をインストールし、コントロールプレーンで実行されている Bitwarden 保管庫プロバイダーとペアリングすることで、GitHub Actions はジョブ実行時にスコープ付き資格情報を継承します。

OpenAI Codex

同じパターンが Codex の CLI でも機能します。Codex のツール呼び出しレイヤーはモデルにコマンドを提示し、モデルが呼び出すスクリプトは aac run を介して秘密情報を取得し、秘密情報はモデルのコンテキスト外に保持されます。最近のスマホからの Codex の記事は Codex のより広範な機能について説明していますが、これはそれと対になる資格情報の側面です。

Cursor

Cursor のターミナルコマンドや Composer ワークフローでは、同じ aac run でラップされたスクリプトが修正なしで機能します。Cursor の強みはローカル編集であるため、リスナーは通常同じマシン上で実行されます。

OpenClaw (Anthropic エコシステムスキル)

Agent Access は公式の OpenClaw スキルを標準で提供しています（リポジトリに SKILL.md があります）。OpenClaw スタイルのスキルを使用するチームにとって、これは現在最も洗練された統合です。スキルはプロトコル形式を認識し、資格情報をフェッチし、スキルが公開する下流のツールにそれらを渡します。OpenClaw API キーガイドは、そのエコシステムにおけるより広範な資格情報管理について説明しています。

平易な言葉で説明するセキュリティモデル

確認すべき3つの主張：

Noise を介したエンドツーエンド暗号化。コンシューマーとプロバイダー間のトラフィックは、WireGuard や Signal が使用するのと同じハンドシェイクファミリーである Noise プロトコルフレームワークで暗号化されます。トランスポート層が最も弱いリンクではありません。
スコープ付き資格情報。コンシューマーは要求したもの（単一のドメインまたは単一の保管庫アイテム ID）のみを取得します。保管庫を列挙することはできません。
デフォルトではコンシューマーのディスクに秘密情報なし。aac run は、秘密情報を環境変数を通じて子プロセスにパイプします。ファイルに書き込まれることはなく、標準出力に表示されることもなく、シェル履歴に残ることもありません。

Agent Access が保護しないもの：

侵害されたコンシューマープロセス。エージェントが悪意のある、または侵害されている場合、範囲限定された資格情報も漏洩します。防御策はプロトコルではなくスコープです。
侵害されたプロバイダー。Bitwarden の保管庫自体が侵害された場合、このレイヤーは何の役にも立ちません。
LLM のコンテキストウィンドウに秘密情報を直接入力すること。README はこの点について明確に述べています。「機密性の高い資格情報を LLM や AI エージェントに直接入力することは推奨しません。」aac run がその回避策です。

一般的なパターン: エージェントが API を呼び出し、Apidog がそれをテストする

ほとんどのチームが採用するループは次のとおりです。

エージェントがコードを記述する。Claude Code、Codex、または Cursor がエンドポイントに触れる PR を開きます。
CI がテストを実行する。テストランナーが aac run を呼び出して API キーをフェッチし、ステージングデプロイメントに対してテストスイートを実行します。
Apidog が契約を検証する。Apidog は、OpenAPI 契約テストを別の CI ステップとして実行します。これも aac run を介して行われ、エージェントがキーを見ることはありません。

結果：エージェントがコードを出荷し、契約が保持され、秘密情報は保管庫から決して離れません。AI 駆動型の変更をテストするためのより広範なプレイブックは、API を呼び出す AI エージェントをテストする方法にあります。

制限事項と警告

早期プレビュー。API とプロトコルは変更される可能性があります。フォローアップの書き直し予算がない限り、本番ワークフローを v0 プロトコルに固定しないでください。
デフォルトで Bitwarden CLI が必要。デフォルトのプロバイダーは bw です。Bitwarden CLI を最初にインストールするか、テスト中にデモプロバイダーを使用するために --provider example を渡してください。
設定ファイルはまだありません。Agent Access は現在、フラグ駆動型です。繰り返し呼び出す場合は、それらをスクリプトで囲む必要があります。
秘密情報を LLM プロンプトに貼り付けないでください。Agent Access がインストールされていても、資格情報をチャットウィンドウにコピーすると、どのプロトコルもあなたを救うことはできません。

よくある質問

Agent Access は無料ですか？

はい、そうです。CLI、SDK、およびプロトコルは、Bitwarden の GitHub 組織の下でオープンソースです。保管庫として Bitwarden を使用している場合は、引き続き Bitwarden の料金を支払う必要があります。

Bitwarden 以外のパスワードマネージャーでも動作しますか？

プロトコルはベンダーニュートラルに設計されています。リファレンス実装には Bitwarden サポートとサンプルプロバイダーが含まれています。他のベンダーも時間の経過とともに独自のプロバイダーを提供することが期待されています。

パスワードマネージャーなしで利用できますか？

テスト目的であれば、はい。組み込みのデモプロバイダーを使用するには --provider example を渡してください。本番環境では、実際のプロバイダーが必要です（現在は Bitwarden、その他はロードマップにあります）。

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

コンシューマーはプロバイダーのリスナーに到達するためにネットワークアクセスが必要です。リスナーとコンシューマーが同じホスト上にある場合は、ローカルのみのセットアップで動作します。

`.env` ファイルとどう違うのですか？

.env ファイルはディスク上に存在し、誤ってリポジトリにチェックインされる可能性があり、エージェントが実行できるものなら何でも読み取ることができます。aac run は、秘密情報をプロセスメモリ内のみに保持し、サブプロセスにスコープされ、終了すると消滅します。

HashiCorp Vault や AWS Secrets Manager の代替になりますか？

いいえ。エンタープライズの保管庫は、大規模なサービス間秘密情報には依然として適切なツールです。Agent Access は、完全なエンタープライズ保管庫では過剰となる開発者のラップトップや CI ランナーのギャップを埋めます。

Anthropic、OpenAI、その他のエージェントベンダーはこれを直接統合しますか？

発表されていません。現在の統合モデルは「スクリプトを aac run でラップする」というものです。エージェントベンダーからの直接的でファーストクラスのサポートは次の自然なステップですが、まだ提供されていません。

バグを報告したり貢献したりするにはどうすればよいですか？

GitHub リポジトリです。問題、プルリクエスト、プロトコルに関する議論はすべてそこで行われます。

今すぐ試す

aac をインストールし、ラップトップで aac listen を実行し、別のターミナルから aac connect --provider example --domain test.com --output json を実行します。JSON が返ってくることを確認してください。これが最小のエンドツーエンドループです。そこから、例のプロバイダーを bw に置き換え、実際のスクリプトを aac run でラップし、API キーを AI エージェントに貼り付けるのをやめましょう。

ワークフローの API テスト側で Agent Access を Apidog と組み合わせると、明確な分離が実現します。保管庫が秘密情報を保持し、Apidog が契約をテストし、エージェントがコードを出荷し、いかなる資格情報もプレーンテキストであなたのマシンから離れることはありません。

ボタン