- 公開日
AIが外部システムへ操作を頼むときは、「ログインできた」だけで実行を許可しません。誰が依頼し、誰として実行し、どの組織のどの情報を、何の操作に使えるかを確認します。代理で行うなら、委任された範囲と期限も必要です。この組合せを実行先で検査することが、利用者の頼んでいない操作や別組織の情報へのアクセスを抑える基本になります。
この記事は、認証・認可・委任の基本を扱います。共有チャットの例で、AIが誰として外部システムへアクセスするかを決める応用は「AIが「誰として」外部システムへアクセスするかを固定する」で解説しています。
認証、認可、委任は別の問いに答える
主体とは、アクセスする人やプログラムなど、権限判断の対象となる存在です。AIを使った処理には、依頼した利用者、AIアプリケーション、外部システムへ接続するアカウントなど、複数の主体が関わります。すべてを一つの「AIユーザー」として扱うと、誰の権限を使ったかが分からなくなります。
| 確認 | 答える問い | 代理申請での例 |
|---|---|---|
| 認証 | 接続してきた主体を、どの識別情報として確かめたか | 利用者のアカウントやAgentの接続主体を確認する |
| 認可 | その主体が、対象へ、その操作をしてよいか | 自分の申請の状態を閲覧できるかを判定する |
| 委任 | 誰が、どの範囲の権限を、誰へ託したか | 利用者がAgentへ申請状況の照会だけを任せる |
| 個別操作の承認 | 今回提示された内容で、その操作を進めてよいか | 確認した変更内容を申請先へ送ってよいかを決める |
認証に成功していても、その申請を閲覧する権限がなければ認可は通りません。閲覧する権限があっても、更新まで委任されたとは限りません。また、更新を行えるアカウントであっても、利用者が今回の内容の送信を承認したとは限りません。
この区別は、AIが自然な文章で依頼を理解することとは別の問題です。「私は管理者です」「この更新は承認済みです」という文章だけから、システム側の権限や承認状態を作らないようにします。根拠にするのは、信頼できる認証結果、権限情報、委任・承認の記録です。
依頼者と実行主体を、一組で残す
利用者の権限で外部システムへ接続する方式では、本人に許された範囲を引き継ぐ設計が考えられます。一方、アプリケーション用のサービスアカウントで接続する方式では、そのアカウントが持つ権限が利用者より広い場合があります。後者で接続できたからといって、要求した利用者へすべての結果を返してよいとは限りません。
代理操作では、依頼者の識別情報と、実際に接続した主体を区別して記録します。加えて、対象組織、対象データ、操作、委任の識別情報、期限、判断結果が分かるようにします。資格情報やアクセストークンそのものを、確認用のログへ貼る必要はありません。
委任の実装を考えるときには、代理の主体を保持する方式と、本人として扱う方式の違いも重要です。OAuth 2.0 Token ExchangeのRFC 8693は、delegationとimpersonationを区別しています。どちらを使うかを曖昧にしたまま「ユーザーとして実行」と記録すると、利用者の直接操作とAgentによる操作を後で見分けにくくなります。
架空の代理申請で、範囲と期限を確かめる
架空の社内申請サービスを考えます。利用者Aは、組織Tの自分の申請について、Agentに状態の照会だけを委任しました。委任は当日の17時に失効し、更新は認めていないとします。時刻は説明用の条件であり、特定製品の既定値ではありません。
このとき、次の記録を一組にします。
- 依頼者：組織Tの利用者A
- 実行主体：当該委任で接続するAgent
- 対象：組織TにあるAの申請
- 操作範囲：状態の照会
- 有効期限：当日17時まで。時刻基準はシステムで統一
- 取消：利用者または権限を持つ管理者による取消を反映
16時に状態を尋ねた場合は、認証に加え、対象、操作、現在の権限、委任期限と取消状態を確認してから照会します。期待する回答は、その申請の状態と確認時点です。別人の申請を混ぜたり、古い状態を現在のものとして返したりしないことも確認します。
同じAgentが16時に「申請金額を変更する」と要求しても、更新は委任されていないため拒否します。17時以後の照会は、期限切れとして拒否します。17時以後の更新要求は範囲と期限の両方に合いません。このように条件を分けて見ると、「期限内なら何でもできる」という誤解を避けられます。
| 要求 | 判断が変わる条件 | 期待する処理 |
|---|---|---|
| 16時にAの申請状態を照会 | 範囲内・期限内で、現在の権限と取消状態も有効 | 認可後に照会する |
| 16時にAの申請を更新 | 操作が委任範囲外 | 更新を行わず、必要な委任を案内する |
| 17時以後に同じ申請を照会 | 委任が期限切れ | 古い会話の依頼を根拠に再開せず、再委任を求める |
| 別組織Uの申請を照会 | 対象の組織が異なる | データを返さず拒否する |
| 取消状況を確認できない | 実行条件が未確認 | この構成では照会を保留し、認可状態の確認へ戻す |
これは未実行の設計例です。認証に成功した状態を固定したまま、操作範囲、期限、対象組織を変え、受信側がそれぞれ拒否できるかを試験するための材料になります。
テナント境界は、入力文ではなく実行経路で守る
テナントとは、一つのサービス内で分けて管理する組織や顧客の単位です。組織Tの利用者が、依頼文やツール引数に組織Uの識別子を書いても、それによってUの権限を得られない構成にします。
OWASPのマルチテナントセキュリティの指針は、信頼できる主体とテナントの対応、データアクセス、キャッシュやセッションの分離などを扱っています。AI連携でも、認証された主体と現在の所属・権限に対象組織を結び付け、検索や更新の実行先まで引き継ぐ考え方が使えます。
テナントの識別子は、どの組織を選ぶかを示す情報であり、それ自体がアクセス許可ではありません。ツールが利用者から渡された識別子をそのまま検索条件にするのではなく、その利用者が対象組織で当該操作を行えることを確認します。
キャッシュにも注意が必要です。前の利用者や別組織の照会結果を、同じ質問だからと再利用すれば、外部システムの認可を通らず情報を返すことになります。組織別のキーで分けるだけでなく、キャッシュを読む時点の閲覧権限や委任の有効性を確認します。認可を守る範囲は、最初のAPI呼出しだけではありません。
判断する場所と、操作を止める場所をつなぐ
AIが「権限不足なので中止します」と文章で答えても、裏でツールが動いていれば制御としては失敗です。認可の判断を、実際の接続やデータ操作を許可・拒否する仕組みにつなげます。NIST SP 800-207は、ポリシーの判断と強制を担う論理的な構成を説明しています。これを設計の参考にし、LLMの説明文とは別に、実行経路で条件を検査します。
申請の案内文をローカルに作るだけなら、外部システムへの更新権限をAgentへ持たせずに済みます。照会を加えると、依頼者と対象の閲覧権限が必要になり、更新まで行うと、委任範囲に加えて変更内容の確認や操作承認を扱う必要が出てきます。作業の影響に合わせて条件は増やせますが、どの段階でも主体や情報の境界を省く理由にはなりません。
運用では、利用者の権限変更、委任の取消、期限切れ、対象組織の変更があったときに、進行中の処理や保存された結果をどう扱うかを定めます。認可状態が分からないときに、接続用アカウントの広い権限で処理を続ける回避策は採りません。できない操作と、認められた材料だけで続けられる説明・下書きを分けて返します。
最初の設計確認では、「誰が依頼したか」「誰として動くか」「どの対象へ何をするか」「いつまで、どの条件で任されているか」を一つの要求で追ってみます。その要求が実行先まで届いたときにも条件が保たれているかを確かめると、認証だけでは見えなかった権限の抜けを見つけやすくなります。
エージェントへの権限委任と、取消・失効の設計は「Agentへ権限を委任するときの範囲・期限・取消の設計」で解説しています。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
