APIキーやパスワードをAIエージェントに渡さない:認証情報の扱い方と代わりの渡し方

値を貼ると何が困るのか

会話に貼った文字列は、その会話の履歴の一部になります。履歴は画面の外にも残りえます。たとえばClaude Codeのセキュリティ解説には、Remote Controlで接続している間は会話の記録が同期のためAnthropicのサーバーに保存される、という説明があります。

履歴がどこにどれだけ残るかは製品やプランで違います。確実に言えるのは、貼った時点で「自分の手元だけにある秘密」ではなくなることです。学習に使うかどうかの設定は、秘密を守ることとは別の話です。学習利用をオフにしても、履歴や共有、ログから漏れる可能性はなくなりません。

もう一つはエージェントが読めるファイルの範囲です。同じ解説では、サンドボックスを使うときの読み取りは既定でマシン全体に及び、~/.ssh や ~/.aws/credentials のような認証情報ファイルも含まれると書かれています(Claude Codeのサンドボックス解説)。サンドボックスをオンにしただけでは、鍵ファイルは守られません。

渡し方ごとの比較表

次の表は、公式資料の内容を踏まえた編集部の整理です。実測ではなく、考え方の目安として使ってください。

• チャットに値を貼る、漏れる主な経路：会話履歴、共有リンク、画面共有、ログ、失効のしやすさ：発行元で止めるしかなく、どこに残ったか追いにくい、判断：避ける
• 指示ファイルや依頼文に書く(CLAUDE.mdなど)、漏れる主な経路：リポジトリへのコミット、チーム共有、失効のしやすさ：履歴に残るため、削除より先に失効が必要、判断：避ける
• 設定ファイルに直書きしてコミット(.mcp.jsonなど)、漏れる主な経路：公開・共有リポジトリ、フォーク、失効のしやすさ：同上。コピーが広がりやすい、判断：避ける
• .env をエージェントが読める場所に置く、漏れる主な経路：ファイル読み取り、出力への混入、失効のしやすさ：発行元で再発行すれば止められる、判断：読ませない設定とセットで限定的に
• 環境変数を参照する(${VAR})、漏れる主な経路：同じ環境で動くコマンドの出力、失効のしやすさ：環境変数を差し替えれば更新できる、判断：ローカル作業の現実解
• OAuthでログインする、漏れる主な経路：トークンの保管場所(端末のキーチェーン等)、失効のしやすさ：サービス側で連携解除できる、判断：対応サービスなら第一候補
• 実行基盤が鍵を持ち、エージェントには見せない、漏れる主な経路：基盤側の設定ミス、失効のしやすさ：基盤側で一括して止められる、判断：業務利用ならここを目指す

最後の行の例が、Claude Codeのクラウド実行です。GitHubの認証情報はAnthropic側で暗号化されて保管され、セッションのVMには入りません。VMが持つのはそのセッション限りの短命な認証情報で、GitHubへの通信は代理経由で認証情報が付与されます(セキュリティ解説)。エージェントが鍵そのものを持たない設計の実例です。

やってはいけない例

以下のキーはすべて説明用の架空の値です。

1. チャットに貼る:「sk-EXAMPLE-0000 がAPIキーです。これで動かして」。値を見せなくても、環境変数の名前だけで足ります。
2. パスワードを教えてログインさせる:代わりに、人がログインした状態のセッションや、OAuthの連携を使います。
3. キーを設定ファイルに直書きしてコミットする:"Authorization": "Bearer EXAMPLE-TOKEN" のように書くと、リポジトリを共有した全員に渡ります。
4. 管理者権限のキーを「面倒だから」渡す:MCPのセキュリティのベストプラクティスも、広すぎる権限(admin:* のようなもの)は漏れたときの被害が大きく、失効の影響も広がると指摘しています。必要最小限の権限から始める考え方です。
5. 鍵を出力させて確認する:「env を実行して中身を見せて」や「.env の内容を貼って」は、鍵を会話に出す操作です。確認は「設定されているか(あり/なし)」だけで足ります。

代わりの渡し方:手順

環境変数で参照する

Claude Codeの.mcp.jsonは、${VAR} の形で環境変数を参照できます。${VAR:-default} なら未設定時の既定値も使えます。対象はcommand、args、env、url、headersなどです(MCPの設定解説)。説明用の例です。

{
  "mcpServers": {
    "my-api": {
      "type": "http",
      "url": "https://api.example.com/mcp",
      "headers": { "Authorization": "Bearer ${MY_API_TOKEN}" }
    }
  }
}

こうすれば、コミットされるファイルには変数名だけが残ります。値は自分のシェルやOSの仕組みで用意します。同じ解説には、秘密をバージョン管理に入れず環境変数の参照にすること、データベースには読み取り専用のユーザーを使うことも書かれています。

ただし環境変数は、同じ環境で動くコマンドからは読める場合があります。気になるなら次の項目を併用してください。

OAuthで連携する

OAuthに対応したリモートのMCPサーバーなら、claude mcp add --transport http <名前> <URL> で追加し、Claude Code内の /mcp からブラウザでログインできます。キーを人が扱わずに済み、不要になれば claude mcp logout <名前> でログアウトできます(同じ解説より)。連携を切る操作はサービス側の画面でも確認してください。

鍵ファイルや環境変数を見せない

サンドボックスの sandbox.credentials では、特定のファイルや環境変数を deny(拒否)にできます。同じ解説に載っている形は次のとおりです。

{
  "sandbox": {
    "credentials": {
      "files": [{ "path": "~/.ssh", "mode": "deny" }],
      "envVars": [{ "name": "GITHUB_TOKEN", "mode": "deny" }]
    }
  }
}

mask を選ぶと、エージェントにはプレースホルダが見え、許可された通信で実際の値に置き換わる仕組みもあります(TLSの終端が必要で、macOSではファイルのマスクは使えず拒否になる、と書かれています)。

MCPサーバーを作る側の注意

自分でサーバーを作るなら、クライアントから受け取ったトークンをそのまま下流のAPIに流す「トークンのパススルー」は禁止です。そのサーバー宛てに発行されたトークンだけを受け付けます(MCPのセキュリティのベストプラクティス)。これは公開中のドラフト版の記述なので、実装時は最新版を確認してください。

漏らしてしまったときの順番

説明用の手順です。

1. まず発行元で失効させる。履歴やコミットの削除より先です。消しても、すでにコピーされていれば意味がありません。
2. 発行元の利用履歴を見て、心当たりのない利用がないか確認する。
3. 必要な操作だけに絞った権限で再発行する。
4. 新しい値は、チャットではなく環境変数やOAuthで渡し直す。
5. 貼った履歴・コミットは、後から整理する。

そのまま使える依頼文

秘密を渡さずに作業を任せる例です(動作は未検証の説明用です)。

このリポジトリのAPI連携を実装してください。
・認証情報は環境変数 MY_API_TOKEN に入っています。値は表示・ログ出力・コミットをしないでください。
・.env や ~/.ssh など鍵が入っていそうなファイルは開かないでください。
・設定の確認は「MY_API_TOKEN が設定されているか(あり/なし)」だけ報告してください。
・設定ファイルには ${MY_API_TOKEN} のような参照だけを書いてください。

点検を頼むときの依頼文です。

このリポジトリの変更差分に、APIキー・トークン・パスワードらしき文字列がないか確認してください。
見つけたら、値は伏せてファイル名と行番号だけ報告してください。

人が確認する点は三つです。差分に秘密が入っていないか、権限が必要最小限か、不要になった連携が残っていないかです。AIの「入っていません」という報告だけを根拠にせず、コミットの前に自分でも見てください。