AIアクセス制御：なぜ権限はメモリ層にあるべきなのか

要点

• AIエージェントを本番投入しているチームの多くは、そのエージェントが実際に何を閲覧できるのかを言い当てられていません。2026年時点で、どのエージェント同士が通信しているのかを完全に可視化できている組織はわずか24.4%にとどまり、エージェントを共有サービス認証情報に付け足すのではなく、エージェント自体を一つのアイデンティティとして扱っている組織はたった21.9%です。(Gravitee, 2026) AIアクセス制御とは、まさにこのギャップを埋める（あるいは埋めそこなう）場所です。
• エージェントに対するアクセス制御は、たいてい手遅れの段階で行われています。エージェントが認証を通り、データを取得し、その後で応答をフィルタリングするのです。データはすでにエージェントのコンテキストに入り込んでいます。より強固なモデルは、何かが取得される前に、メモリ層でアイデンティティと権限を強制します。
• エージェントには、人間だけを前提としたモデルでは同時に制御する必要のなかった3つの軸で制御が求められます。すなわち、何を読み取れるか、何を書き込めるか、そして1回のターンで連鎖させられるアクションは何か、です。プロンプトのルールやAPIトークンは最後の一つを制御しますが、最初の一つを取りこぼします。
• 重要となる制御は、プロンプトレベルではなくアーキテクチャレベルのものです。すなわち、アイデンティティのスコープ（RBAC/ABAC）、権限昇格を伴わない権限の継承、オブジェクト単位・フィールド単位でのジャストインタイム検査、機微なアクションに対するヒューマン・イン・ザ・ループ、そしてエージェントとそれが代行した人物の双方を記録する改ざん不能な監査証跡です。
• このページはアクセスのアーキテクチャ、つまり権限がどのように付与され、強制されるのかを扱います。AIエージェントの脅威に関する当社の見解を写したものではなく、その対となる内容です。攻撃対象領域についてはAIエージェントセキュリティをご覧ください。

エージェントのためのAIアクセス制御とは何か？

AIアクセス制御とは、AIエージェントがどのデータを読み取れるか、何を変更できるか、どのアクションを取れるか、そして誰の権限のもとで動作するかを決定する、一連のルールと強制メカニズムのことです。適切に実装されていれば、エージェントはそれが代行する人物とまったく同じ権限を継承し（それ以上は継承せず）、すべてのアクセスは使用の瞬間に、オブジェクト単位・フィールド単位で検査され、その後、改ざん不能な証跡へ記録されます。

自律型エージェントの場合、人間だけを前提としたモデルが主に最後の一つだけを気にかけていたのに対し、3つのスコープを同時にカバーしなければなりません。

• 読み取りスコープ ― エージェントが取得し、推論の対象にできるもの。サポートエージェントが人事記録を自身のコンテキストに取り込むことは決してあってはなりません。
• 書き込みスコープ ― エージェントが変更できるもの。低リスクの更新と、記録システムへの影響の大きい変更とを切り分けます。
• アクションスコープ ― エージェントが呼び出せるツール。返金、プロビジョニング、エスカレーションといった下流のアクションを制御します。

この用語はいい加減に使われがちなので、それが「何ではないか」をはっきりさせておくと役立ちます。システムプロンプト内の一行 ― 「ユーザーが閲覧を許可されたデータのみにアクセスすること」 ― はアクセス制御ではありません。プロンプトは丁寧なお願いであって、強制の境界ではないのです。認証もアクセス制御ではありません。エージェントが*誰*であるかを知っても、それが*何*にアクセスできるかは決まらないからです。

そして、脅威という意味でのエージェントセキュリティ ― プロンプトインジェクション、ジェイルブレイク、データ流出 ― とも同じものではありません。それらは攻撃です。アクセス制御は、そうしたものが関わってくる前に権限を決定するアーキテクチャです。脅威対象領域についてはAIエージェントセキュリティで別途扱っています。このページは、アイデンティティと権限が実際にどのように強制されるかを扱います。

層の問題：後からフィルタするか、事前に強制するか

これが、たいていのアクセス制御が見過ごしている違いであり、他のすべてを左右する点です。

たいていのエージェントアーキテクチャは、アイデンティティを検証し、エージェントに要求したデータを取得させ、その後で応答をユーザーが閲覧を許可された範囲まで絞り込みます。一見安全に見えます ― ユーザーが権限のないフィールドを目にすることはありません。しかしデータはすでにエージェントのコンテキストに入り込んでいます。フィルタが実行される前に、取得され、トークン化され、推論・要約・偶発的な漏洩に利用できる状態になっていたのです。「応答からフィルタで除いた」というのは、毎回、それが機能したことを証明しなければならない主張です。

より強固なモデルは、取得層で強制します。エージェントはユーザーのアイデンティティを継承し、アクセス制御は何かが取得される*前*にデータ層で適用されます。ソースシステムから継承したフィールド単位の権限が、クエリごとに評価されます。権限のないフィールドは結果セットに一切入らず ― トークン化されることも、ワーキングメモリに入ることも、推論の対象になることもありません。「そもそも取得されなかった」というのは、「後から取り除いた」とは構造的に異なる保証であり、規制対象の購入者にとっては、監査を乗り切れるのはこちらです。

APIの境界が立ち位置として誤っている理由は、もう一つあります。人間は一度に1つのリクエストを行いますが、エージェントは1回のターンで5つのアクションを連鎖させます ― 取得し、推論し、書き込み、ツールを呼び出し、エスカレーションする、といった具合です。各エンドポイント呼び出しをスコープで区切るトークンは、これらのアクションを個別に評価するため、一連のシーケンス全体をスコープ内に収めることができません。メモリ層での強制は、個々の呼び出しだけでなく、連鎖全体が推論の対象とするコンテキストを統治します。

したがって、以下で取り上げるどのプラットフォームについても、問うべきは「RBACを備えているか」ではありません。「RBACがどこで強制されるのか ― 回答の段階か、それともメモリの段階か」です。

AIエージェントのアクセス制御を定義する5つの制御

これはアーキテクチャのチェックリストとして読んでください。各制御について問うべきは、プラットフォームがそれを謳っているかどうかではなく、ランタイムで強制されているのか、それとも単にプロンプトでお願いしているだけなのか、です。

これら5つのうち4つは同じ形で失敗します。エージェントの下位でアクセスを強制するのではなく、エージェントの周りにアクセスを設定してしまうのです。データ層に存在するアクセス制御は、プロンプトが誤っていても、モデルが差し替えられても、エージェントがスコープを読み違えても、揺るぎません。

Computerがアクセスを強制する場所 ― 回答ではなく、メモリで

DevRevによるComputerは、権限が出力へのフィルタではなく、データ層の性質となるように設計されています。その差別化要因であるTeam Intelligenceは、権限を意識するナレッジグラフであるComputer Memory上で動作し、アクセスモデルはこのアーキテクチャから導かれます。

双方向同期エンジンであるAirSyncは、各ソースシステムのアクセス制御をデータと*ともに*取り込み、それを最新の状態に保ちます。つまり、あるサポートエンジニアがSalesforceで契約金額を閲覧できないのであれば、Computerもそれを閲覧できず、ましてや表示することもできません。さらにAirSyncはスキーマを認識するため、その強制はレコードだけでなくフィールド単位にまで及び ― データが実際に読み取られる層で維持されます。

ここではアイデンティティが第一級の概念です。1つのモデルが、人間もエージェントも同じように統治します。エージェントは、それが代行する人物として実行し、その人物とまったく同じスコープを継承します。エージェントが委任する作業も、そのスコープの内側にとどまります ― 権限昇格はありません。権限は各アクションの瞬間に再検査されるため、誰かのアクセス権がセッション途中で取り消された場合、次の呼び出しは古い権限のまますり抜けるのではなく、失敗します。

エージェントが読み取りから*行動*へ移るとき、Safe Actionsがそのステップを統治します。重大な書き込みは、ヒューマン・イン・ザ・ループの承認 ― 承認または拒否。1回の呼び出し、またはセッション全体にスコープ指定 ― を待って一時停止し、サンドボックス化がエージェントの動作中にツールが触れられる範囲を制限します。

すべてのアクションは、エージェント、それが代行した人物、そして何が変わったかを記録する監査証跡に残り、起きるべきでなかった場合には取り消すことができます。アクセス制御とアクションガバナンスは同じ生地の一部であり、これこそが書き戻しを有用かつ安全なものにするものです。これは、AIエージェントのメモリガバナンスで概念的に扱っている内容の、運用面にあたります。

実際のチームにとってこれがどう見えるか

アクセス要求を処理するエージェントを運用しているITサービスデスクを考えてみましょう ― エージェントの権限を誤ることが最も大きな代償を招く場面の一つです。なぜなら、そのエージェントの仕事そのものがアクセスを付与することだからです。

あるマネージャーが、直属の部下のパスワードをリセットするようエージェントに依頼します。アイデンティティスコープは、エージェントがそのマネージャーの権限の範囲内でのみ動作してよいと決定するため、そのスコープ外の要求は、チケットが作成される前に、その理由を示したうえで拒否されます。ソフトウェア要求は権限に応じてスケールします。メンバーレベルのものは自動承認される一方、管理者レベルのものは二段階の承認チェーンを上っていき、役割外の要求はゲートに突き当たります。

よりリスクの高いアクションには、さらに厳しい制御がかかります。本番データベースやrootへの時間制限付きの昇格アクセスは、正当な理由と期間ポリシーとともに付与され、期限が切れると自動的に取り消されます。MFAリセットはセルフサービスではなくマネージャーの証明を必要とし、不審なものはアカウントを即座に一時停止し、その場でセキュリティチームに通知します。これらの判断のいずれもが、アイデンティティ層から実際の認可を継承し、監査証跡に残ります ― プロンプトが丁寧にお願いしたからではなく、権限モデルがそれを強制したからです。

これこそがアクセス制御が本来の役目を果たしている姿です。エージェントは、その権限が制限され、帰属が明確で、取り消し可能である*からこそ*、真に有用なのです。

よくある質問

AIエージェントのアクセス制御とAIエージェントセキュリティの違いは何ですか？

アクセス制御は権限に関するもの ― エージェントが何を閲覧・実行してよいか、誰の権限を継承するか ― です。脅威という意味でのAIエージェントセキュリティは、攻撃に関するもの、すなわちプロンプトインジェクション、ジェイルブレイク、データ流出、そしてOWASP Top 10 for LLM Applicationsが挙げる過剰なエージェンシーのようなリスクに関するものです。両者は関連しています ― 優れたアクセス制御は攻撃の影響範囲を縮小します ― が、答えている問いは異なります。このページはアクセスのアーキテクチャであり、脅威は別途扱います。

RBACはAIエージェントにどのように適用されますか？

役割ベースのアクセス制御は、エージェントを、広範な共有認証情報で動作させるのではなく、それが代行するユーザーとして動作させ、その人物の役割と権限を継承させることで適用されます。最も強力な実装は、RBAC（および属性ベースのアクセス制御）をオブジェクト単位・フィールド単位にまで拡張し、取得の前にデータ層で強制します。そのため、エージェントがユーザーには見えないフィールドを推論の対象にすることは決してできません。権限はセッションごとに一度ではなく、各アクションで動的に検査されます。

AIエージェントは独自のアイデンティティを持つべきですか？

はい。2026年時点で、エージェントをアイデンティティを持つ実体として扱っている組織はわずか21.9%であり、これはほとんどのエージェントが、それが付随したサービスから広範な認証情報を継承していることを意味します。(Gravitee, 2026) エージェントに第一級のアイデンティティを与え、与えられたタスクについてユーザーとして実行させることこそが、最小権限、権限の継承、そして意味のある監査証跡を可能にします。それがなければ、あるアクションを、本当に誰がそれを認可したのかに帰属させることができません。

AIエージェントの権限にはどのような標準が適用されますか？

エージェントのアイデンティティとアクセスは、エンタープライズITの他の部分と同じ標準の上に構築されます。すなわち、認可のためのRBACとABAC、委任アクセスのためのOAuth 2.0、プロビジョニングと認証のためのSCIMおよびSSO/SAML、そしてスコープ設定のための最小権限とゼロトラストの原則です。リスクの側面では、NIST AI Risk Management FrameworkとOWASP Top 10 for LLM Applicationsが、一般的に参照される公開文献です。エージェントに必要なのは、まったく新しい標準というよりは、これらをメモリ層で強制することです。

エージェントの権限はどこで強制されるべきですか？

データ層で、取得の前に ― 事後に応答へフィルタをかける形ではありません。強制がエージェントによるデータ取得の後に行われるなら、権限のないデータはすでにエージェントのコンテキストに入り込んでおり、フィルタが機能したことを証明しなければなりません。取得の前に強制するということは、権限のないフィールドが取得されることも、トークン化されることも、推論の対象になることも決してない ― 検査可能で、監査に耐える保証 ― を意味します。

問うべきただ一つの質問

AIアクセス制御を評価するとき、プラットフォームが権限モデルを備えているかどうかを問うてはいけません ― 2026年までに、まともなものならどれもそれを謳っています。問うべきは、強制がどこで行われるか、すなわち回答の段階か、それともメモリの段階か、です。その一語の裏には、まったく異なる3つの保証が隠れています。よい振る舞いをお願いするプロンプト。出力を切り詰めるフィルタ。

そして、何かが取得される前に強制される境界。エージェントが誤っているときに揺るがないのは、最後のものだけです。ご自身のシステムから継承され、あらゆるアクションで検査され、取り消し可能な ― メモリ層で強制される権限をご覧になるには、Agent Studioをご覧いただくか、ご自身のアクセス制御シナリオをウォークスルーにお持ち込みください。そして、拒否すべき要求をそれが拒否する様子をご覧ください。