AIエージェントでSOC 2のアクセス管理に盲点　人間のIDを借りるエージェントをどう監査するか

AIエージェントが人間のアカウント、OAuthトークン、APIキー、サービスアカウントを使って企業システムを操作するようになり、SOC 2のアクセス管理や変更管理で「誰が実際に操作したのか」を説明しにくいケースが増えています。

2026年9月25日にBleepingComputerへ掲載されたToken Securityの寄稿では、SOC 2のTrust Services CriteriaはAIエージェントを明示的なID種別として扱っていないため、従来どおりのアクセスレビューではエージェントの実態を見落とす可能性があると指摘しています。

ただし、これは「SOC 2がAIエージェントを対象外にしている」という意味ではありません。

AICPAのTrust Services Criteriaは特定技術を前提とせず、アクセス管理、変更管理、委託先管理などの結果を評価する基準です。AIエージェントも、組織がシステムの構成要素やアクセス主体として識別し、適切なコントロールを設計すれば対象に含められます。

問題は、AIエージェントが人間や既存のサービスアカウントの資格情報を借りて動く場合、従来の台帳、アクセスレビュー、ログ、退職者処理だけでは「エージェントが存在すること」自体を捕捉できない可能性がある点です。

結論：SOC 2が古くなったのではなく、管理対象の定義が追いつくかが論点

SOC 2は、AICPAのTrust Services Criteriaに基づき、サービス組織のセキュリティ、可用性、処理のインテグリティ、機密保持、プライバシーに関するコントロールを評価するアテステーション報告です。

AIエージェントの普及によってSOC 2の基準そのものが無効になるわけではありません。

企業側で確認が必要なのは、現在のコントロールが次のような状態になっていないかです。

SOC 2の観点では「AIを導入したか」ではなく、AIエージェントがシステム内で何を実行でき、誰の権限を使い、誰が責任を持ち、いつ停止されるかを説明できる状態にする必要があります。

Token Securityが指摘する「4つの前提」

BleepingComputerの記事はToken Securityによるスポンサー寄稿です。

同社は、従来のアクセス管理で暗黙に置かれてきた4つの前提が、AIエージェントでは成立しにくくなると指摘しています。

アカウントは作成前に承認される

人間の社員であれば、入社や異動を起点にアカウント申請、承認、発行が行われます。

AIエージェントでは、従業員がOAuth画面で「許可」を押す、APIキーを設定ファイルへ記載する、MCPサーバーを追加するといった操作だけで、新しい実行主体が業務システムへアクセスできる場合があります。

組織側に「新しいAIエージェントを作成した」という申請記録が残らなければ、アクセス台帳に現れないまま稼働します。

すべてのIDには明確な所有者がいる

人間のアカウントでは、原則として所属部署と本人を特定できます。

AIエージェントでは、誰が作成したのか、現在誰が責任を持っているのか、どの業務のために動いているのかが記録されていないケースがあります。

作成者が異動・退職した後も、OAuth grantやAPIキーが残っていればエージェントだけが稼働し続ける可能性があります。

ログに表示された名前が実際の操作主体を示す

AIエージェントが社員本人のセッションやPersonal Access Token、サービスアカウントを使う場合、ログ上では「社員A」や「service-account@example」と表示されても、実際に操作したのはAIエージェントということがあります。

アクセスレビュー上は正しい人物・正しい権限に見えても、実際の実行主体が別であれば、監査証跡の意味が変わります。

権限を見ると、そのIDが何をするためのものか分かる

従来の最小権限では、職務に必要な権限を付与し、それ以上を持たせないことが基本です。

AIエージェントでは、同じ権限でもプロンプト、取得した文脈、外部ツールの出力によって実行内容が変化します。

「Salesforceを読み書きできる」という権限だけでは、「どの目的で、どのレコードを、どの条件で変更してよいか」までは表現できません。

この4点はAICPAが公式に定義した「SOC 2の欠陥」ではなく、Token SecurityがAIエージェント運用に照らして提示した分析です。

68％が「人間とAIエージェントの操作を区別できない」

Cloud Security Alliance（CSA）がAembitの委託を受けて2026年1月に実施した調査では、228人のIT・セキュリティ担当者から回答を得ています。

その結果、68％の組織が、人間による操作とAIエージェントによる操作を明確に区別できないと回答しました。

さらに、

• 85％がAIエージェントを本番環境で利用
• 74％がAIエージェントへ必要以上の権限を与える場合がある
• 79％がAIエージェントによる新しいアクセス経路を監視しにくいと回答
• 43％が共有サービスアカウントを利用
• 31％が人間のユーザーIDでAIエージェントを動作させている
• アクセス管理フレームワークを「非常に一貫して」AIエージェントへ適用できている組織は22％

という結果でした。

この調査はAembitが資金提供し、CSAと共同で質問票を作成したものです。CSAがオンライン調査、分析、解釈を行っています。

調査結果は世界全体の企業を代表する統計ではありませんが、「人間のIDを借りるエージェント」が監査証跡を曖昧にする問題を定量的に示しています。

82％が把握していなかったAIエージェントを発見

CSAがToken Securityの委託を受けた別の2026年調査では、418人のIT・セキュリティ担当者が回答しました。

この調査では、

• 82％が、セキュリティ・IT部門が把握していなかったAIエージェントを発見
• 65％が過去12カ月にAIエージェント関連のセキュリティインシデントを経験
• インシデント経験組織の61％で機密データの露出または不適切な取扱いが発生
• 正式なAIエージェントの廃止・退役プロセスがある組織は21％

という結果が示されています。

SOC 2でアクセス管理やオフボーディングを評価していても、そもそもAIエージェントが資産・ID台帳に登録されていなければ、レビュー対象から外れる可能性があります。

シャドーAIについては、業務に潜むシャドーAIとはでも整理しています。

CC6.1～CC6.3では「人間のIDを借りるエージェント」を確認

AICPAのTrust Services Criteriaでは、CC6系で論理アクセスに関するコントロールを扱っています。

CC6.1は、保護すべき情報資産への論理アクセスを保護するためのセキュリティソフトウェア、インフラ、アーキテクチャなどを扱います。

CC6.2は、システム資格情報を発行しアクセスを許可する前に、内部・外部ユーザーを登録・認可する考え方を含みます。

CC6.3は、役割、責任、システム設計、変更に応じてアクセスを許可・変更・削除することを扱います。

AIエージェント運用では、これらを人間だけに適用せず、エージェントも独立したアクセス主体として扱えるかが確認点になります。

企業側では少なくとも、

• エージェントID
• 所有者
• 業務目的
• 人間の依頼者・委任元
• 接続先
• 利用する資格情報
• 権限
• 有効期限
• 作成日
• 最終利用日
• 停止条件

を台帳化しておくと、アクセスレビューの対象を明確にできます。

AIエージェントのID・権限管理については、AIエージェントのID・権限管理とはでNISTの資料を基に詳しく整理しています。

NISTもAIエージェントの「識別・認可・監査」を独立した論点として扱う

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

NISTは、AIエージェントがデータ、ツール、アプリケーションへアクセスする際のリスクに対し、適切な識別と認可が必要だとしています。

検討項目には、

• AIエージェントの識別
• 認証
• 認可
• 人間からエージェントへの権限委任
• 監査
• 否認防止
• プロンプトインジェクション後の影響軽減

などが含まれます。

NISTの資料は最終規格ではなくConcept Paperですが、「AIエージェントを人間や従来のソフトウェアと区別して追跡できるか」が企業IAMの課題になっていることを示しています。

CC6.3では「社員を退職させてもエージェントが残る」問題がある

人間の退職処理では、HRシステムを起点にIdP、メール、SaaSなどのアカウントを停止する仕組みを整えている企業が増えています。

AIエージェントでは、同じ退役処理が存在しない場合があります。

例えば社員が退職した際、

• 本人のIdPアカウントは停止
• メールアカウントも停止
• VPNも無効化

されても、

• 個別発行したAPIキー
• 長期間有効なOAuth grant
• サービスアカウント
• MCPサーバーの資格情報
• 開発端末上のAIエージェント設定

が残る可能性があります。

CSAとToken Securityの調査で、正式なエージェント退役プロセスを持つ組織が21％にとどまった点は、このライフサイクル管理の弱さと整合します。

アクセスレビューでは「社員アカウントを削除したか」だけでなく、その社員が作成・所有・認可したAIエージェントや非人間IDまで関連付けて確認する必要があります。

CC8.1ではAIが作成・レビューする変更の独立性を確認

CC8.1は、インフラ、データ、ソフトウェアなどへの変更について、認可、設計、開発・設定、文書化、テスト、承認、実装を管理する基準です。

AIコーディングエージェントの導入では、コードを作成する主体とレビューする主体が人間とは限りません。

例えば、

1. AIエージェントAがコードを生成
2. AIエージェントBがレビュー
3. CI/CDが自動テスト
4. 条件を満たすと自動デプロイ

という構成が考えられます。

この場合、「作成者と承認者が別IDだった」という事実だけでは、実質的な職務分離を説明できない場合があります。

2つのAIエージェントが同じモデル、同じポリシー、同じ所有者、同じ資格情報体系で動作している場合、別IDだから独立したレビューと判断できるかは、組織のコントロール設計次第です。

なお、AICPAのCC8.1自体が「AI同士の承認を禁止している」わけではありません。

企業が変更管理上どの行為を人間承認とするのか、AIによるレビューをどの範囲で証拠として認めるのかを明文化する必要があります。

CC9.2ではMCPサーバーや外部AIツールを委託先管理へ含める

CC9.2は、ベンダーやビジネスパートナーに関連するリスクを評価・管理する基準です。

従来の委託先管理では、契約、購買申請、セキュリティチェック、SOC 2報告書の取得などを通じて第三者を把握します。

AIエージェントでは、従業員がMCPサーバーや外部AIサービスを設定ファイルへ追加するだけで、社内データへアクセスする新しい第三者接続が生まれることがあります。

MCPサーバーが、

• GitHub
• Slack
• Salesforce
• Snowflake
• 社内データベース
• ファイルサーバー

などへ接続する場合、技術的には単なる「AIツール追加」でも、情報を受け取り、外部コードを実行し、企業システムを操作する第三者サービスとして評価が必要になることがあります。

MCPの認証・権限・シャドー利用のリスクは、Model Context Protocol（MCP）のセキュリティリスクや対策で整理しています。

SOC 2 Type 2の報告書があっても「すべてのAIエージェントが管理済み」とは限らない

AICPAは、SOC 2 Type 2では対象システムに対するコントロールの設計と、対象期間における運用有効性を評価すると説明しています。

SOC 2報告書は、企業全体のあらゆるセキュリティリスクが存在しないことを保証するものではありません。

AIエージェントが、

• システム記述に含まれていない
• 資産台帳に存在しない
• 人間の資格情報を借りている
• 外部MCPとして勝手に追加されている
• 監査ログで人間と区別できない

状態であれば、既存のコントロールが正常に動作していても、実際のAI利用状況を十分に説明できない可能性があります。

したがって、SOC 2取得企業では「監査に通っているからAIエージェントも管理済み」と判断せず、システム記述とコントロール対象にAIエージェントが含まれているかを確認する必要があります。

SOC 2対応企業がAIエージェント導入時に確認したいポイント

AIエージェントを本番環境へ導入する企業では、既存のSOC 2対応プロセスへ次の項目を組み込めます。

• AIエージェントとMCPサーバーを資産台帳へ登録する
• 各エージェントに一意のID、所有者、業務目的を割り当てる
• 人間の個人アカウントをそのままエージェントへ共有しない
• 共有サービスアカウントを減らし、エージェント単位で監査可能にする
• OAuth、APIキー、サービスアカウントの有効期限と失効条件を定める
• 人間とAIエージェントの操作をログで区別できるようにする
• 誰の依頼を受けてエージェントが操作したかを記録する
• 権限だけでなく、許可された目的・処理範囲も定義する
• 作成者の退職・異動時に関連エージェントと資格情報を同時に失効する
• AIが作成・レビュー・承認・実装した変更の役割分担を明文化する
• MCPサーバーや外部AIツールを第三者リスク管理へ含める
• 監査人と事前にAIエージェントのシステム記述・証跡・サンプリング方法を確認する

特に最初に確認したいのは、「本番環境で稼働しているAIエージェントをすべて列挙できるか」です。

CSAの2つの調査では、未把握のAIエージェント、過剰権限、人間との識別不能、退役プロセス不足が複数確認されています。

SOC 2対応をAIエージェントへ広げる場合、既存のチェックリストへAI項目を追加するだけでなく、IDの発行から停止までを一つのライフサイクルとして管理する必要があります。

AIエージェント全体のセキュリティリスクについては、AIエージェントのセキュリティとはも参照してください。

出典

• 2017 Trust Services Criteria (With Revised Points of Focus – 2022) – AICPA & CIMA
• SOC for Service Organizations Engagements – Overview – AICPA & CIMA
• Identity and Access Gaps in the Age of Autonomous AI – Cloud Security Alliance
• More Than Two-Thirds of Organizations Cannot Clearly Distinguish AI Agent from Human Actions – Cloud Security Alliance
• Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises – Cloud Security Alliance
• New Cloud Security Alliance Survey Reveals 82% of Enterprises Have Unknown AI Agents in Their Environments – Cloud Security Alliance
• Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization – NIST NCCoE