はじめに
こんにちは。GMO Flatt Security株式会社 ソフトウェアエンジニアの梅内(@Sz4rny)です。
一つ前の記事である「MCPにおけるセキュリティ考慮事項と実装における観点（前編）」では、MCP Server / Client のリスクについて紹介しました。本記事では、すこし観点を変えて「AI と認可制御」について検討します。
LLM を組み込んだサービスを実装している人も、LLM が組み込まれた開発支援ツールを使っている人も、おそらく一度は「AI にどの程度権限を与えてよいのか」という疑問に頭を悩ませたことがあるのではないでしょうか。本記事では、このテーマについて深堀りします。
また、GMO Flatt Securityは日本初のセキュリティ診断AIエージェント「Takumi」や、LLMを活用したアプリケーションに対する脆弱性診断・ペネトレーションテストを提供しています。ご興味のある方はリンクよりサービス詳細をご覧ください。
背景となる課題意識
近年、大規模言語モデル (LLM: Large Language Model) を取り巻く様相の進化は目覚ましく、初期の LLM は人間と自然な会話をするだけでしたが、今や LLM は自ら考えて行動する AI エージェントへと進化しており、ソフトウェアエンジニアリングのあり方そのものを根本から変えようとしています。技術の進歩により、「AI とともにプロダクトをつくる体験」および「プロダクトを AI の力でより価値のあるものにする体験」の双方が日進月歩で進化していると言えるでしょう。これを読んでいる方も、少なからず開発中に LLM を用いてコード補完を行っていたり、AI エージェントに雑多なタスクを依頼したりしたことがあると思います。
一方で、LLM や AI エージェントが持つ推論能力や自律性は、新たなセキュリティ上の懸念をもたらしていると言えます。
たとえば、ユーザーからの質問に回答するため、あるシステムが管理しているデータベースを自由に閲覧することができる AI エージェントを開発したとしましょう。ここで、悪意のあるユーザーであるXさんは、他人であるYさんの個人情報を表示するようなタスクをエージェントに依頼するかもしれません。もし、AI への指示 (プロンプト) の内容を確認する機能や、リクエスト元ユーザー以外の個人情報を取り除くようなフィルター等が適切に実装されていない場合、エージェントが悪用されて個人情報が漏洩してしまう危険性があります。
本記事では、上記の例で挙げたような「AI と認可制御」に焦点を当て、認可制御の基礎から、AI に関連する技術を活用する際に注意すべき観点について詳しく説明します。本記事を読んでいただくことで、以下の2点について深い理解が得られるものと思います。
- 「AI でつくる人」が注意すべき認可制御上の観点について
- 開発フローに LLM や AI エージェントを活用している場合、どのような認可制御上の問題が発生しうるか。また、それにどのように対処すべきか。
- 「AI をつくる人」が注意すべき認可制御上の観点について
- プロダクトに LLM や AI エージェントを組み込んだ機能を提供している場合、どのような認可制御上の問題が発生しうるか。また、それにどのように対処すべきか。
なお、以下では特に断りのない限り、「AI」と表記されたものは LLM をベースとした AI エージェントを指すものとします。
免責事項
本稿の内容はセキュリティに関する知見を広く共有する目的で執筆されており、脆弱性の悪用などの攻撃行為を推奨するものではありません。許可なくプロダクトに攻撃を加えると犯罪になる可能性があります。当社が記載する情報を参照・模倣して行われた行為に関して当社は一切責任を負いません。
認可制御に関する前提知識
認可制御とは？
まずは、認可制御の基礎について振り返ることとします。なお、すでに認可制御については知っている、という方はこのセクションを飛ばして「AI と認可制御」のセクションに進んでください。
認可制御とは、主にシステムにおいて「誰が」「何に (どのようなデータや機能に) 対して」「何を (どんな操作を) してよいか」を制御するための仕組みです。認可制御が適切に実装されていれば、正当な権限を持った主体のみが、事前に許可された機能やデータにアクセスできることを保証できます。
たとえば、様々な人のプロフィールを閲覧できる SNS アプリケーションがあるとします。また、このアプリケーションは以下に示す2つの API を実装しているとします。
GET /profile/{userId}userIdに対応するユーザーのプロフィールを表示する
POST /profile/{userId}userIdに対応するユーザーのプロフィールを更新する
ここで、前者の API はどのような主体であってもアクセスが許可されるべきでしょう。一方、後者の API については、リクエスト元ユーザーのユーザー IDと {userId} の箇所に指定された値が一致している場合に限ってアクセスを許可するべきです。そうしないと、誰でも他人のプロフィールを更新できてしまうことになるでしょう。
これは非常に単純な例ですが、現実には「管理者権限のユーザーは誰のプロフィールでも更新できる」といったような、アプリケーションの要件に基づいた複雑な認可制御が行われる場合が大半です。
ところで、認可と混同されやすい概念として認証 (Authentication) がありますが、こちらはリクエスト元の主体が誰であるかを確認、検証するプロセスを指します。認可制御は、ほとんどの場合において認証が完了した主体が持つ役割や属性、システムの状況等に基づいて実施されます。
認可制御のバリエーションと重要な原則
認可制御にはいくつか代表的なバリエーションがあります。
おそらくもっとも有名で広く利用されているのが RBAC (Role-Based Access Control) でしょう。RBAC では、特定の権限をロールにまとめ、そのロールをアプリケーションにアクセスする主体に付与します。例として、データの参照のみが想定されているユーザーには「閲覧者」ロールを付与し、データの操作を行うユーザーには「管理者」ロールを付与する、といったケースが挙げられます。
次に利用されているのが ABAC (Attribute-Based Access Control) です。ABAC は、リクエスト元の主体やリクエスト先のリソース、および関連するコンテキストの属性 (Attribute) に基づいて認可の判断を行う方式です。
例として、飲み物の情報を表示するアプリケーションを考えてみましょう。このアプリケーションでは、20歳未満のユーザーには酒類に関連する情報を表示してはいけないものとします。このとき、ABAC に基づいて認可制御を行うロジックは以下のようになります。
- 参照しようとしているリソース (飲み物) が酒類ではなければ許可
- 参照しようとしている主体が20歳以上のユーザーなら許可
- それ以外は拒否
この例では、リクエスト元の主体とリクエスト先のリソースの属性しか参照していませんが、もしこのアプリケーションを海外に展開するとなった場合、その国の法律に沿った年齢制限の機構を導入する必要があります。この場合、ユーザーの所在国での年齢制限というコンテキストの属性も参照する必要があるでしょう。
これらに加えて、ReBAC (Relationship-Based Access Control) という方式も存在します。ReBAC では、主体とリソース間、あるいは、リソースとリソース間等の関係性に基づいてアクセス制御を行います。ReBAC は、図でイメージすると分かりやすいかもしれません。ユーザーやデータなどを「点（ノード）」、それらの関係性を「線（エッジ）」で結んだ図（有向グラフ）を考えます。このとき、「特定の点と点の間に、ある種類の線が存在するか？」を調べることで、アクセスを許可するかどうかを判断するのが ReBAC の考え方です。 関係性の例としては、以下のようなものが挙げられます。
- 所有権の関係性: あるユーザーが作成したリソースは、そのユーザーのみが編集できる。
- 所属の関係性: あるユーザーが作成したリソースは、そのユーザーが所属するグループのメンバーなら参照できる。
- 階層上の関係性: あるユーザーが作成したリソースは、そのユーザーの部下なら参照のみ可能だが、上司なら編集もできる。
さて、どの方式を採用するにせよ、必ず遵守すべきプラクティスがあります。それが「最小権限の原則 (PoLP: Principle of Least Privilege)」です。最小権限の原則は、簡単に言うと「各主体に対して、アプリケーションを利用する上で必要となる最低限の権限のみを与えるべきである」という考え方です。
たとえば、テストの成績を管理するアプリケーションを考えてみましょう。このとき、学生ロールのユーザーには自分の成績を参照する権限を、教師ロールのユーザーには管轄の学生の成績を参照・編集する権限を付与すべきです。しかし、もちろん学生ロールのユーザーに自分の成績を編集する権限を与えるべきではありません。
このような直感的に発見できるミスは起こりにくく思えますが、実際の開発の現場においては度重なる仕様変更や複雑な仕様の確認漏れによって、本来付与すべきではない権限が付与されているケースがしばしば見られます。
認可制御不備の実態とリスク
以前Shisho Cloud byGMOの認可制御診断機能を解説した記事でも触れた通り、グローバルな調査リポート OWASP Top 10 2021 において「認可制御不備」は第1位に挙げられ、大規模なインシデントを引き起こすリスクが極めて高いと位置づけられています。
加えて、GMO Flatt Security が提供している手動脆弱性診断においても、発見された脆弱性のうち、リスクの高さにおいて特に重大だったものの多くが認可制御不備に起因するものでした。
では、認可制御の実装にミスがあったり、前提となる仕様に不適切な定義が含まれていたりした場合、どのようなリスクが顕在化するおそれがあるのでしょうか。大雑把に述べると、そのようなリスクは以下の3つに大別されます。
- 意図しないデータの参照
- 本来は閲覧権限を持たないはずの主体によって、不正にデータを閲覧されるおそれがあります。
- 特に、アクセス先のデータが機密情報や個人情報であった場合、重大な情報漏洩やプライバシーの侵害に派生するおそれがあります。
- 意図しないデータの更新・削除
- 本来は編集権限を持たないはずの主体によって、不正にデータを更新・削除されるおそれがあります。
- これにより、悪意を持ったユーザーによって他ユーザーの情報が勝手に変更されたり、取引履歴やセキュリティ関連のログといった重要なデータが削除されたりするおそれがあります。
- 意図しない機能の実行
- 本来は実行権限を持たないはずの主体によって、特定の機能や API が呼び出し可能になるおそれがあります。
- たとえば、一般権限のユーザーが管理者相当の機能を実行することができてしまったり、無料ユーザーが有料ユーザー限定の機能にアクセスできてしまったりなど、技術的にも事業的にも重大なリスクに派生するおそれがあります。
AI と認可制御
AI と認可制御にまつわる課題
では、いよいよ本題に入りましょう。LLM や AI エージェントの台頭によって、従来の認可制御の仕組みにどのような課題が生じるのでしょうか。
なお、これ以降の内容において認可制御を考えるとき、それは以下の図に示すように、AI エージェントが特定のデータソースや機能 (ファイルサーバ、データベース、サードパーティの API など) を使おうとする際に「AI エージェントがそれにアクセスしてもよいのか」を判断するプロセスを指すものとします。
これまでの認可制御の多くは、人間がアプリケーションを使う場合のシナリオや操作方法を前提に作られています。そのため、AI エージェントを通じてアプリケーションが使われるようになると、次のような問題が顕在化するおそれがあります。
- 自律性の高い AI による予測が困難な振る舞い
- AI は、ある程度アプリケーションを利用する際のフローが明確である人間と異なり、与えられたプロンプト等に応じて多様な振る舞いを示すことがあります。
- そのため、具体的にどのような権限 (あるいはロール、関係性等) を付与するかの判断が困難になる場合があります。
- AI エージェントを介することによる攻撃可能範囲の拡大
- AI エージェントは、たとえば RAG（Retrieval Augmented Generation; AI が外部情報を参照して回答を生成する技術）を実現するために、利用者が直接アクセスすることのできない社内システムやデータベースなどにアクセスするための権限を持っていることがあります。
- このとき、エージェントの振る舞いをうまく悪用するようなプロンプトが与えられると、本来のリクエスト元ユーザーの権限では実現できないようなデータや機能へのアクセスが行われるおそれがあります。
- 文脈に合わせた動的な権限の割り当て
- AI エージェントの権限は静的なものではなく、エージェント自身が有する権限 (例: 特定のデータソースにアクセスする権限) と、特定のタスクの実行を依頼したユーザーの権限を動的にマージして決定する必要があります。
- このように状況に応じて権限を組み合わせる方法に不備があると、本来その指示を出したユーザーの権限ではできないはずの操作が実行されてしまったり、逆に、許可されるべき操作がブロックされてしまったりするおそれがあります。
これらの事項は、OWASP Top 10 for LLM Applications 2025 において「LLM06:2025 Excessive Agency」としてランクインしています。当該ドキュメントにおける Agency とは、特定のタスクを実行するために AI エージェントに与えられた権限や能力のことを指します。たとえば、システム外のサービスと連携するためのプラグイン機能や、特定のデータにアクセスするための関数呼び出し機能などがこれに当たります。このような Agency が過剰に付与されている場合に、AI エージェントがユーザーやシステムに対して損害を与えるようなアクションを実行する可能性がある、というのが LLM06:2025 の趣旨です。
さらに、当該ドキュメントでは、LLM06:2025 の原因として以下の3点がピックアップされています。
- 過剰な機能性 (Excessive functionality)
- エージェントが、システムが意図した操作に不要な機能にアクセスできる場合を指します。
- 過剰な権限 (Excessive permission)
- エージェントに対して、必要最小限以上の権限が付与されている場合を指します。
- 「どのようなアクションが可能か」といった行為の種別だけでなく、「どのようなリソースに対して」という対象のスコープの広さについても、この項目に含まれます。
- 過剰な自律性 (Excessive autonomy)
- エージェントが、システムやユーザーに大きな影響を及ぼすアクションを、特定の人間による確認や承認なしに実行する (できる) 場合を指します。
ケーススタディ: 社内向けのレポート作成 AI エージェント
では、具体的な架空の事例を通して、AI と認可制御にまつわる困難さについて考えていきましょう。
ここでは「社内向けのレポート作成 AI エージェント」を組み込んだアプリケーションを題材とします。このアプリケーションは、社内のメンバーが自然言語でエージェントに指示をすると、社内のファイルサーバやデータベース上にあるデータやドキュメント等を検索、参照し、適宜わかりやすく要約したうえでユーザーに表示する、という機能を持つものとします。
さて、このエージェントにはどのような権限を付与すべきでしょうか。その権限はリクエスト元ユーザーごとに変化させるべきでしょうか。その場合、どのように最終的な権限を決定すべきでしょうか。また、エージェントに与えるツールにはどのような機能を持たせるべきでしょうか。
過剰な権限の付与
まず、エージェントそのものに与える権限について考えてみましょう。ユースケースを考慮すると、エージェントはあくまで各種データソースにアクセスし、それらの情報をまとめるだけの主体であると考えられます。そのため、参照系の権限は付与する必要がありそうですが、更新や削除等の権限は付与しなくても良さそうです。
もし、このエージェントに更新や削除等の権限を付与してしまうと、意図せずファイルサーバ上のドキュメントが更新されてしまったり、データベース上の特定のレコードが更新されてしまったりといった、重大度の高いリスクに繋がる可能性があります。
また、前述の通り権限の種別だけでなく、権限のスコープについても注意が必要です。たとえば、このエージェントの目的が「会社の会計資料に関するレポートを提供する」ことに限定されているとします。この場合、このエージェントは各データソースに蓄積された会計に関するデータにアクセスできるべきですが、それとは関係のないデータ (社員の個人情報等) にはアクセスできるべきではありません。
このように、権限のスコープに不備があっても、やはり想定外のデータの参照や操作が実行されるリスクが存在します。
過剰な機能の付与
先ほどの例では、エージェントに不要な権限が付与されていたことを問題として取り上げましたが、そもそもエージェントに与えられたツールにそのような機能性があることも問題です。たとえエージェントがそのような権限を持っていたとしても、ツールに最小限の機能しか与えられていなければ、エージェントはその範囲を逸脱したアクションを実行することはできません。
このように、エージェントに与えるツールからは、不要な機能を排除することが重要ですし、そもそもツール自体を過剰に与えないことも重要です。突飛な例になりますが、このエージェントに会社の銀行口座からの送金を可能にするツールを与える必要はないですよね。そのようなケースはないにしても、現実には元々使われていたがある時点から使われなくなったツールが残存していたり、テスト用に付与したツールが本番環境でも有効になっていたりといったケースは散見されるため、あり得ない話ではありません。
動的な権限の付与
ここまではリクエスト元ユーザーの属性や権限を無視した議論を行ってきましたが、実際のアプリケーションにおいては、そのような情報に基づいた認可制御が行われていることがほとんどです。たとえば:
- ユーザーごとの制御: AさんにはAさん自身の個人情報は表示してもよいが、他の社員の個人情報を表示してはいけない。
- ロールベースの制御: 人事管理者には人事に関するデータを表示してもよいが、その他の社員には表示してはいけない。
- 属性ベースの制御: 人事部所属のマネージャー以上の役職のユーザーには人事に関するデータを表示してもよいが、その他の社員には表示してはいけない。
AI エージェントを活用するようなアプリケーションにおいても、このようなリクエスト元ユーザーの属性や権限に基づいた認可制御を適切に実施する必要があります。言い換えると、いわゆる AWS の IAM における AssumeRole のように、リクエスト元ユーザーに応じてエージェントがかぶる帽子を切り替える必要があるのです。
このような動的な権限の付与は、エージェント自身が持つ権限をあわせて考慮する必要があるとき、より複雑になります。以下のベン図を見てください。
このベン図は、4つの領域に分けることができます。すなわち:
- P1: リクエスト元ユーザーとエージェントの双方が持っていない権限
- P2: リクエスト元ユーザーのみが持っている権限
- P3: エージェントのみが持っている権限
- P4: リクエスト元ユーザーとエージェントの双方が持っている権限
このうち、P1 および P4 の認可制御については、特に悩む必要はないでしょう。それぞれ、そのまま拒否・許可すればよいだけです。
P2 の領域が存在する場合、これはセキュリティ上の欠陥というより、むしろ使い勝手 (すなわち、ユーザーエクスペリエンス上の) の問題と言えるでしょう。なぜなら、この領域は「自分自身で操作すればできることなのに、AI エージェントに頼むと『権限がありません』と断られてしまう (でも、自分でやるのは手間がかかる…)」という、ユーザーにとって不便な状況を生み出すからです。この問題を解決するためには、前述の通りエージェントがリクエスト元ユーザーが持つ権限を適宜引き受けるような設計にすればよいでしょう。
もっとも扱いが難しいのは P3 です。たとえば、エージェントはタスク遂行のために社内のデータベースにアクセスする権限を有する一方で、一般の従業員にはそのような権限が与えられていない、というありがちなケースについて考えてみましょう。
ここで、認可制御を緩く実施する方向に倒すと、ユーザーのタスクが想定通りに遂行されやすくなる一方で、本来は当該ユーザーが知り得なかった情報を、エージェントを介して取得されるおそれがあります。たとえフィルタリング等の機構を利用して、エージェントが返す出力内容から機微な情報等を除去できていたとしても、ユーザーは複数回クエリを実行した結果を集約したり、出力内容をフィルタリングされないフォーマットに変換するようなプロンプトインジェクション上のテクニックを使ったりすることで、ある程度この制限を回避することが可能であるため、根本的な解決策とはなり得ません。
一方で、認可制御を厳格に実施する方向に倒すと、やはりユーザーエクスペリエンス上の課題が露呈することとなります。「ユーザーやエージェントにどこまで見せていいか、どこまで実行させていいか」と「どのくらい認可制御を厳格に実施するか」は常にトレードオフの関係にあり、実際の開発においては、高い粒度のもとで動的かつ柔軟な認可制御を実現することが望ましいと言えます。
「AI と認可制御」のまとめ
本セクションでは、AI と認可制御において主にどのような課題があるのか紹介しました。また、ケーススタディを通して、AI に対する認可制御の難しさについて検討しました。
簡単にまとめると、AI に対する認可制御を考えるうえでの重要なポイントは以下の2点です。
- まずは AI ができることを必要最小限に: なんといっても、基本は最小権限の原則です。AI には、それが果たすべき役割に必要な権限・機能のみを付与するようにしましょう。
- より柔軟な認可制御へ: 最小権限の原則に沿った仕組みを構築できたら、次は AI を使う人やその文脈に応じて、ちょうどよい権限を柔軟に付与できるような仕組みを検討してみましょう。
AI と認可制御に関する課題、そして、その困難さへのアプローチについて理解いただけたでしょうか。以降では、ここまでの内容をもとに、AI と認可制御に関する各観点について、より具体的に検討していくことにしましょう。
「AI でつくる人」のための認可制御上の観点
本記事を読まれている方の中で (ソフトウェアエンジニアではなくても) プログラミングに何らかの形で関わったことのある方であれば、「AI でつくる」体験、すなわち、AI によるコード補完やコード生成、はたまた Devin に代表されるような AI エージェントを用いた Vibe Coding を経験済みの方も多いのではないでしょうか。
筆者も当初はこれらの技術について少し懐疑的でしたが、今や AI による支援無しでどのようにプログラミングを行っていたのか全く記憶にありません。このブログの原稿は Google Docs で書いているので当然そんなことはないのですが、入力中に次の文章がサジェストされるのを無意識に待っている瞬間がしばしばあり、習慣化の怖さを思い知らされます。
さて、AI による開発支援ツールは、その機能を発揮するためにコードのリポジトリやローカルファイルシステム、さらに開発環境内の特定のサービスやリソースへのアクセスを要求するものがほとんどです。このようなアクセスを許可する場合、開発者は「AI にどのような権限を付与するべきか」を正確に把握するとともに、実際に付与する権限を最小限に抑えることが望ましいと言えます。
以下に、AI による開発支援ツールを利用する場合における、認可制御上の重要な観点について示します。
- 機密情報漏洩の防止
- ツールに対して過度に広範な権限を付与すると、意図せずリポジトリやファイルシステムに保管されているクレデンシャル等にアクセスされ、それをモデルの学習に利用されたり、AI が連携する外部のサービスに送信されたりするおそれがあります。
- そのため、ツールがアクセスできるリソースや、連携できるサービスのスコープを必要最小限に抑えるとともに、モデルにおける学習機能のオプションを無効化するなど、複合的な対策が必要です。
- 意図しないアクションの防止
- 上記と同様に、ツールに対して過度に広範な権限が付与されていたり、過度な自律性が容認されていたりすると、当該ツールがリクエストを行った開発者の意図を超えたアクション (想定外のコードの変更や外部サービスの呼び出し等) を実行するおそれがあります。
- そのため、ここでもやはりツールに与える権限を必要最小限に抑えることが重要です。
これらに加えて、AI が特定のタスクを実行する前に、管理者によるタスク計画の承認を必須とするような仕組みも対策として有効です。例として、Devin では「Devin should proceed without waiting for approval on complex tasks」というオプションを無効化することで、タスクを実行する前にリクエストを行った開発者の承認を必要とするようになるため、意図しない結果につながるリスクを低減させることができます。
「AI をつくる人」のための認可制御上の観点
ここまでで述べた通り、AI エージェントやそれを活用したサービス、アプリケーションを開発する「AI をつくる人」は、システムにおける認可制御の設計を十分理解したうえで、開発に取り組むことが重要だと言えます。本セクションでは、そのような開発現場において堅牢な認可制御を実現するためのアーキテクチャやプラクティスについて検討、紹介します。
コンテキストアウェアな認可制御の採用
AI エージェントが持つ自律性や依頼されるタスクの多様性に対応するためには、静的な RBAC といった単純な認可制御モデルでは対応しきれないことが容易に想像できます。よって、より高度な認可制御モデルを採用する必要があるでしょう。
「コンテキストアウェアな認可制御」とは、AI エージェントが動作する際の様々な文脈 (context) に基づいて、付与すべき権限や操作の実行可否を決定するアプローチです。考慮される文脈として、以下のような事項が挙げられます。
- リクエスト元ユーザーの属性
- AI エージェントの属性
- アクセスが必要なリソースのセキュリティレベル
- 実行されるアクションの種別
例として、ケーススタディのセクションで紹介した「人事部所属のマネージャー以上の役職のユーザーには人事に関するデータを表示してもよいが、その他の社員には表示してはいけない」という認可制御上の要件を実現するための実装について考えてみましょう。このような要件を実現するためには「リクエスト元ユーザーの属性を参照し、それが特定の条件を充足している場合に限って人事データベースへの接続ツールを与える」といった構成が妥当そうです。以下に、疑似コードを示します。
agent = agent.new() user = request.user if user.department == "HR" and user.position.is_superior_than("manager"): agent.add_tool(hr_database_tool.new()) agent.start_thinking(request.prompt)
さらに、ポリシーベースのアーキテクチャ上でこのような動的な認可制御を実装することで、実際に認可上の判断を行うポイント (PDP: Policy Decision Point) が一元化されます。その結果、ユーザーが AI エージェントを介してサービスを利用するかどうかにかかわらず、一貫した方法で認可の判定が行えるようになります。
たとえば、OPA (Open Policy Agent) ベースのアーキテクチャを採用する場合、以下のような Rego で実装されたポリシーを認可制御用のマイクロサービスにセットしておきます。そして、エージェントとアプリケーションの双方が、特定のアクションに対する認可の判断を共通のマイクロサービスに問い合わせるようにします。
package ...
default allow = false
allow {
input.user.department == "HR"
is_manager_or_above(input.user.role)
input.requested_data_type == "HR"
}
is_manager_or_above(role) {
# マネージャー以上の役職リスト
manager_roles := {"マネージャー", ...}
manager_roles[role]
}
このような構成にしておくことで、認可に関する要件の変更を柔軟に行えるようになります。たとえば、「AI エージェント経由であれば、マネージャー以上ではなくても人事部所属なら許可する」という要件が追加されたとします。このような場合、以下のようにポリシーの実装を変更するだけで済むため、いちいちアプリケーションやエージェントの実装を変更する必要がなくなります。
package ...
default allow = false
allow {
input.origin == "app"
input.user.department == "HR"
is_manager_or_above(input.user.role)
input.requested_data_type == "HR"
}
allow {
input.origin == "agent"
input.user.department == "HR"
input.requested_data_type == "HR"
}
is_manager_or_above(role) {
# マネージャー以上の役職リスト
manager_roles := {"マネージャー", ...}
manager_roles[role]
}
AI ゲートウェイの活用
ここまでの例では AI エージェントが直接データソースや外部サービスにアクセスするような方式を前提として説明してきました。もう一つの有効な方法として、AI エージェントとデータベースなどの間に、専用の「関所」のような役割を果たすゲートウェイを設置し、AI エージェントが行うすべてのインタラクションが必ずこのゲートウェイを経由するようにする方式があります。これは、AI エージェントが外部とやり取りするための専用の API を用意する方式である、と考えると分かりやすいでしょう。
この方式の利点は、ポリシーベースのアーキテクチャを採用する場合と同様に、AI エージェントに関する認可の判断や、AI エージェントがアクセス可能な外部の機能を統一的に管理できる点にあります。これらに加えて、リクエストレートの制限やプロンプトのサニタイズ、出力内容のフィルタリングなど、AI エージェントを導入するにあたって考慮すべきその他の要件も同時に実現することが可能です。
おわりに
本記事では、AI 時代における認可制御について俯瞰的に説明しました。まず、認可制御の基礎やそのバリエーション、原則等について紹介し、不備があった場合にどのようなリスクが生じうるのかを検討しました。次に、AI と認可制御にまつわる課題について検討するとともに、レポート作成 AI エージェントを題材として、ケーススタディ的にどのような問題が発生しうるのかについて議論しました。最後に、「AI でつくる人」および「AI をつくる人」に向けて認可制御上の重要な観点を紹介するとともに、具体的な AI エージェントのための認可アーキテクチャについて検討しました。なお、本記事で触れている内容は AI と認可制御にかかわる話題のほんの一部です。ぜひ、他の AI セキュリティに関するブログ記事にも目を通してみてください。
AI や LLM がソフトウェアエンジニアリングのあらゆる側面に浸透するにつれて、その権限設計は単なるセキュリティ上の要件にとどまらず、真に信頼して協働できる AI を構築するための根幹となっています。AI エージェントが持つ自律性に伴う恩恵を最大限に享受するためには、堅牢な認可制御の仕組みが不可欠です。本記事が、読者のみなさまが「AI でつくる」「AI をつくる」際のヒントになれば幸いです。
お知らせ
GMO Flatt Securityは2025年3月から日本初のセキュリティ診断AIエージェント「Takumi」を開発・提供しています。Takumiを導入することで、高度なセキュリティレビューや巨大なコードベース内調査を月額7万円(税別)でAIに任せることができます。
また、セキュリティエンジニアによる脆弱性診断・ペネトレーションテストとして「LLMアプリケーション診断」を正式リリースしました。LLMを活用するアプリケーションの実装のセキュリティリスクをソースコード解析により網羅的に検出します。
今後ともGMO Flatt SecurityはAIエージェントを開発している組織だからこその専門的な深い知見も活かしながら、AIを活用するソフトウェアプロダクトにとって最適なサービスを提供していきます。公式Xをフォローして最新情報をご確認ください！
