読了時間：4分
オピニオン
企業は、人間の境界を守るために多額の投資をしています。セキュリティチームはフィッシング耐性のある多要素認証（MFA）を導入し、厳格な条件付きアクセスポリシーを適用し、想定外のIPアドレスからのログインをすべて精査します。しかし、人間の従業員を厳しく監視する一方で、エンジニアリングチームは自律型のAIエージェントに、本番環境への広範なアクセスを静かに与えています。こうしたエージェントは多くの場合、サービスアカウントやAPIトークン、委任されたクラウド権限に支えられた非人間ID（NHI）として動作します。
これらのエージェントは、文書を要約するだけではありません。機密性の高いクラウドリポジトリやデータベース、社内環境を横断して、マシン間のアクションを自律的に実行します。認証には有効期間が長く過剰な権限を持つトークンを使うため、従来の対話型アクセス制御の外側に置かれがちです。
多くのセキュリティチームは、ここに深刻な盲点を抱えつつあります。エージェント型ワークフローを、システム全体にアクセスできる自律的なコンポーネントではなく、無害なソフトウェア連携として扱っているためです。既存のAIリスクに関するガイダンスは有用ですが、アクセス制御の問題を見落としている組織は少なくありません。エージェントが行動を起こせるようになれば、そのエージェントはIDの攻撃対象領域の一部になります。コードの実行、リソースのプロビジョニング、財務記録の変更を自律的に行うエージェントは、実質的にあらゆる点で特権ユーザーと同じ振る舞いをします。次に起きる深刻なエージェント型AIの障害は、目に見えるハルシネーションではなく、IDをめぐる大惨事になるかもしれません。
AIモデルのIDとは何か
最近のAIガバナンスをめぐる議論で、チームが苦労していると感じるアクセス上の論点は、モデルが何を語れるかではありません。エージェントが行動を起こす際に、どのIDを使うかです。IT監査の責任者として、高リスクのシステムで私が必ず確認する設計原則の一つが職務分離です。価値の高い業務プロセスを、単一のIDが開始し、承認し、実行できてはなりません。従来の統制は、主要な業務・技術ワークフローでこの境界を厳格に守らせています。開発者はピアレビューなしにコードを本番環境へ直接プッシュできませんし、在庫管理者は自分が作成した補充発注書を自分で承認できません。しかし、アクセス境界を明確にしないままエージェント型AIを導入すれば、この仕組みは崩れかねません。
現実的なクラウド障害のシナリオを考えてみましょう。エンジニアリングチームが、複数プラットフォームのツール連携を効率化するため、AWS IAMのワイルドカード権限（s3:*や緩いsts:AssumeRoleパス）を持つサービスアカウントを基盤として、自動化エージェントを構築したとします。このエージェントはデータベースの制約を監視し、スクリプトの最適化を自動でデプロイする役割を担っています。ある日、インフラの速度低下を検知したエージェントは、解消のためにデプロイスクリプトを書き換え、分離された複数の本番環境にわたって一連のプロビジョニング変更を実行します。
その結果は、典型的なAIの失敗には見えないかもしれません。本番環境の停止、データ整合性の問題、予算外のクラウド費用の急増といった形で表面化する可能性があります。この一連の流れはマシン間で完結するため、従来の「人間が介在する」チェックポイントを回避できてしまいます。エージェントは、起案者、承認者、実行者を同時に務めるのです。自律システムが、分離されたプラットフォームをまたいでエンドツーエンドの取引を実行でき、しかも企業として認識できる証跡を残さないのであれば、従来の統制は弱まります。
AIエージェントをどう統制するか
こうした運用上の脆弱性が、手に負えない内部脅威に発展するのを防ぐには、セキュリティアーキテクチャの中で、エージェント型AIを開発サンドボックスから、ID・アクセス管理（IAM）と特権アクセス管理（PAM）の対象範囲へ移す必要があります。これらの存在に本番環境の鍵を渡す前に、次のような厳しい運用上の現実に照らして、アーキテクチャを徹底的に検証すべきです。
-
エージェントのID： マシンはどのNHIまたはサービスアカウントを使っているか。エージェントは汎用のシステムトークンを共有したり、個々のシステム活動を見えにくくする広範な企業サービスアカウントで動作したりしてはなりません。本番のエージェントにはそれぞれ、分離された非対話型のIDを割り当て、認証トークンは短命にして、認証情報の窃取や再利用のリスクを減らす必要があります。
-
エージェントの権限（影響範囲）： エージェントのアクセスは、限定された業務目的に厳密に絞られているか。レポート作成のためにデータベースのレコードを読み取るだけなら、書き込みや削除の権限を持たせてはいけません。過剰な権限付与は、エージェントを構造的な弱点に変えます。プロンプトインジェクションはツールの使い方を誘導でき、過剰な権限があれば、その誘導された動作がバックエンドシステムにまで影響を及ぼします。
-
エージェントの所有者： マシンの自律的な行動に対するリスクと運用上の責任は誰が負うのか。エージェントがデータベースを破損させたり、ネットワーク外へデータを転送したりした場合、責任をエンジニアリングのフレームワークや汎用のソフトウェアライブラリに負わせることはできません。業務プロセスの責任者が、リスクプロファイルを明確に自らの責任として引き受ける必要があります。
-
エージェントのログ： インシデント発生後に、エージェントのAPI呼び出しを再現できるか。標準的なクラウドログは、システムの動作を示すだけで、業務上の文脈が十分ではありません。セキュリティチームには、プロンプト入力、ツール呼び出し、モデル出力、ポリシー判断、下流のAPI実行を捕捉するテレメトリが必要です。その際は、機密データを保護するため、適切な保持期間とマスキングを設けます。
-
エージェントのレビュー： こうした自律的なIDに対して、定期的なアクセス権の認定レビューを実施しているか。正式な権限レビューとガバナンスの仕組みがなければ、エージェントはすぐに監視されないゾンビアカウントと化します。開発プロジェクトが放棄されたり、基盤のシステムプラットフォームが廃止されたりした後も、残り続けてしまいます。
-
エージェントの封じ込め： 帯域外の封じ込め手段はあるか。セキュリティ基盤は、重要なシステム依存関係を不安定にしたり、企業アーキテクチャ全体で下流の業務停止を引き起こしたりすることなく、自律型エージェントを素早く隔離または無効化できなければなりません。
人間の特権ユーザーに今日適用しているのと同じ基本的な規律で、AIエージェントを監査・統制しなければ、脅威アクターは明日、それらを自動化された内部脅威として悪用するかもしれません。エージェントを特権IDとして扱うのは、後からではなく、今からです。この規律を今日のうちに築いた組織は、インシデントレポートを書かなければならなくなったときに、はるかに強い立場に立てるでしょう。
