7月16日、Token Securityが「AI Agents Broke the Security Playbook. Here's What Replaces It.」と題した記事を公開した。AIエージェントの台頭によって従来のセキュリティ設計が機能しなくなった理由と、それに代わる新しいアプローチについて詳しく論じている。

アイデンティティが唯一の制御面——なぜそれが問題なのか

AIエージェントの文脈において、その基盤となるのはアイデンティティだ。あらゆるエージェントは最終的にアクセスを必要とし、認証を行い、認証情報を使い、ツールを呼び出し、データに到達する。

問題は、多くのエージェントが独自のアイデンティティを持たず、従業員のアイデンティティを借用する点だ。これにより監査ログ上でエージェントと人間が区別できなくなる。

プロンプトフィルタリングや行動制御は「エージェントが何を言うか」に作用するが、アイデンティティ制御は「エージェントが何に到達できるか」を規定する。到達範囲が爆発半径（Blast Radius）を決める以上、アイデンティティが唯一の実効的なコントロールプレーンになる。

この論点はセキュリティコミュニティでも共有されており、OWASP LLM Top 10ではエージェントの過剰権限（Excessive Agency）や不適切な認可を主要リスクとして挙げている。また、NISTのAI Risk Management Framework（AI RMF）もAIシステムのガバナンスとアクセス制御を重点領域として位置づけている。

「環境が把握可能である」という前提が崩れた

過去20年間、エンタープライズセキュリティはある前提の上に成り立っていた。「環境は把握できる」というものだ。ツールを導入し、ユーザーをインベントリし、システムをマッピングし、ポリシーを定義する。変化は人間のスピードで起きていたため、このモデルは機能した。

AIエージェントはその前提を破壊した。

エージェントは通常のアプリケーションではない。自律的に動作し、ツールを呼び出し、複数のシステムにわたってアクセスを取得し、コンテキストに応じて挙動を変える。SaaSプラットフォーム上で動くものもあれば、ローカルで動く非公式なものもある。人間のアクセス権を借用し、次のインベントリスキャンが来る前に消えることもある。

Token Securityの調査によれば、企業内のエージェントは人間が手動で起動するチャットボットから完全自律型の本番サービスまで多岐にわたり、ローカルエージェントの5分の1以上がすでに本番データソースへの直接アクセスを保有しているという。

固定ワークフローの限界：「ベンダーが作ったダッシュボード」では足りない

既製のセキュリティツールは、よくある脅威パターン（過剰権限のサービスアカウント、古い認証情報、休眠中の管理者ユーザーなど）を扱うダッシュボードを提供する。それ自体は有用だが、本当に重要な問いは環境固有のものになる。

• 過去2週間に作成されたエージェントのうち、人間の認証情報を継承して本番環境にアクセスできるものはどれか？
• プロジェクト終了後も有効なトークンを保持したままのローカルコーディングエージェントはどれか？
• AIエージェントを経由して、あるシステムから別のシステムへの攻撃パスはどのようなものか？

これらの問いは、組織ごとのクラウド構成、SaaSスタック、開発プラクティス、コンプライアンス要件によって変わる。どのベンダーのロードマップも、すべての組み合わせを先回りできない。

記事ではこのギャップを「オペレーショナライゼーションギャップ（operationalization gap）」と呼ぶ。リスクのカテゴリは特定できても、自分たちの環境に合った具体的な対処パスに落とし込めない状態を指す。エージェントは従来のツール更新サイクルより速く動くため、このギャップはさらに広がる。

「全部自分で作る」も正解ではない

Retoolの2026年版 Build vs. Buy レポートによれば、35%のチームがすでに少なくとも1つのSaaSツールを自社開発ツールに置き換えており、78%が今年さらに多くを内製化する予定だと回答している。AIによってプロトタイプ開発が数時間でできるようになった今、この傾向は加速している。

しかしセキュリティ領域には特有の難しさがある。データ層の問題だ。

有用なセキュリティワークフローは、その下にあるアイデンティティ・アクセス・権限・オーナーシップ・アクティビティのデータと同程度にしか機能しない。カスタムアプリを作ること自体は難しくない。それをAWS、Azure、GitHub、Salesforce、Okta、シークレットマネージャー、CI/CDパイプライン、各種SaaSプラットフォーム、エージェントフレームワーク、オンプレシステムに安全につなぐことが本当の難所だ。

上流APIが変更されるたびに壊れる脆弱なスクリプトをメンテし続けるコストは見えにくい。「自分で作ればいい」の隠れたコストはコード生成ではなく、リアルタイムで正規化・完全な状態を保つデータ基盤の構築にある。

答えは「基盤を買い、運用レイヤーを自分で作る」

記事が提示する結論はシンプルだ。

「Buy the foundation, build the operating layer（基盤は買い、運用レイヤーは作る）」

継続的な検出、インテグレーション、スキーマ正規化、アイデンティティ相関、アクセスマッピング、ガバナンス制御といった構造的に複雑な基盤部分は、購入すべき対象だ。スケールと深度が必要で、常時メンテナンスが求められる。セキュリティチームの限られたエンジニアリングリソースをここに割くべきではない。

一方で「どのエージェントが誰のもので、何にアクセスしてよいか、例外はどこか、リメディエーションは何をすべきか」という組織固有のロジックは、チームが自分で所有・構築すべき運用レイヤーだ。

ライブなアイデンティティ基盤があれば、次の問いに継続的に答え続けられる。

• このエージェントのオーナーは誰か？
• 何をするためのものか？
• どのアイデンティティを使っているか？
• どのシステムに到達できるか？
• そのアクセスは意図と一致しているか？
• 放棄・侵害・変更された場合どうなるか？

この基盤なしには、どんなカスタムワークフローも古いエクスポートや断片的なインベントリの上に立つ砂上の楼閣に過ぎない。

詳細はAI Agents Broke the Security Playbook. Here's What Replaces It.を参照していただきたい。