※ 本記事は、Rajath RavikumarおよびApurv Awasthiによる「Building trusted access for AI agents with OCI IAM」を翻訳したものです。
2026年11月5日
2026年4月、PocketOSは、AIコーディング・エージェントがステージング環境で問題のトラブルシューティングを行っていた際に、広範な権限を持つAPIトークンを見つけ、それを使って同社の本番データベースを削除したと報告しました。The Guardianの報道によると、エージェントは開発者からの依頼や承認なしにこの操作を実行しました。
このインシデントは、企業のアイデンティティ管理における根本的な課題を浮き彫りにしています。エージェントにシステムへのアクセスを許可することは、その所有者が、エージェントが実行できるすべての操作を承認したことを意味しません。企業がAIに委ねる役割や責任が増える中、エージェントが実行できることを制限し、慎重な扱いが必要な操作に追加の認可や人による承認が必要となる条件を定めるために、より強力な制御を導入する必要があります。
オラクルも、企業のワークフローでAIの活用を検討する中で、この課題に直面してきました。Enterprise ChatGPTを社内システムに接続した際には、従業員のアクセス権限を維持し、AIが各従業員に閲覧を許可された情報だけにアクセスできるようにすることを優先しました。Codexや運用担当者向けエージェントの導入に伴い、AIは、従業員がすでに本番システムへのアクセス権を持つ環境でツールを使うようになりました。こうした導入では、エージェントの操作を承認された範囲内に収めるため、必要なときに必要な期間だけアクセス権を付与するジャストインタイム・アクセス、最小権限の原則に基づくアクセス権の見直し、慎重な扱いが必要な操作に対する人による承認を取り入れました。
これらの経験を通じて、AIエージェントに対して認証と認可をどのように適用するかを見直す必要があるという確信を深めています。Oracle Cloud Infrastructure Identity and Access Management（OCI IAM）は、ユーザー、アプリケーション、ワークロードに対して、認証、認可、アイデンティティ管理の機能をすでに提供しています。オラクルは、AIエージェントが意思決定を行い、作業を委任し、企業システムとやり取りする際に生じる追加の要件に対応するため、これらの機能を拡張する方法を検討しています。
AIエージェントがアイデンティティ管理に新たな要件をもたらす理由
現在では、1つのリクエストに、独立して動作する多数のエージェントが関わることがあり、その中には数分間しか稼働しないものもあります。たとえば、インシデントを調査する運用担当者は、専門のエージェントに作業を委任するエージェントを利用するかもしれません。これらのエージェントが運用担当者の認証情報や共通のアプリケーションIDを共有していると、監査記録からアカウントは特定できても、どのエージェントが操作を実行したのかは分からない場合があります。その結果、タスクの終了後に責任の所在を明らかにすることが難しくなります。
また、エージェントに必要な権限は、作業の進行に伴って変化します。エージェントは、まずログやメトリックを調べ、その後、問題の解決には構成の変更が必要だと判断するかもしれません。最初から広範なアクセス権を与えると不要なリスクが生じる一方、読み取り専用のアクセスに制限すると、タスクを完了できなくなる場合があります。企業には、あらかじめ定めたアクセス権限の上限を超えることなく、タスクの進展に応じて権限を調整する手段が必要です。
エージェントに操作を実行する権限がある場合でも、そのときの状況が重要です。未使用のリソースを整理するエージェントがデータベースの削除権限を持っていたとしても、本番サービスを支えるデータベースを削除すれば、お客様に影響が及ぶ可能性があります。企業は、権限上は許可された操作を実行してよいのか、ブロックすべきなのか、それとも人による承認が必要なのかを判断するための安全対策を整える必要があります。
OCI IAMのアイデンティティ基盤を拡張
OCI IAMは、認証、ワークロードID、フェデレーション、一元管理されたポリシー、監査をすでに提供しています。また、Model Context Protocol（MCP）を通じて企業のツールに接続するAIアプリケーションを支援するため、標準に準拠したOAuth機能も拡張してきました。これらの機能には、認可サーバーの検出、クライアントIDメタデータ・ドキュメント（CIMD）のサポート、特定のリソースを対象とするアクセス・トークン、Cross-App Accessが含まれます。アプリケーションが信頼できる接続を確立し、システムをまたいで認可されたアクセスを維持できるよう支援します。
次に注力するのは、この基盤を拡張し、エージェントが大規模に動作する際の課題や、実行中に権限が変化することへの対応です。
すべてのエージェントの責任の所在を明確に
オラクルは、個々のエージェントとサブエージェントの実行ごとに、有効期間の短い固有のIDを付与する仕組みを開発しています。これらのIDは、その作成に責任を持つユーザー、ワークロード、または親エージェントに関連付けることを想定しています。このアプローチは、委任先でのタスクも含めて各操作の実行主体を特定し、実行終了後も監査記録を保持できるように設計されています。これにより、お客様が、どのエージェントが操作を実行したのか、誰の権限を行使したのか、その権限がどのように委任されたのかを把握できるようにすることを目指しています。
エージェントにはタスクに必要な権限だけを付与
IAMロール（IAM Roles）は、認可されたユーザーやエージェントが、あらかじめ定義された権限を一定期間だけ行使できるようにするため、開発が進められています。タスクの進展に応じて、エージェントは、IAMポリシーで定められた権限の上限内で、追加の権限を要求できるようになる想定です。サブエージェントの権限は、委任元のエージェントと同じか、それよりも狭い範囲に制限する想定です。このアプローチは、広範な権限を常時付与することへの依存を減らしながら、具体的な実行手順を事前に予測できないタスクでも、エージェントが完了できるよう支援することを目指しています。
権限上は許可された操作を実行すべきか判断
オラクルは、コンテキストを考慮したアクセス判断を支援するため、IAMポリシーで許可されている操作を現在の条件下で実行すべきかどうかの評価に役立つ機能を開発しています。利用可能な信頼できるシグナルを使い、コンテキストに応じた認可（Contextual Authorization）によって、その操作を許可するか、人による追加の承認を求めるか、拒否するかを判断できるようにすることを目指しています。たとえば、エージェントに削除権限がある場合でも、データベースの削除をブロックしたり、実行前に本人確認を伴う人による承認を求めたりすることが考えられます。
重大な影響を伴う操作の制御を人の手に
人による承認は、指定された慎重な扱いが必要な操作についてはIAMポリシーによって、また、追加の監督が必要と判断されるリクエストについてはContextual Authorizationによって、認可ワークフローに組み込むことが考えられます。承認が必要な場合、OCI IAMは、YubiKeyへのタッチやOCI Identity Assuranceによる生体認証などの制御を使って承認者本人を確認し、その承認を特定の操作に結び付けることが考えられます。
企業が制御を維持するために
AIエージェントによって、ますます複雑な作業を委任できるようになっています。企業は、重要なシステムに対する無制限の権限をエージェントに与えることなく、こうした能力を活用できることが求められます。
長年にわたり企業システムを保護してきたアイデンティティ管理の原則は、引き続き不可欠です。変わるのは、その原則を、独立して動作する多数のエージェント、作業の進行に伴って変化する権限、そして操作がもたらす影響を考慮しなければならない判断に適用する必要があるという点です。
オラクルは、OCI IAMの実績ある機能と標準に準拠したアプローチを拡張し、AIエージェントのアイデンティティおよびアクセス管理を支援する方法を検討しています。目指すのは、誰が操作するのか、何を実行できるのか、いつ操作を進めてよいのかについて適切な監督とアクセス制御を維持しながら、組織がAIエージェントに実質的な業務を委任できるよう支援することです。