ヒューマン・イン・ザ・ループ万能説崩壊 NISTが提唱するAIエージェント運用のあるべき姿：人間の権限は与えていいのか？

AIエージェントに人間の資格情報を渡し、必要なときだけ「承認」を押す。そんな運用は一見、安全そうに見える。しかしNISTによると、この人間が絡む運用には大きな穴があるという。一体それは何だろうか。

[＠IT]

　AIエージェントの導入が進めば、その“暴走”を防ぐために、ID管理はこれまで以上に重要になる。だが米国国立標準技術研究所（以下、NIST）が警告するのは、単純な「AI向けIAM」の導入ではない。人間向けに残ってきた古い慣行をAIエージェントに持ち込めば、その価値を損なう可能性がある。問題はAIそのものだけではないのだ。

　NISTは2026年8月27日（現地時間）、AIエージェントの安全な普及には、強固なID管理と認可の基盤が欠かせないとするブログ「Back to the Future: Why Agentic AI Needs a Strong Identity Foundation」を公開した。

　AIエージェントは、利用者の指示を受けて情報を取得したり、外部サービスを操作したり、複数のツールを組み合わせてタスクを実行したりできる。そのため、単に「AIが安全に回答できるかどうか」を考えるだけでは不十分だ。

　NISTは、自動化や生産性向上を急ぐAIエージェントの初期導入では、機能や即効性が安全性より優先されがちだと指摘し、AIエージェントが誰の代理として、どの権限で、何を実行したのかを管理できる仕組みが必要になると訴えた。

AIエージェントになぜ「人間の権限」を委譲してはいけないのか？

　NISTがまず問題視するのが、利用者の資格情報をAIエージェントに共有する運用だ。例えば、利用者が自身の認証情報をAIエージェントに渡し、その資格情報を使って外部サービスを操作させる場合、実際にその操作を実行した主体を明確にすることが難しくなる。

　これは単なるセキュリティ上の問題にとどまらない。金融取引や医療情報の共有など、誰が操作したのかを明確にする必要がある場面では、安全性だけでなくプライバシーや法務上の問題にもつながる。

　そこで重要になるのが、AIエージェント自身のアイデンティティーと、人間や運用システムとの関係を管理することだ。AIエージェントを単純に「ユーザーの代わりにログインする存在」とするのではなく、どのAIエージェントが、誰の指示や権限に基づいて行動したのかを追跡できるようにする必要がある。

　企業環境では、SPIFFEやOAuth 2.0など既存の標準技術を基礎として、AIエージェントのアイデンティティーを扱うことが考えられる。WIMSEやIdentity Assertion JWT Authorization Grantなど、エージェントやサービス間でアイデンティティーを扱うための仕組みも挙げられている。

　一方、コンシューマー向けの環境では、人間とエージェントをどのように識別するかという課題が残る。NISTは、FIDOにおける認証器を巡る議論についても、まだ初期段階にあると指摘している。

　もう一つの問題が、長期間利用できるAPIキーやサードパーティーサービスのアクセストークンだ。

　長期有効な資格情報は、利用主体のアイデンティティーを十分に証明できない場合があり、漏えいすれば第三者によって利用される可能性がある。設定ファイルやログに資格情報が平文で残ることも問題になる。

　NISTは、短期間だけ動作するエージェントであれば、資格情報や認可も短命かつ必要最小限にする考え方を示している。

　OAuth 2.0、SPIFFE、JSON Web Token（JWT）、X.509などの既存標準は、そのための基盤になり得る。ただ、これらの標準を採用するだけでAIエージェントの安全性が確保されるわけではない。重要なのは、エージェントが必要とする期間、範囲、利用先を限定した資格情報と認可を設計することだ。

　例えばDPoPは、トークンが盗まれた場合でも、そのトークンを別の主体がそのまま利用するリスクを軽減する仕組みとして利用できる。NISTは、この領域に関連してNISTIR 8587の草案も公開している。

　さらに厄介なのが、過剰な権限だ。

　人間のユーザーに付与されている権限を、そのままAIエージェントに与えれば便利ではある。しかし、AIエージェントは人間が一つずつ操作する場合とは異なり、複数のツールやデータにまたがる処理を短時間で実行できる。その結果、当初想定していなかったツールやデータにアクセスしたり、データセットやコードを削除したりする可能性がある。

　さらに、環境内に放置された資格情報などを見つけ、それを利用して権限を広げる可能性もある。

　このため、単に最新の認証プロトコルへ移行するだけでは問題は解消しない。必要なのは、AIエージェントが何をするのか、その事業上の価値とリスク許容度に応じて、必要な権限だけを細かく与える認可設計だ。

　NISTは、その実現に関連する仕組みとして、動的で細粒度の認可を可能にするRich Authorization Requests（RAR）、呼び出しの連鎖に認可コンテキストを伝えるTransaction Tokens、外部のポリシー判断・執行機能との標準APIを提供するAuthZenなどを挙げている。

　ここでも重要なのは、特定の技術を導入すること自体ではない。「誰にどこまで権限を渡すか」という従来のIAMの問題を、エージェントについても細かく制御できるようにすることにある。

　また、ローカル端末上で利用者アカウントの権限をそのままエージェントに与える方式についても、NISTは警告する。

　開発や資料作成では便利だが、エージェントが利用者になりすまして広範な操作を実行できる状態になりやすい。さらに、エージェントごとの行動主体を中央のID台帳で管理することも難しくなる。

　NISTはローカル環境でのエージェント利用そのものがなくなるとは考えていない。そのため、強化された実行基盤や厳格なコンテナ型サンドボックスなどによって、エージェントが接触できる範囲を制限する考え方を示している。

ヒューマン・イン・ザ・ループ万能説崩壊　あるべき運用の姿とは？

　AIエージェントの操作を人間が確認してから実行する「ヒューマン・イン・ザ・ループ」（HITL）も、万能な防御策ではない。

　人間による承認を挟めば、危険な操作を止められるように思える。しかしAIエージェントが大量の操作を実行し、そのたびに承認を求めるようになれば、別の問題が発生する。

　承認要求が頻繁に表示されれば、利用者は内容を十分に確認せず、反射的に許可するようになる可能性がある。NISTはこれを多要素認証（MFA）疲労と同様の問題として捉え、承認に過度に依存することで、説明責任や否認防止を弱める恐れがあると指摘する。

　つまり、「最後は人が確認すればいい」という設計も、AIエージェントの実行量が増えれば防波堤として機能しなくなる可能性がある。

　Model Context Protocol（MCP）における「elicitation」は、エージェントが処理の途中でユーザーから追加情報を求めるための仕組みだ。こうした仕組みは対話型の処理に有用だが、認証情報や機密情報を入力させるような設計にすれば、エージェントやユーザーになりすます攻撃につながる可能性がある。

　MCP側でも、elicitationを機密情報の要求に利用しないよう注意を促している。

　重要なのは、ユーザーに何度も「この操作を許可しますか」と尋ねることではない。あらかじめ許可する行動の範囲を定義し、エージェントがその範囲を逸脱した場合に止められる仕組みが必要になる。

　NISTは、こうした考え方の一例として、事前に承認した「flight plan」に基づいてエージェントの行動範囲を定める取り組みを紹介している。プロンプトに機密情報を含めない設計と組み合わせることで、承認疲れや情報漏えいのリスクを抑えることを狙うものだ。

　NISTは今後、ID標準をAIエージェントに実用的に適用する方法について業界関係者と検討を進め、ブログやオンライン資料拠点、NIST文書などを通じて情報を公開していくとしている。