新たな特権アイデンティ：AI エージェントとセキュリティの大きな課題

Your Newest Privileged Identity Is An AI Agent

2026/09/11 SecurityBoulevard — AI エージェントは、生産性向上ツールとして紹介されることが多いが、セキュリティの観点から見るなら、その説明だけでは不十分である。人間とは異なる主体として、認証情報の保持／信頼できないデータの読み取り／ツールの呼び出し／複数システム間の移動などをマシンスピードで実行する。こうした特性の組み合わせが AI エージェントを有用なものにしている。それと同時に、その影響範囲を把握する上で重要な単位となるのは、ネットワーク境界ではなく ID である。しかし、AI エージェントの導入状況を見ると、セキュリティ・チームにとって、これを将来のアーキテクチャ上の問題として扱う余裕はない。

Techstrong の特別レポート The Great Unification で引用された Okta の調査によると、すでに 91% の組織が AI エージェントを使用しているが、人間ではない ID に対する十分に整備された戦略を持つ組織は 10% に留まる。Cloud Security Alliance の調査では、68% の組織が自社環境における AI エージェントの活動と人間の活動を確実に区別できていないことが明らかになった。

AI エージェントと人間を区別できない監査証跡は、インシデント発生後に説明責任を果たせるものとは言い難い。

サービス・アカウントは AI エージェントの ID 戦略にはならない

長年にわたってマシンによるアクセスを管理してきた企業は、既存のサービス・アカウント・モデルに AI エージェントを組み込むことが自然に思えるだろう。しかし、この方法では、いくつかの重要な違いを見落とすことになる。一般的に見て、従来のサービス・アカウントは、範囲が限定されたアプリケーションと既知の呼び出し処理を支えるものだ。

その一方で、AI エージェントには、使用するツールの選択／実行時の処理経路の組み立て／読み取ったデータに含まれる指示への反応といった役割がある。したがって、1 つのタスクを実行する間に、課題管理システム／ソースリポジトリ／クラウドコンソール／可観測性システム／導入プラットフォームなどを横断する。その処理の経路自体は正当なものであっても、必ずしも事前に決められているとは限らない。

そのため、セキュリティで把握する必要があるのは、どの AI エージェントが操作したのか／誰の代理として操作したのか／宣言されたタスクは何だったのか／どのモデルとツール群を使用したのか／どの承認状態で操作したのかといった情報である。

認証情報については有効期間を短くし、その操作に必要な範囲へ限定する必要がある。それに加えて、ユーザーの認証情報の借用や、共有アカウントの背後への隠蔽などは行うべきではない。ツールへのアクセス権限も明示的に設定する必要があり、重大な結果をもたらす操作には、巧妙なプロンプトでも迂回できない確認ポイントが必要となる。

機械的な処理速度により、リスクの深刻さも変化する。過剰な権限を持つ人間の場合、ミスが発見されるまでに操作するシステムは数個かもしれない。しかし、AI エージェントの場合には、到達可能な全対象に対して、同じ権限を網羅的に行使できる。最小権限は単なるコンプライアンス上の標語ではなく、被害の拡大速度を制限する仕組みとなる。

プロンプト・インジェクションは ID と認可の問題

プロンプト・インジェクションは、特殊な入力検証の不備であるかのように論じられることが多い。しかし、セキュリティの観点で重要な問題は、侵害された AI エージェントや、誤った判断へ誘導された AI エージェントが、その後に何を実行するのかという点である。いずれは悪意の指示を読み取る AI エージェントであるため、完全なフィルタリングを主要な防御策とする考え方は現実的ではない。

外部からの影響を前提とするシステムでは、AI エージェントが実行する操作を制限する必要がある。強固な ID 管理／範囲を限定した権限／データの外部送信に対する制御／ツールの許可リスト／機密性の高い操作に対する独立した承認により、不適切な指示による影響を軽減できる。

そのため、AI エージェントのセキュリティは、プラットフォームと同一のアーキテクチャの中で扱われる必要がある。内部開発者向けプラットフォームは、AI エージェントが利用するエンドポイント／実行環境／ゲートウェイ／配信経路を制御する。セキュリティ部門がポリシーを定義するが、そのポリシーを実際に適用できる仕組みを提供するのはプラットフォームである。

現在のガバナンスには大きな隔たりがある。Futurum の調査では、AI エージェントのガバナンス成熟度はわずか 18.1% であり、DevSecOps の 46.1% を大幅に下回っている。より成熟している DevSecOps の基盤が重要になるのは、このためである。

組織にとって、完全に独立した MLSecOps のサイロを構築する必要はない。必要なのは、既存のサプライチェーン／ID／Policy as Code／リリース管理の仕組みを、新たな成果物と新たな主体へ拡張することである。

防御側の導入は攻撃対象領域の拡大より遅れている

2026年の Dark Reading の調査で、セキュリティ専門家の 48% が挙げているのは、Agentic AI が最大の攻撃経路となっている点である。Okta の報告では、CISO の 81% が AI に過剰なアクセス権限が付与されることを懸念しているが、許容可能な AI リスクについて取締役会と完全に認識が一致していると回答した割合は 31% に留まった。

同時に、セキュリティ・スキャンにおける AI の利用率はわずか 12.4% であり、Futurum の調査ではソフトウェア・ライフサイクルの各段階の中でも特に低い導入率となっている。これは、セキュリティ・チームが AI を無視していることを意味するものではない。自動化によって誤った安心感を持つことが大きな損失につながり得る分野では、慎重な姿勢は合理的である。しかし、防御対象となる領域は、多くの防御手法の変化よりも速い速度で拡大している。

解決策は、すべてのセキュリティ判断を自動化することではなく、重要な境界では人間の権限を維持しながら、可視性／封じ込めの能力を向上させる部分に自動化を利用することである。AI エージェントは、テレメトリの相関分析／定型的なアラートの調査／修正策の提案を行うことができる。しかし、範囲を限定した ID や検証可能な一連の承認手続きがない状態で、広範な修正を実行する権限まで AI エージェントに付与することは、まったく別の判断となる。

監査ログで回答できなければならないこと

実用的な AI エージェントのセキュリティ対策は、問題が発生した後に組織が必要とする証拠を明確にすることから始まる。

誰が、何が、タスクを開始したのか？どの AI エージェントのインスタンスが各操作を実行したのか？どのデータが判断に影響したのか？どのツールと認証情報を利用できる状態だったのか？何が変更されたのか？どのような人間による承認が必要で、実際に取得されたのか？操作を元に戻すことは可能か？無関係な処理を停止することなく認証情報を失効させられるか？

現在のプラットフォームで、これらの問いに回答できないのであれば、その組織には AI ポリシーの不足以前に、可観測性／ID 管理の不足が存在する。

Agentic AI により、セキュリティは広範な運用変革の一部となる。AI は保護のために必要な処理環境であると同時に、その行動を統制する必要がある働き手でもある。プラットフォーム・エンジニアリング／DevOps／セキュリティは、それぞれの責任範囲を維持しながらも、同じ制御の仕組みを共有することになる。

The Great Unification は、人間ではない ID の問題／ガバナンスに関するデータ／プラットフォームモデル／移行を頓挫させる可能性が残る未解決のリスクなど、ソフトウェア・スタック全体におけるこうした統合について解説している。

AI エージェントの普及に伴い、人間以外のアクセス権限に関する設定不備やガバナンスの遅れが深刻な問題となっています。従来の管理手法の流用では、不適切なプロンプト指示への反応／想定外の自動操作／権限の過剰行使といった事象を引き起こし、組織全体への被害拡大に繋がります。影響を抑制するため、操作権限の最小化／有効期間の短縮／短時間での認証情報更新／ツールの明示的な許可設定／機密操作への人間の承認手続き追加が有効です。Okta や Dark Reading などの報告でも指摘される通り、可視性の確保と適切な ID 統制を通じた迅速な対応体制構築が重要となります。開発プラットフォームと連携した継続的な監視と検証プロセスの統合が強く求められます。