「APIキーは.envに」はもう危ない AIエージェントに渡す権限の決め方

AIエージェントを社内のシステムにつなぐとき、APIキーを.envファイルに書いて読み込ませる方法がよく使われます。@ITの連載は、このやり方がエージェントを「内通者」に変えると指摘しました。Appleの10月2日の発表も手がかりに、エージェントに渡す権限の決め方を整理します。

なぜ「.envにAPIキー」が危ないのか

.envは、アプリの設定や秘密の値を書いておくテキストファイルです。APIキーは、ほかのサービスを呼び出すための合言葉にあたります。人がアプリを動かすだけなら、この方法で大きな問題は起きにくいものでした。

AIエージェントは、ファイルを読み、コマンドを実行し、外部と通信します。同じフォルダにある.envも、エージェントにとっては読めるファイルの一つです。エージェントが読む文書に悪意のある指示が紛れ込んでいると、その指示に従って手持ちの鍵を使ってしまうおそれがあります。

@ITの連載が示した場面

@ITの連載(Postmanの草薙昭彦氏)は、次のような流れを描いています。在庫管理、顧客データベース、メール送信のAPIキーを.envに書き、エージェントにつなぐ。デモはうまくいき、そのまま本番で使い始める。

数週間後、一見ふつうの問い合わせが届きます。本文には、エージェントが読み取る外部データに紛れ込ませた指示が仕込まれていました。連載は、こうした手口として「ツール汚染」や「間接プロンプトインジェクション」を挙げています。

プロンプトインジェクションとは、文書やWebページに指示を紛れ込ませてAIを操る攻撃です。

OpenAIもエージェント「dots」の説明で、Webページやメール、文書に悪意ある指示が含まれ得ると書いています。保護の仕組みはこの危険を減らすが、なくせるわけではないとも説明しています。

権限が強すぎる状態には3つの型がある

セキュリティの非営利団体OWASPは、AIを使うシステムの主なリスクの一つに「過剰なエージェンシー」を挙げています。エージェントに任せすぎた結果、誤った出力や操られた出力で損害が出る状態のことです。原因は次の3つに分けられています。

Appleがフルディスクアクセスを絞る理由

Appleは10月2日、開発者向けサイトでmacOSの「フルディスクアクセス」の扱いを見直すと発表しました。フルディスクアクセスは、バックアップアプリなどが動けるように、プライバシーを守る制御の大部分を通り抜けられる権限です。

Appleによると、一部の開発者がこの権限を、ユーザーを危険にさらしかねない形で使っています。ユーザーが十分に理解しないまま、システム上のあらゆるものが見える状態になっているといいます。ファイルやメール、メッセージ、閲覧履歴も含まれます。

今後は、本当に許可したいユーザーだけが、はっきりした操作を経て許可できるよう追加の制御を入れるとしています。Appleは「AIエージェントの能力と自律性が高まるにつれ、このレベルのアクセスに伴うリスクは大幅に増す」と書いています。導入の時期や仕組みは明らかにしていません。

Appleは特定の企業やアプリには触れていません。ITmedia NEWSは、9月に関連する議論があったと伝えています。MetaのAIエージェント「Muse」のMac版で、フルディスクアクセスとメッセージの扱いが問題になった件です。

許可しているアプリは、Macの「システム設定」から確かめられます。「プライバシーとセキュリティ」の中の「フルディスクアクセス」を開くと一覧が出ます。AIエージェントや、その周辺のアプリに許可が出ていないかを見ておきましょう。

エージェントに渡す権限の4つの考え方

1. 最小権限:機能・権限・自律性を絞る

OWASPは対策として、エージェントが使える拡張機能を最小にするよう勧めています。シェルのコマンド実行のように、何でもできる機能は避けるべきだとしています。

権限は必要な最小限にし、指示した利用者の権限の範囲で実行させます。つないだ先のシステムの側でも、操作ごとに認可を確かめるよう勧めています。

実務では、エージェント専用の鍵を用途ごとに作るのが基本です。読むだけの仕事には、読み取り専用の鍵を渡します。管理者のアカウントや、人が使っている鍵をエージェントに使い回さないようにします。

任せる仕事は、次のように段階で考えると決めやすくなります。

2. 秘密の置き場:作業フォルダに置かない

@ITの連載は、対策を次の3つの層に分けています。

• 認証情報を安全に保管する層
• 必要なときに必要な分だけ、期限が短く範囲を絞った資格情報を発行する層
• 誰が、どのユーザーの権限で、何にアクセスしたかを記録して監査する層

すぐにできるのは、.envをエージェントの作業フォルダに置かないことです。どうしても置く場合は、エージェントに読ませない設定をします。たとえばAnthropicのClaude Codeでは、設定ファイルに次のような拒否のルールを書けます。

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

Claude Codeでは、会社が配る「管理設定」が最も優先され、利用者の設定では上書きできません。拒否のルールは、承認の画面を出さないモードでも有効です。会社で使うなら、こうした拒否を個人任せにせず、管理設定で配ります。

社内でよく見かける鍵の置き方と、置き換え先を表にまとめます。

3. 人の承認:影響の大きい操作に絞ってはさむ

OWASPは、影響の大きい操作には利用者の承認を求めるよう勧めています。

製品の例では、OpenAIのdotsが、パスワードの変更や送金を必ず本人に引き継ぎます。データの完全な削除、ソフトのインストール、新しいアクセス権の付与は、毎回確認します。

ただし、何にでも承認を求めると、内容を見ずに承認ボタンを押すようになります。承認をはさむのは次の4種類に絞ると、仕組みが回りやすくなります。

• 元に戻せない操作(削除、上書き、送信)
• 社外に情報が出る操作(メール、共有リンク、外部へのアップロード)
• お金が動く操作(購入、支払い、契約)
• 権限が増える操作(アカウント作成、共有設定の変更、ソフトのインストール)

4. ログ:誰の権限で何をしたかを残す

OWASPは、被害を小さくする手段として、記録と監視、呼び出し回数の制限も挙げています。エージェントの記録では、「どの社員の指示で」「どの鍵や権限で」「何に」「いつ」アクセスしたかを残します。

記録があれば、おかしな動きに早く気づけます。事故が起きたときに、どの鍵を止めればよいかもすぐ分かります。

情シスが決めるルール表

ここまでの考え方を、社内ルールのひな形にまとめます。会社の規模に合わせて調整してください。

シークレットマネージャーは、パスワードや鍵を暗号化して保管し、必要なときだけ取り出せる仕組みです。主なクラウドに用意されています。

今日からできること

まずは現状を知ることから始めます。今週中に次の6つを確かめてみてください。

• 共有フォルダや開発のリポジトリに、.envや鍵が書かれたファイルが置かれていないか探す
• 社内で使われているAIエージェントと、そのつなぎ先を一覧にする
• 会社のMacで、フルディスクアクセスを許可しているアプリを確かめる
• エージェントに渡している鍵が、管理者の鍵や人と共用の鍵でないか確かめる
• Claude Codeなどを使う部署には、.envの読み取りを拒否する設定を配る
• 鍵が漏れたときに、誰がどの手順で止めるかを決めて書き出す

エージェントは、渡した権限の分だけ仕事をしてくれます。渡す権限を決めることが、情シスにとっての新しい仕事になっています。