AIエージェントのID・権限管理とは　NISTが進めるAgent Identity、OAuth・OIDC・最小権限の設計

AIエージェントが企業システムへアクセスするようになると、「誰がログインしたか」だけではアクセス管理が成立しなくなります。

人間がAIへ「取引先の未払い請求を確認して」と依頼した後、AIエージェントがERP、メール、CRMへ接続し、別のサブエージェントを起動する場合、実際にシステムを操作する主体は人間ではありません。

一方で、AIへ人間のアカウントや長期間有効なAPIキーをそのまま渡せば、プロンプトインジェクションやエージェントの誤動作が発生した際、そのユーザーが持つ権限すべてが被害範囲になり得ます。

米国NIST National Cybersecurity Center of Excellence（NCCoE）は2026年2月、「Software and AI Agent Identity and Authorization」のConcept Paperを公開しました。

同資料では、AIエージェントを人間と区別して識別する仕組み、OAuthを使った認可、人間からエージェントへの権限委任、ログと透明性、プロンプトインジェクション発生後の影響低減までを検討対象としています。

AIエージェントの安全な導入では、モデルの安全性だけでなく「IDと権限」が新しい中核になります。

AIエージェントのID・権限管理のサマリー

• 【確認済み】NIST NCCoEは2026年2月、Software and AI Agent Identity and AuthorizationのConcept Paperを公開しました。
• 【重要】同資料は最終標準ではなく、NCCoEが実証プロジェクト等を検討するためのConcept Paperです。
• 【確認済み】NISTはAIエージェントについて、人間と区別可能なID、認証、認可、権限委任、監査、データフロー追跡を主要論点に挙げています。
• 【確認済み】NISTはAIエージェントの認可にOAuth 2.0/2.1、OpenID Connect、ポリシーベースのアクセス制御など既存標準の活用を検討しています。
• 【確認済み】NISTは「最小権限をどう定義するか」「人間からエージェントへのon behalf of委任をどう扱うか」を明示的な検討課題としています。
• 【確認済み】英国NCSCはAIシステムに最小権限を適用し、外部システムを操作するAIには可能なアクションの制限を設けるよう推奨しています。
• 【確認済み】イスラエル発のCyberArkはAIエージェントを新しい特権IDクラスとして扱い、Just-in-Time、Zero Standing Privileges、継続監視を適用する製品・設計を公開しています。
• 【確認済み】イスラエル発のSilverfortも、Microsoft Copilot StudioのAIエージェントに対して実行時のID・アクセス制御を適用する仕組みを発表しています。
• 【本記事の整理】企業ではAIエージェントを人間の「代理アカウント」とせず、独立した非人間IDとして可視化し、人間の委任関係とセットで管理することが重要です。

管理項目	人間ユーザー	AIエージェントで追加すべき視点
Identity	社員ID	エージェント固有ID、所有者、モデル、用途
Authentication	MFA等	workload identity、証明書、短期トークン
Authorization	RBAC	タスク・目的・時間・ツール単位の動的認可
Delegation	代理権限	誰の指示を誰の権限で実行したか
Privilege	管理者権限	Zero Standing Privileges、JIT
Audit	操作ログ	プロンプト→判断→ツール呼出→結果の連鎖
Lifecycle	入社・異動・退職	作成・複製・停止・廃止・所有者変更

AIエージェントは「新しい非人間ID」

クラウドでは以前からサービスアカウント、APIキー、ワークロードIDなどのNon-Human Identity（NHI）が使われてきました。

AIエージェントも人間ではないため広い意味ではNHIに含められます。

ただし、従来のサービスアカウントと大きく異なる特徴があります。

一般的なバッチ処理は、事前に決められたコードを決められた順序で実行します。

AIエージェントは自然言語の目標から計画を作り、状況に応じて使用するツールや操作順序を変える可能性があります。

つまり「認証主体は機械」でありながら、「行動が完全には決定論的でない」という性質を持ちます。

このため、従来の「このサービスアカウントにはこのAPI権限を恒久付与する」という設計では権限が広くなりやすくなります。

NISTがAIエージェントのIdentityを正式な研究テーマに

NIST NCCoEは2026年2月、AIエージェントへ既存のID標準とベストプラクティスを適用するためのConcept Paperを公開しました。

NISTが検討している領域は大きく5つに分かれます。

1つ目はIdentificationです。

アクセス管理基盤が人間とAIエージェントを区別し、エージェントが何を実行できるか管理できるようにします。

2つ目はAuthorizationです。

OAuthやポリシーベースアクセス制御を使い、AIへ与える権限・Entitlementを制御します。

3つ目はAccess Delegationです。

特定のユーザーとAIエージェントを結び付け、誰の代わりに行動しているかを追跡します。

4つ目はLogging and Transparencyです。

AIエージェントの操作を非人間IDと結び付け、実行したアクション、生成データ、結果を追跡できるようにします。

5つ目はData Flow Trackingです。

ユーザーのプロンプトやデータ入力元の来歴を追跡し、AIが行動する際のリスク判断に利用します。

これらは、従来IAMの延長線上にありながら、AIエージェント固有の「委任」「意図」「自律性」を追加する考え方です。

最小権限は「静的RBAC」だけでは足りない

NISTのConcept Paperでは、AIエージェントに対して最小権限をどう確立するかが明示的な問いとして挙げられています。

AIエージェントの必要なアクションは、タスク実行前に完全には予測できない場合があります。

例えば、

「未払い請求を確認し、必要なら担当者へ連絡して」

というタスクでは、ERPの読み取り、CRMの担当者検索、メール送信が必要かもしれません。

この場合、

「AIにERP・CRM・メールの全権限を常時付与する」

のではなく、

• ERPは請求情報の読み取りのみ
• CRMは該当顧客のみ
• メールは下書き作成まで
• 外部送信は人間承認
• 権限はタスク完了まで

という細分化が必要です。

AIエージェントではRBACだけでなく、時間、タスク、意図、対象リソース、データ機密度などを組み合わせた動的認可が重要になります。

「誰の代わりに動いたか」を残す

AIエージェントの監査では、エージェントIDだけでは不十分です。

NISTは「on behalf of」の権限委任と、人間IDとAIエージェントIDを結び付けるHuman-in-the-Loop Authorizationを検討課題にしています。

例えばAIが顧客データを削除した場合、

「AI Agent-123が削除した」

だけではなく、

「営業部Aさんが依頼したタスクに基づき、Agent-123がAさんから委任された限定権限で削除要求を作成し、管理者Bさんが承認した」

まで追えることが望まれます。

これにより、インシデント対応、内部監査、規制対応で責任と経緯を説明しやすくなります。

OAuth・OIDCを使っても安全性は自動的に確保されない

NISTはAIエージェントの認証・認可でOAuth 2.0/2.1、OIDCなど既存標準の活用を想定しています。

ただしOAuthを導入すれば安全という意味ではありません。

重要なのは、

• どのエージェントへトークンを発行したか
• どのリソース向けか
• どのScopeか
• どのユーザーから委任されたか
• 何分有効か
• いつ失効できるか

を制御することです。

特にAIエージェントへ長期間有効なRefresh Tokenや管理者権限を渡すと、プロンプトインジェクションやエージェント侵害時の影響が大きくなります。

可能な限り短期トークンを使い、必要なタスクが終われば失効させる設計が適しています。

CyberArkはAIエージェントを「特権ID」として扱う

イスラエル発のCyberArkは、AIエージェントを新しい特権Identityクラスとして扱う製品・設計を公開しています。

同社はAIエージェントへ、

• Discovery
• 最小権限
• Just-in-Time Access
• Zero Standing Privileges
• 継続的なセッション監視
• Lifecycle Management

を適用する考え方を示しています。

特に「Zero Standing Privileges」はAIエージェントと相性の良い考え方です。

業務を待っているだけのAIエージェントに、24時間管理者権限を持たせておく必要はありません。

タスク開始時だけ必要な権限を付与し、終了後に自動回収する方が、侵害された場合のブラストラジウスを小さくできます。

SilverfortはAIエージェントの実行時認可を重視

同じくイスラエル発のSilverfortは2026年、Microsoft Copilot StudioのAIエージェントに対してRuntime Identity & Access Controlを適用する統合を発表しました。

AIエージェントが実際に企業リソースへアクセスしようとする時点でポリシーを評価し、不正なアクセスを実行前に遮断する考え方です。

AIエージェントでは、作成時に一度権限を審査するだけでは不十分です。

利用するツール、データ、タスク、委任元が実行のたびに変わり得るため、ランタイムでの認可が重要になります。

AIエージェントの「所有者不明」が新しいシャドーITになる

企業ではAIエージェントが、

• SaaSの標準機能
• Copilot Studio等のノーコード環境
• 開発者のローカル環境
• GitHub Actions
• クラウド上のAgent Framework
• MCP連携

など様々な場所から増えていきます。

このとき問題になるのが、誰が所有者なのか分からないエージェントです。

人間のアカウントなら、人事情報と連動して退職時に無効化できます。

AIエージェントは所有者、用途、作成部署、利用中の資格情報を台帳化しなければ、担当者が異動・退職した後も動き続ける可能性があります。

セキュリティ対策Labでは、企業のAI導入でAIを独立したIdentityとして扱っている組織が少ないという調査を企業のAI導入が招く情報漏洩リスク-シャドーAIと権限過多が明らかにで取り上げています。

Microsoft EntraのAI Agent管理ロールでも権限問題が発生

AIエージェント向けのIAMは、新しい機能であるため実装自体も攻撃面になります。

セキュリティ対策Labでは、Microsoft Entraの「Agent ID Administrator」ロールに関する権限問題をMicrosoft Entra「Agent ID Administrator」ロール 範囲逸脱でテナント全体の乗っ取りが可能で取り上げています。

この事案はMicrosoftが修正済みですが、AI専用ロールを作っただけで安全になるわけではないことを示しています。

重要なのは、Role Definition、対象Resource、Ownership、Service Principal、委任関係を含むIAM全体のAttack Pathを評価することです。

AIエージェントID台帳に最低限持たせる項目

企業でAIエージェントを管理する場合、次の情報を最低限台帳化します。

項目	内容
Agent ID	一意のエージェント識別子
所有者	業務責任者・技術責任者
作成元	SaaS、Cloud、開発環境
用途	実行する業務
Model	利用モデル・バージョン
Tools	API、MCP、ブラウザ、Shell等
Human delegator	誰の代理で動くか
Credentials	利用するサービスID・Token
Privileges	読取・書込・削除・管理
Data scope	アクセスできるデータ分類
Network	接続可能な外部・内部先
Approval	人間承認が必要な操作
Logs	記録先と保持期間
Expiry	エージェント・資格情報の失効日

AIエージェント権限の設計例

AIエージェントには、操作の重大性に応じて権限を段階化すると管理しやすくなります。

レベル1：読み取りのみ

社内Wiki検索、FAQ、公開情報調査などです。

外部への書き込みや送信を許可しません。

レベル2：下書き・提案

メール下書き、チケット案、設定案、コード修正案まで作成します。

実際の送信・反映は人間が行います。

レベル3：限定的な自動実行

特定のSaaS、特定のデータ範囲に限って自動操作を許可します。

件数、金額、時間帯などに上限を設けます。

レベル4：高リスク操作

支払い、外部公開、データ削除、IAM変更、本番コード変更などです。

原則としてHuman-in-the-Loopの承認を必須にします。

この設計では「AIがどれほど賢いか」ではなく、「失敗した場合の影響」で権限を決めます。

情報システム部門への示唆

企業のIAMは今後、人間、従来型のMachine Identity、AI Agent Identityの3種類を同時に扱う必要があります。

AIエージェントだけを別のセキュリティ製品で囲うのではなく、既存のIAM、PAM、IGA、Secrets Management、SIEMとつなげることが重要です。

特に優先したいのは次の5点です。

1. AIエージェントを発見し、一意のIDと所有者を付ける
2. 人間のアカウントを共有せず、エージェント専用資格情報を使う
3. 常時権限を避け、JIT・短期トークンを使う
4. 高リスク操作には人間承認を入れる
5. 人間の依頼からAIの実行結果まで一連のログを残す

英国NCSCも、AIシステムに最小権限を適用し、外部アクションへ適切な制限を設けることを推奨しています。

AIエージェントのID管理は「将来の高度なAI対策」ではありません。

メール、CRM、クラウド、GitHubなどへAIを接続した時点で、すでにIAMの問題になります。

従来のIAMの強みを活かしつつ、タスク・意図・委任・自律性というAI固有の情報を加えることが、2026年以降の企業ID管理で重要になります。

セキュリティ対策LabではIAM全体の基礎をIAMとは-なぜ必要なのか 機能や種類も解説で解説しています。

出典

• Accelerating the Adoption of Software and AI Agent Identity and Authorization – NIST NCCoE
• Guidelines for secure AI system development – UK National Cyber Security Centre
• CyberArk Introduces First Identity Security Solution Purpose-Built to Protect AI Agents with Privilege Controls – CyberArk
• AI agents are forcing a reckoning with identity and control – CyberArk
• Silverfort Integrates AI Agent Identity Control for Microsoft Copilot Studio – Silverfort
• Israel National Cybersecurity Strategy – Israel National Cyber Directorate
• 企業のAI導入が招く情報漏洩リスク-シャドーAIと権限過多が明らかに – セキュリティ対策Lab
• Microsoft Entra「Agent ID Administrator」ロール 範囲逸脱でテナント全体の乗っ取りが可能 – セキュリティ対策Lab
• IAMとは-なぜ必要なのか 機能や種類も解説 – セキュリティ対策Lab