9月21日、Sean Michael Kernerが「How to control agentic AI access to enterprise data」と題した記事を公開した。ITおよびセキュリティ専門家の79%が、AIエージェントを含む非人間アイデンティティ（NHI）経由の攻撃への防御に自信がないという調査結果が示すように、AIエージェントのデータアクセス制御は多くの企業にとって未解決の問題だ。この記事では、エンタープライズ環境においてAIエージェントのデータアクセスをどう制御し、説明責任を確保するかについて詳しく紹介されている。

既存のアクセス制御がAIエージェントに通用しない理由

企業のアイデンティティ管理は長年、「人間のユーザー」か「固定された権限を持つサービスアカウント」のどちらかを前提に設計されてきた。AIエージェントはそのどちらにも当てはまらない。

エージェントはタスクの実行中に新たなツールやデータセットへのアクセスを動的に要求できる。何か問題が起きたとき、「誰がエージェントを承認したか」「どのリソースにアクセスしたか」「権限委譲はどのように行われたか」を追跡できるログが残っていないケースが多い。

この問題の深刻さは数字にも表れている。Oasis Securityが後援したCloud Security Allianceの2026年調査（約400名のITおよびセキュリティ専門家を対象）では、79%が非人間アイデンティティ（NHI）経由の攻撃への防御に自信がないと回答。16%以上の組織はAI関連の新しいアイデンティティの作成自体を追跡していないと答えた。さらにGartnerは、2028年までに、従業員がAIエージェントと認証情報を共有することを許可している組織の90%が、その慣行を変えるための多額の投資を迫られると予測している。

現状よく使われる対処として、サービスアカウントへの割り当てや、OAuthフローの延長、既存のDLP（データ損失防止）ツールの転用などがあるが、いずれも根本的な問題を解決していない。主な欠点は以下の通りだ。

• 認証情報がデプロイ時に発行され、その後再評価されない
• エージェントにタスクに必要な範囲を超えた権限が付与される
• ログにアクションを開始・承認した人物の情報が残らない
• 既存の監査ツールは動的なエージェント行動を追跡するよう設計されていない

エンジニアが押さえるべき4つの制御レイヤー

1. エージェントID（Agent Identity）

本番環境の各エージェントに共有サービスアカウントではなく、固有の帰属可能なアイデンティティを付与することが出発点だ。

NISTは2026年2月のコンセプトペーパーで、OAuth 2.0/2.1、OpenID Connect、SPIFFE/SPIRE（ワークロードID用）、SCIM（ライフサイクル管理用）といった既存標準を用いてAIエージェントを保護するガイダンスを公開している。エージェントの行動を承認した人物まで追跡可能にするプロトコル拡張についても言及されている。

2. ランタイム認可（Runtime Authorization）

最小権限の原則をエージェントに適用するには、タスク・アクション・アクセス対象リソースごとに必要な権限だけをその都度付与する仕組みが必要だ。

MCP（Model Context Protocol）の認可モデルは「インクリメンタルスコープ同意」をサポートしており、作業の進行に応じてサーバーが追加権限を要求できる設計になっている。これにより、広範な静的権限付与をタスクに絞った動的な権限に置き換えられる。

3. 委任権限（Delegated Authority）

エージェントがユーザーの代わりに行動する場合、その権限委譲が証明可能でなければならない。元記事では、MCPの認可モデルが組織のIDプロバイダーを通じてエージェントとアプリケーション間の接続を管理する仕組みについて言及されている。

技術的な基盤として、IETFで議論が進む Identity Assertion JWT Authorization Grant の考え方が紹介されている。標準的なトークン交換を使い、人間のIDを確認しつつエージェントの権限を制限する仕組みを実現するアプローチだ。

4. マシンネイティブ監査（Machine-native Audit）

事後の説明責任のため、各委任アクションをそれを開始した人物と実行したエージェントに紐付ける、改ざん防止済みの記録が必要だ。有用な監査記録は以下を含む必要がある。

• エージェントが何を行う権限を持っていたか
• 実際にどのアクションを取ったか
• どのリソースにアクセスまたは変更を加えたか

ベンダー選定と実装の優先順位

ベンダー選定・実装の局面では、単にチェックリストを埋めるのではなく、「エージェントが何かを実行したとき、その行動を誰に帰属させられるか」という問いを軸に判断することが重要だ。記事では具体的な確認事項として以下を挙げている。

• 各本番エージェントは専用のアイデンティティを持つか、共有サービスアカウントで動くか
• 人間のIDがエージェントを通じてすべてのダウンストリーム呼び出しにどう伝播するか、ユーザー・エージェント・委任権限・実行アクションを示すサンプル監査レコードを提示できるか
• 認証情報は短命でタスクにスコープされているか、問題のあるエージェントをどれだけ速く失効させられるか

これらの問いに答えられないベンダーやアーキテクチャは、4つの制御レイヤーのいずれかが欠落している可能性が高い。

実装の優先順位としては、本番エージェントがエンタープライズデータに触れる前に、担当の人間を特定・割り当てること、長期的な静的認証情報を単一タスク・リソース・アクションにスコープした短命トークンに置き換えること、そして認可チェックをデータレイヤーに移し、リクエスト時点でアクセスを評価する構成にすることの3点が示されている。

エージェントがAPIやデータサービスを人間のアプリを介さず直接呼び出す前提でアーキテクチャを設計し、エージェントのクエリも人間のアクセスと同じポリシーレイヤーを通す構成が求められる。「エージェント用の例外ルート」を設けた時点で、監査とアクセス制御の一貫性は崩れる、というのが記事全体を通じた核心的なメッセージだ。

詳細はHow to control agentic AI access to enterprise dataを参照していただきたい。