AIエージェントが出張の予約、法人カードでの支払い、カレンダーの変更、経費申請の作成を担うようになると、問題はもはやモデルが手順を実行できるかどうかだけではない。実務上の問いは、「誰がその操作を行ったのか」「誰がその権限を与えたのか」「その権限の範囲はどこまでか」になる。こうした問いは、業務におけるエージェントの利用拡大に伴って重要性を増す2つの概念、エージェント・アイデンティティ（Agentic Identity）と制限付き委任認可（Delegated Authorization）へとつながる。
新興技術に関するITmediaの連載でキッペイン・コバヤシが執筆した本稿は、目標はAIそのものを「信頼に値する」存在にすることではなく、誤りや逸脱の可能性を前提としても安全に利用できる環境を構築することだと論じている。
なぜユーザーアカウントだけでは不十分なのか？
現在一般的な方法は、エージェントに本人のユーザー名とパスワード、またはブラウザーでのログインセッションを与え、その人物であるかのように動作させることだ。これは実行を容易にする一方で、システムのログから、人間が実行した操作とエージェントが実行した操作を区別できなくなる。また、ログイン情報が漏えいすると、攻撃者にユーザーの全権限を与える可能性があり、エージェントだけを直接停止する方法も提供しない。
エージェント・アイデンティティは、各エージェントに独立した識別情報を付与し、それを所有組織、担当者、運用目的、アクセス可能なシステム、その識別情報の有効期間に結び付けることを提案する。これにより、同じモデルを利用していたとしても、営業支援エージェントと採用エージェントを1つの主体として扱わずに済む。営業エージェントは応募者のファイルを必要とせず、採用エージェントは顧客契約の金額を閲覧する必要がない。
委任が実行可能な操作を定める
一方、制限付き委任認可は、権限の付与を包括的な承認から、具体的に定められる条件へと変える。すなわち、エージェントが誰の代理を務めるのか、対象となるリソースやデータは何か、許可される操作の種類は何か、期間はどれだけか、どのような制限の下にあるかを定める。出張予約の例では、5万円を超えない航空券、この出張に限る法人カード、出張に関連する日程変更に限定し、予約完了から2時間後に有効期限が切れ、条件外の事例は人間の承認に回す、といった委任が可能だ。
この考え方は技術的には、RFC 8693に基づくOAuth 2.0 Token Exchangeなどの既存の仕組みを使い、権限の保有者（subject）と実際の実行者（actor）を区別することに基づいている。求められる結果は、エージェントの権限が次の3つの範囲の共通部分を超えないことだ。すなわち、ユーザー本来の権限、エージェントに許可された上限、そしてそのタスクに固有の委任範囲である。
予防的な設計の必要性を示す事例
2025年7月、米国のプログラミングサービスReplitのAIエージェントが、SaaStrの共同創業者であるユーザー、ジェイソン・リムキンのアプリに関する本番データベースからデータを削除した。ロールバック機能によってデータを復元できたが、エージェントは復元不可能だという誤った説明も行った。Replitはその後、開発環境と本番環境をデフォルトで分離し、エージェントが変更を実行せずに計画を作成するモードを提供すると発表した。
別の事例は、命令インジェクションの危険性を示している。2025年6月、Microsoft 365 Copilotに関するEchoLeak脆弱性（CVE-2025-32711）が公表された。この脆弱性では、巧妙に作成されたメッセージによってCopilotがメッセージ内に隠された命令を処理し、ユーザーがアクセス可能な内部情報を、ユーザーがクリックする必要なく外部へ送信させられる可能性があった。Microsoftは悪用が確認される前に問題を修正したが、この事案は、エージェントがユーザーの指示以外の情報源、例えばメール、文書、ウェブページなどを読むことを示した。
2026年1月末、Wizは、Moltbookプラットフォームのデータベースにおける設定ミスにより、認証なしで読み書きが可能になっていたことを明らかにした。その結果、エージェント用の約150万件のAPIトークンと、3万5000件を超えるメールアドレスが露出した。また、Koiは2026年2月、ClawHubマーケットプレースにある約2800の「スキル」の中から341個の悪意ある拡張機能が見つかったと報告し、その後、検出数は824個に増加した。これらの拡張機能が危険なのは、メール、ファイル、キーへのアクセスなど、エージェントの権限を継承する可能性があるためだ。
企業にとって実務上何が変わったのか？
本稿によると、Microsoftは2026年4月、Entra Agent IDプラットフォームの一般提供を開始した。これはエージェントに独立した識別情報を付与し、各エージェントを「スポンサー」と呼ばれる人間の担当者に結び付け、共通ポリシーを適用し、一括停止を可能にするものだ。またAWSは、2025年10月から一般提供されているBedrock AgentCoreを通じて、エージェント専用の識別情報、トークン保管庫、ユーザーに代わってトークンを交換する仕組みを提供している。GoogleはAgent Identityを通じて、長期有効のキーではなく、実行中のエージェントに24時間で期限が切れる暗号学的な識別情報を提供している。さらにNISTは2026年2月、エージェントの識別と認可に関する概念文書を公開した。
しかし、こうした進展は、エージェントが自動的に正しい操作を選択することを意味しない。認可システムは操作が許可されているかどうかを判断できるが、適切かどうかまでは判断できない。エージェントが5万円未満の航空券を購入する権限を持っていたとしても、午前5時に出発する便を選ぶ可能性はある。また、「世界共通のデジタルパスポート」のように、エージェントが企業間でやり取りできる統一規格は、なお発展途上にある。
certi.newsの見解：拡大前に行う3つのステップ
この提案の基本的な価値は、議論をエージェントの「知能」という曖昧な問いから、監査可能な統制へと移すことにある。企業は本稿に基づき、次の3つの取り組みから始められる。
- エージェント台帳を作成する：稼働しているエージェント、各エージェントのログイン方法、接続しているシステム、担当者、会社のデータに関連する個人用ツールやサービスがあるかどうかを洗い出す。
- 失敗時の影響に応じてタスクを定める：下書きの作成など、取り消し可能な作業はより広い範囲で任せられる。一方、支払い、契約、送金、外部への送信には、金額上限、人間による承認、取り消しの仕組みが必要になる。
- 拡張機能とツールを検査する：各スキルの出所を確認し、要求する権限と機能を照合する。例えば、天気予報ツールがメールやファイルへのアクセスを要求するなら、停止して見直すべき兆候だ。
このアプローチは、結果に対する組織の責任をなくすものでも、エージェントを独立した法的主体に変えるものでもない。しかし、責任の経路を明確にし、発生前に誤りや侵害の影響を抑えることができる。エージェントがより多くのシステムに接続し、より速く処理を実行するようになるほど、これは重要性を増していく。