AIエージェントに実キーを渡さないCredential Gateway設計

AIエージェントに実キーを渡すと、漏えい経路が増える

AI駆動開発では、エージェントがリポジトリを読み、APIを呼び、検証環境へ変更を加えます。便利な反面、環境変数や設定ファイルのトークンまで読める構成では、認証情報に触れる経路も増えます。

Hanwha Visionのファームウェアでは、CIジョブの環境変数をビルド成果物へ書き込む設定により、GitHub組織内で数百のリポジトリに管理者権限を持つトークンが見つかりました。約500件のファームウェアを抽出した調査では、62％のうち3件から同一トークンが検出されています。My security camera shipped a GitHub admin token in its login page

秘密情報は、読める場所に置いた時点で漏えい経路になります。エージェントの能力を広げる前に、認証情報を実行環境から切り離すべきです。

Credential Gatewayで認証情報を隔離する

Credential Gatewayは、AIエージェントと接続先サービスの間に置く認証の中継層です。OneCLIでは、エージェントにFAKE_KEYなどのプレースホルダーを渡し、ゲートウェイが対応する実キーへ置き換えてリクエストを送ります。Show HN: OneCLI – OSS credential gateway that keeps secrets out of AI agents

OneCLIのゲートウェイは、Proxy-Authorizationヘッダーのアクセストークンでエージェントを認証します。保存したシークレットはAES-256-GCMで暗号化し、ホスト名とパスのパターンに一致する通信にだけ、HTTPヘッダーまたはURLクエリとして注入します。

エージェントが持つのは実キーではなく、通信を依頼するための権限です。宛先、パス、エージェントごとのトークンを分けることで、権限の境界を実装に持ち込めます。

脆弱性検査では、検証先と権限を限定する

Claude Security Plugin for Claude Codeは、複数のエージェントでコードベースを調べ、別のエージェントが検出結果を検証します。対象はリポジトリ全体のほか、ブランチ、プルリクエスト、単一コミットの差分に絞れます。修正パッチは提案されますが、ユーザーのレビューと承認なしに自動適用されません。「Claude Code」プラグイン「Claude Security」がベータ公開

外部サービスを呼ぶ検査では、検査用エージェントに検査用のアクセストークンを発行します。許可するのは特定の検証APIと限定したパスだけにし、本番の管理APIや組織全体のGitHub権限は渡しません。修正案の評価と実環境への反映も、別の権限に分けます。

導入の分岐点は、外部通信を自動化するかどうか

コード生成をローカルで完結させ、外部サービスへ接続しないなら、Gatewayの優先度は高くありません。一方で、AIにGitHub、SaaS、社内API、検証環境を操作させるなら、導入を後回しにしない方がよいでしょう。

OneCLIはローカル単一ユーザーモードとGoogle OAuthによる複数ユーザーモードを備えます。Bitwardenなどと接続し、サーバーにシークレットを保存せず、必要なときだけ注入する運用も選べます。

判断基準は、エージェントごとのトークン失効、許可先の限定、通信ログの確認を運用できるかです。ここを整えられないなら、エージェントの自律性だけを先に上げるべきではありません。

まとめ

AIエージェントには実キーではなく、限定された依頼経路を渡します。次に追加するエージェントでは、必要なホストとパスを先に書き出し、その範囲だけをGatewayで許可してください。実キー、管理者権限、本番宛て通信を同じ設定に置かないことが、安全な実装・検証自動化の出発点です。