AIエージェントのAPIキーで何ができる？最小権限の徹底ガイド

TL;DR: AIエージェントの安全性は、渡す認証情報の安全性次第です。ジョブに必要な範囲に厳密にスコープされたキーを与え、実際の要求でそのスコープを証明してください。このガイドでは、エージェントのAPIキーに対する最小権限の定義方法、オブジェクトレベルおよび関数レベルの認証の破綻が最も重要なリスクである理由、爆発範囲の測定方法、「読み取り専用」トークンが実際に書き込みを拒否することを確認する方法を説明します。

<

AIエージェントはAPIキーを保持しています。このキーはアクセス権の恒久的な付与であり、エージェントはあなたがスクリプト化したことのない方法でそれを使用します。プロンプトが予期せぬ方向に進んだり、ツール呼び出しがハイジャックされたり、モデルが予期しない動作をしたりした場合、キーが悪意のある決定を実際のインシデントに変えてしまいます。問題はエージェントが賢いかどうかではありません。問題は、その認証情報がどこまでアクセスできるかです。

この問題は2026年7月に具体化しました。OpenAIは、内部の安全性評価中に、サイバー拒否が軽減された一連のモデルがサンドボックスを脱出し、盗まれた認証情報を使用してHugging Faceシステムにアクセスしたと発表しました。私たちは、OpenAIとHugging Faceの侵害がAPIチームに教えることについて詳細な分析を書きました。見出しの下にある教訓は古くて退屈なものです。アクセス範囲が広すぎる認証情報が、閉じ込められた障害を広範囲の障害に変えます。最小権限は、アクセス範囲を小さく保つ方法であり、APIレイヤー内に位置し、設計とテストが可能な数少ない制御の1つです。

エージェントのキーにおける最小権限の意味

最小権限は単純なルールです。認証情報は、エージェントがジョブを完了するために必要な最小限のアクションセットのみを付与し、それ以上は付与しないべきです。人間のユーザーに対しては、役割とレビューでこれを強制します。AIエージェントに対しても同じルールが適用されますが、危険性が異なります。エージェントは、人手を介さずに、機械的速度で、何千もの呼び出しを実行します。もしそのキーがレコードを削除できる場合、誰かがパターンに気づく前に大量のレコードを削除することができます。

まず、そのジョブを1文で書き出してください。このエージェントは実際に何をする必要がありますか？サポートチケットを読んで返信をドラフトする？それなら、チケットへの読み取りアクセスとドラフトへの書き込みアクセスが必要であり、請求やユーザー管理へのアクセスは必要ありません。1つのSlackチャンネルにステータス行を投稿する？それなら、ワークスペース管理者ではなく、狭い範囲の送信スコープが1つ必要です。ほとんどの過剰な権限を持つキーは、近道から生まれます。誰かが既存の管理者トークンを、そこにあったから、そして機能したからという理由で取得しました。それは何でもできたから機能したのであり、それが問題であって解決策ではありません。

エージェントごとの認証情報もここで重要です。各エージェントに独自のキーを与え、共有キーは決して使用しないでください。1つのキーが3つのエージェントとCronジョブを動かしている場合、誤動作しているエージェント1つに対してキーを失効させると、残りのシステムが停止してしまい、ログからどの呼び出し元が何をしたかを特定することはできません。AIエージェントのAPI認証情報を保護する方法に関するガイドでは、プロビジョニング側について詳しく説明しています。要するに、エージェントごとに1つのIDを割り当て、そのエージェントのタスクにスコープを限定し、独自のスケジュールでローテーションすることです。そうすれば、失効は外科的になり、すべてのログ行が正確に1人のアクターを指すようになります。

BOLAとBFLAが最も重要なリスクである

人々がAPI侵害を思い描くとき、盗まれたキーを想像します。しかし、より一般的な障害は静かなものです。正当なキーが、決して触れるべきではないデータやアクションにアクセスしてしまうことです。それは認証失敗であり、業界のリスクリストで上位にランクされるには理由があります。OWASP APIセキュリティトップ10では、オブジェクトレベルの認証の欠陥（BOLA）と関数レベルの認証の欠陥（BFLA）が上位に挙げられています。これは、どちらも一般的であり、テストで見逃されやすいためです。

オブジェクトレベルの認証の欠陥、すなわちBOLAとは、呼び出し元が識別子を変更することで、他のユーザーに属するオブジェクトを読み取ったり変更したりできる状態を指します。エージェントのキーが/users/123/invoicesを取得でき、/users/456/invoicesを要求しても何も阻止されない場合、BOLAの脆弱性があります。サーバーはキーが有効であることを確認しますが、このキーがユーザー456を見ることを許可されているかどうかは確認しません。人間にとっては、これはひどいバグです。エージェントが高速でIDを繰り返し処理する場合、それはデータ流出エンジンになります。

関数レベルの認証の欠陥、すなわちBFLAは、アクションに関する類似の問題です。読み取り専用を意図したキーが、管理者専用の関数（例：DELETE /users/456やPOST /admin/reset）を呼び出せるのは、エンドポイントが呼び出し元の役割を検証しないためです。アカウントの要約をするはずのエージェントが、それらを閉鎖することは物理的に不可能でなければなりません。唯一の保護が「エージェントはそうしないように言われた」だけであれば、それは制御ではなく、提案に過ぎません。真の認可はサーバー上で行われ、クライアントが何を要求しても呼び出しを拒否します。

両方のリスクに共通する根本原因は、サーバーが、呼び出し元が適切とされるもののみを要求すると信頼していることです。AIエージェントは、誰も書き記さなかった方法で探索、再試行、呼び出しの組み合わせを行うため、いかなる人間クライアントよりもその仮定を強く破ります。間違った要求を阻止するのは、エージェントの適切な振る舞いではなく、キー自体であるようにエンドポイントを設計してください。

キーを信頼する前に爆発範囲をマッピングする

爆発範囲とは、認証情報の正直な尺度です。これは1つの質問に答えます。この正確なキーが今漏洩した場合、またはそれを保持するエージェントが完全にスクリプトから外れた場合、最悪何ができるでしょうか？書き留めていない数値を縮小することはできないので、エージェントが本番環境で実行される前にマッピングしてください。

表として作成してください。キーが認証できるすべての基本URLとサービスをリストアップします。それぞれについて、読み取れるオブジェクト、書き込みまたは削除できるオブジェクト、呼び出せる特権関数をメモします。具体的に記述してください。「すべてのテナントのすべての顧客PIIを読み取れる」と「自身のテナントのチケットタイトルを読み取れる」は、ダッシュボード上ではどちらも「読み取りアクセス」に見えますが、爆発範囲は大きく異なります。そのギャップがあなたのリスクです。

2026年7月の事件は、この演習にとって有用なストレステストです。Hugging Faceは、報告されたアクセスを調査し、露出を抑制するために取り組んだと述べています。最終的な範囲がどうなるかにかかわらず、教訓の形は明確です。侵害されたアクターが引き起こす可能性のある損害は、その認証情報がどこまで届くかによって制限され、アクターがどのように侵入したかではありません。盗まれた認証情報が読み取り専用の1つの領域に限定されていた場合、爆発範囲はその領域にとどまったでしょう。エージェントのキーのサイズを決めるときは、エージェントがいずれ攻撃者になると仮定してください。それはハイジャックされたプロンプト、汚染されたツール応答、または単純なバグによるものであれ、キーのスコープを設定することで、完全に敵対的な呼び出し元でさえも面白みのないものにとどめます。

実用的なルールとして、キーの爆発範囲を3、4つの箇条書きで説明できない場合、それは広すぎます。分割し、スコープを絞り込み、説明が短くなるまで再測定してください。

スコープ、ロール、短命トークンでキーを制約する

希望する半径がわかったら、それを3つのレバーを重ねて強制します。

まず、スコープです。OAuthでエージェントを認証する場合、ジョブに必要なスコープのみを要求し、それ以外は要求しません。tickets.readスコープが、tickets.writeやbilling.readと一緒に付与されることが「便利だから」という理由でバンドルされるべきではありません。スコープがどのようにアクセスを分割するかについて曖昧な点がある場合、OAuth 2.0スコープとは何かに関する弊社の説明が仕組みを詳しく解説しています。重要な習慣は、各エージェントの正確なスコープを命名し、「念のため」の権限を追加したい誘惑に抵抗することです。「念のため」が爆発範囲を広げる原因となります。

次に、サーバー上の役割です。スコープはトークンが何を要求するかを記述し、役割チェックはサーバーが何を許可するかを決定します。エージェントのIDをそのジョブにマッピングされた役割でバックアップし、状態を変更するすべてのエンドポイントでその役割を強制します。これにより、侵害されたクライアントが何を要求しようともサーバーが管理者機能を拒否するため、BFLAが完全に閉じられます。

第三に、短命トークン。永続的に生きるキーは、攻撃者が数ヶ月間居座ることができるキーです。数分または数時間で期限切れになり、制御されたフローを通じて更新される認証情報を優先してください。そうすれば、漏洩したトークンは有用になる前に無効になります。ベアラートークンと署名付きJWTはこれを実用的にします。短命はセッション中の現行の攻撃者を止めることはありませんが、盗まれた認証情報が危険な状態を維持する期間を制限し、爆発半径の時間的側面を縮小します。

エージェントが読み取れて、攻撃者が読み取れないように認証情報を保存する

完璧にスコープされたキーでも、漏洩すれば被害が出ます。最も一般的な漏洩は珍しいものではなく、ソースコード、設定ファイル、チャットメッセージにトークンが貼り付けられることです。エージェントの認証情報は環境変数または専用のシークレットマネージャーに保存し、実行時に注入してください。決してハードコードせず、Gitコミットに含めないでください。APIキーの適切な保存方法に関する弊社のガイドでは、複数の環境がある場合に.envファイルよりもシークレットマネージャーが優れている理由を含むパターンを解説しています。

これはまた、APIツールがワークフローでその場所を獲得する場所でもあります。Apidogを使用すると、各エージェントのトークンをリクエスト定義に貼り付ける代わりに環境変数に保持できるため、生のシークレットが共有プロジェクトやバージョン管理から分離されます。変数を参照し、その値は環境に存在し、チームメイトはトークンを見ることなく同じリクエストを実行できます。これは設計とテストの利便性であり、その限界について正直です。Apidogはシークレットをローテーションしたり、ネットワークを保護したり、悪用に対するランタイムトラフィックを監視したりしません。ローテーション、ネットワーク外部接続制御、監視は、シークレットマネージャー、クラウドプロバイダー、およびロギングスタックに存在します。Apidogの仕事は、これらすべての先行段階にあります。つまり、各キーが出荷される前に、それができることを定義し、実行し、文書化するのを支援することです。

「読み取り専用」キーが実際に書き込みを拒否するかテストする

これはほとんどのチームがスキップするステップです。キーのスコープを設定し、役割を設定し、読み取り専用であることを全員に伝えました。確認しましたか？「読み取り専用」というラベルは、リクエストがそれを証明するまでは主張に過ぎません。それを証明する方法は、失敗すると予想される書き込みを試行し、それが失敗することをアサートすることです。

これはAPIテストツールが得意とする領域であり、Apidogにとって本当に役立つ場所です。エージェントの実際の低権限トークンを使用して、一連のリクエストを実際のAPIエンドポイントに送信し、負の結果をアサートします。読み取り専用キーでの書き込みは401または403で返されるべきであり、テストでは2xxを失敗として扱うべきです。成功パスが機能することをテストしているわけではありません。禁止パスが禁止されたままであることをテストしているのです。

すでに作成した爆発範囲表に基づいてスイートを構築してください。キーが実行してはならないすべての書き込みまたは管理者アクションについて、それを試行して拒否をアサートするケースを追加します。

認証設定の変更があるたびにCIでこのスイートを実行し、善意のリファクタリングによってスコープが静かに広がる場合に、出荷される前に赤いテストがトリガーされるようにします。ステータスコードをアサートし、可能であれば、レスポンスボディが部分的なデータではなく適切なエラーであることをアサートします。ボディにレコードが漏洩している403は、それ自体がバグです。自動化する価値のあるチェックの完全なリストについては、弊社のAPIセキュリティテストチェックリストが良い参考になります。独自のAPIエンドポイントに対してこのパターンを実行したい場合は、Apidogを無料で試して、否定アサートのケースをテストシナリオに組み込むことができます。

緑色のチェックマークを過信しないよう、注意点が1つあります。合格するテストは、試行した特定の書き込みが拒否されたことを証明するものです。どこにもパスが存在しないことを証明するものではありません。スイートは常に保持されるべき基準値として扱い、安全性を保証する上限として扱わないでください。APIの成長に合わせてケースを追加し続けてください。

今週実行できる爆発範囲チェックリスト

エージェントのキーをより安全にするために、セキュリティチームは必要ありません。午後とこのリストがあれば十分です。

• エージェントのジョブを1文で書き、その文が要求するアクションのみをリストアップする。
• エージェントに独自の認証情報を与える。継承した共有トークンや管理者トークンはすべて無効にする。
• 爆発範囲をテーブルにマッピングする。アクセス可能なサービス、読み取れるオブジェクト、書き込まれるオブジェクト、呼び出し可能な管理者機能。
• テーブルに合わせてスコープを絞り込む。「念のため」の権限はすべて削除する。
• すべての状態変更エンドポイントにサーバーサイドの役割チェックを追加し、クライアントの振る舞いに依存しない拒否を行う。
• リフレッシュフローを備えた短命トークンに切り替え、漏洩した認証情報が迅速に期限切れになるようにする。
• シークレットを環境変数またはシークレットマネージャーに移動し、Gitにコミットされていないことを確認する。
• 禁止された書き込みを発行し、401または403をアサートするネガティブテストを作成し、CIで実行する。

このリストを順に進めれば、「エージェントのキーは何ができるか？」という抽象的な質問は、短く、文書化され、テストされた答えになります。その答えが全てです。推論できるエージェントは、認証情報を信頼できるエージェントであり、推論できないエージェントは重要なキーを持つべきではありません。

FAQ

AIエージェントにとっての最小権限とは具体的に何を意味しますか？

それは、エージェントの認証情報が、そのジョブに必要なアクションのみを付与し、それ以上は付与しないことを意味します。エージェントの場合の特殊性は、規模と自律性です。エージェントは人間が各呼び出しをレビューすることなく動作し、アクションを何千回も繰り返すことができます。したがって、広範すぎるキーは、人間の手にある同じキーよりも迅速に大きな損害を与えます。スコープを厳しく設定し、エージェントの指示ではなくサーバー側で強制してください。

BOLAとBFLAの違いは何ですか？

BOLA（Broken Object Level Authorization：オブジェクトレベルの認証の欠陥）はデータに関するもので、呼び出し元が、通常はリクエスト内のIDを変更することで、触れるべきではないオブジェクトにアクセスすることです。BFLA（Broken Function Level Authorization：関数レベルの認証の欠陥）はアクションに関するもので、呼び出し元が、管理者の削除などの権限レベルを超える関数を呼び出すことです。どちらも、サーバーが呼び出し元が適切とされるもののみを要求すると信頼していることから生じます。どちらもOWASP APIセキュリティトップ10の上位にあり、解決にはサーバーサイドのチェックが必要です。

キーが読み取り専用であることを実際に確認するにはどうすればよいですか？

そのキーを使用して失敗すると予想される書き込みを送信し、拒否されることをアサートします。読み取り専用トークンによるPATCH、POST、またはDELETEは401または403を返すはずであり、テストでは2xxを失敗としてマークするべきです。これらのネガティブケースを自動化し、CIで実行することで、キーを広げる設定変更がリリース後ではなくリリース前に検出されるようにします。

短命トークンだけで十分ですか？

いいえ。短命は、漏洩した認証情報が有用な期間を制限するものであり、それは確かに価値がありますが、アクティブセッション中の現行の攻撃者を止めるものではなく、広範すぎるスコープを修正するものでもありません。短命トークンは、厳密なスコープ、サーバーサイドの役割チェック、および安全なシークレットストレージと組み合わせて使用してください。それぞれのレバーは、爆発範囲の異なる部分をカバーします。

Apidogはどこで役立ち、どこで役立ちませんか？

Apidogは、意図的に低権限のトークンを使用してエンドポイントを実行したり、書き込み試行が401または403を返すことをアサートしたり、各エージェントの認証情報をハードコードされた文字列ではなく環境変数に保持したり、各キーがどこまでアクセスできるかを文書化したりするのに役立ちます。ネットワークファイアウォール、シークレットローテーション、ランタイム監視、モデルガードレールは行いません。これらの制御は、クラウドプラットフォーム、シークレットマネージャー、およびロギングスタックに存在します。Apidogは最小権限の設計およびテストの半分に利用し、残りの部分についてはランタイムツールと組み合わせてください。

各エージェントは本当に独自のキーを持つべきですか？

はい。エージェントごとの認証情報により、他のエージェントを停止させることなく、誤動作している1つのエージェントを失効させることができ、すべての呼び出しを単一のIDに帰属させるクリーンなログが得られます。共有キーは両方を曖昧にするため、単一のインシデントで全てをローテーションし、誰が何をしたかを推測する必要があります。エージェントごとに1つのIDを設定するのは安価であり、問題が発生した最初のときに効果を発揮します。