OCI IAMによるAIエージェントの信頼できるアクセスの構築 (2026/10/30)

https://blogs.oracle.com/cloud-infrastructure/building-trusted-access-for-ai-agents-with-oci-iam

投稿者：Rajath Ravikumar | Senior Principal Product Manager

 Apurv Awasthi | Vice President of Product Management

2026年4月、PocketOSは、ステージング環境での問題解決中に、AIコーディングエージェントが広範な権限を持つAPIトークンを発見し、それを使用して同社の本番データベースを削除したと報告した。ガーディアン紙の報道によると、このエージェントは開発者の要求や承認なしにこの操作を実行したという。

今回の事件は、企業におけるアイデンティティ管理の根本的な課題を浮き彫りにしました。エージェントにシステムへのアクセス権限を与えたとしても、その所有者がエージェントが実行できるすべての操作を承認したとは限りません。企業がAIに委任する業務が増えるにつれ、エージェントの行動範囲を制限し、機密性の高い操作には追加の承認や人間の承認が必要となる場合を判断するための、より強力な管理体制を構築する必要があります。

Oracleでは、企業ワークフローにおけるAIの活用を検討する中で、この課題に直面しました。Enterprise ChatGPTを社内システムに接続した際、AIが各従業員のアクセス権限が認められた情報のみにアクセスできるように、従業員のアクセス権限を維持することを最優先事項としました。Codexとオペレーター向けエージェントの導入により、AIは既に従業員が本番システムへのアクセス権を持つ環境でツールを使用するようになりました。エージェントのアクションが承認された範囲内に収まるように、これらの導入段階では、ジャストインタイムアクセス、最小権限レビュー、機密性の高い操作に対する人間の承認を導入しました。

これらの経験から、AIエージェントの導入には認証と認可の適用方法を再考する必要があるという確信が強まりました。Oracle Cloud Infrastructure Identity and Access Management（OCI IAM）は既に、ユーザー、アプリケーション、ワークロードに対する認証、認可、およびID管理機能を提供しています。AIエージェントが意思決定を行い、作業を委任し、エンタープライズシステムと連携する際の、AIエージェントの新たな要求に対応するため、これらの機能を拡張する方法を検討しています。

AIエージェントがアイデンティティに新たな要求を突きつける理由

現在では、単一のリクエストに対して、独立して動作する多数のエージェントが関与する可能性があり、中には数分間だけ動作するエージェントもあります。インシデントを調査するオペレーターは、専門のエージェントに作業を委任するエージェントを使用する場合があります。これらのエージェントがオペレーターの認証情報や共通のアプリケーションIDを共有している場合、監査記録にはアカウントは特定できますが、どのエージェントがアクションを実行したかは特定できません。そのため、タスク終了後に責任の所在を明確にすることが困難になります。

エージェントには、作業の進行状況に応じて変化する権限も必要です。エージェントはまずログやメトリクスを調べ、その後、修復には構成の変更が必要だと判断する場合があります。最初から広範なアクセス権限を与えると不必要なリスクが生じる一方、読み取り専用アクセスに制限するとタスクの完了を妨げる可能性があります。企業は、確立されたアクセス制限を超えずに、タスクの進行に合わせて権限を調整できる方法を必要としています。

エージェントが操作を実行する権限を持っている場合でも、状況は重要です。未使用リソースをクリーンアップするエージェントはデータベースを削除する権限を持っているかもしれませんが、本番サービスをサポートするデータベースを削除すると、顧客に支障をきたす可能性があります。企業は、承認されたアクションを実行すべきか、ブロックすべきか、または人間の承認を必要とするかを判断するための安全対策を確立する必要があります。

OCI IAMのアイデンティティ基盤に基づいて構築

OCI IAMは既に認証、ワークロードID、フェデレーション、集中管理ポリシー、監査機能を提供しています。さらに、標準ベースのOAuth機能を拡張し、モデルコンテキストプロトコル（MCP）を介してエンタープライズツールに接続するAIアプリケーションをサポートしました。これらの機能には、認可サーバーの検出、クライアントIDメタデータドキュメント（CIMD）のサポート、リソース固有のアクセストークン、クロスアプリケーションアクセスなどが含まれます。これらの機能により、アプリケーションは信頼できる接続を確立し、システム間で認可されたアクセスを維持できます。

次に私たちが注力するのは、この基盤を拡張し、エージェントが大規模に運用される方法や、実行中にエージェントの権限がどのように変化するかに対処することです。

すべてのエージェントに責任を持たせる

当社は、個々のエージェントおよびサブエージェントの実行ごとに、固有の短命なIDを開発しています。これらのIDは、作成を担当したユーザー、ワークロード、または親エージェントに紐付けられるように設計されています。このアプローチは、委任されたタスク全体にわたる帰属管理と、実行終了後の監査記録の保持をサポートするように設計されています。これにより、顧客はどのエージェントが操作を実行したか、そのエージェントが誰の権限を行使したか、そしてその権限がどのように委任されたかを把握できるようになります。

エージェントに、その任務に必要な権限のみを与える

IAMロールは、承認されたユーザーとエージェントが、定義された権限を一定期間引き受けることができるように開発されています。タスクが進化するにつれて、エージェントはIAMポリシーで定められた最大権限の範囲内で、追加の権限を要求できるようになります。サブエージェントは、委任元のエージェントと同じか、より狭い権限に制限されます。このアプローチは、広範な常時アクセスへの依存度を軽減しつつ、エージェントが事前に正確な手順を予測できないタスクを完了できるように設計されています。

承認された措置を進めるべきかどうかを判断する

コンテキストを考慮したアクセス判断を支援するため、OracleはIAMポリシーで許可されている操作が現在の状況下で実行されるべきかどうかを評価する機能を開発しています。利用可能な信頼できるシグナルを使用することで、コンテキスト認証は操作を許可するか、追加の人的承認を要求するか、または拒否するかを判断するのに役立ちます。たとえば、エージェントが削除権限を持っている場合でも、データベースの削除をブロックしたり、実行前に検証済みの人的承認を要求したりすることができます。

重大な行動を人々にコントロールさせる

指定された機密性の高い操作については、IAM ポリシーによって、または要求に追加の監視が必要な場合にはコンテキスト認証によって、人間の承認を認可ワークフローに組み込むことができます。承認が必要な場合、OCI IAM は、YubiKey タッチや OCI Identity Assurance による生体認証などの制御を使用して人間の承認者を検証し、承認を特定のアクションに紐付けることができます。

企業をコントロール下に置く

AIエージェントの登場により、ますます複雑化する業務の委任が可能になっている。企業は、エージェントに重要なシステムに対する無制限の権限を与えることなく、この機能の恩恵を受けるべきである。

長年にわたり企業システムを保護してきたアイデンティティ原則は、依然として不可欠である。変化するのは、これらの原則を多数の独立して動作するエージェントに適用する必要性、作業の進行に伴って変化する権限、そして行動の結果を考慮しなければならない意思決定の必要性である。

Oracleでは、OCI IAMの確立された機能と標準ベースのアプローチを拡張し、AIエージェントのIDおよびアクセス管理をサポートする方法を模索しています。その目的は、組織がAIエージェントに有意義な作業を委任しつつ、誰が、何を、いつ実行すべきかについて適切な監視とアクセス制御を維持できるようにすることです。