
過去20年の大半において、企業のセキュリティは「環境は把握可能である」という実用的な前提に基づいて運用されてきました。セキュリティチームはツールを導入し、ユーザーを管理し、システムをマッピングし、ポリシーを定義し、ベンダーが構築したダッシュボードやワークフローを活用することで、その後発生する事態の大部分を管理することができました。
このモデルは不完全ではあったものの、環境の変化が人間の対応速度の範囲内にとどまっていたため、機能していた。
AIエージェントは、その前提を打ち破り、それとともに従来の対応マニュアルも無効にしてしまいました。
エージェントは通常のアプリケーションとは異なります。自律的に動作し、ツールを起動し、システム間でアクセス権を取得し、状況に応じて挙動を変えます。承認されたものはSaaSプラットフォーム上で実行されますが、承認されていないものはローカルで実行されます。また、人間のアクセス権を借りて動作し、次回のインベントリスキャンが行われる前に姿を消すこともあります。
また、エージェントが到達できる範囲も極めて多様です。企業が実際にエージェントをどのように展開しているかに関するToken Securityの調査によると、人間が起動するチャットボットから自律的な本番サービスまであらゆるものが確認されており、ローカルエージェントの5分の1以上がすでに本番データソースへの直接アクセス権を保持していることが判明しました。
サイバーセキュリティにおける「自社開発か購入か」という議論は、今や根本的に変化しています。従来の問いは単純でした。「ツールを購入すべきか、それとも自社で開発すべきか?」というものです。しかし、エージェント時代において、この枠組みは狭すぎます。
セキュリティチームはスタック全体を再構築する必要はありませんが、数ヶ月前に他者が作成した固定のワークフローに依存することもできません。
より適切な問いは、「セキュリティチームはどのレイヤーを自ら管理すべきか」ということです。
固定的なセキュリティワークフローの限界
AIエージェントは、環境をより特化させ、より動的にし、予測を困難にします。ベンダーは、権限が過剰なサービスアカウント、期限切れの認証情報、休眠中の管理者ユーザー、過剰な権限、本番システムへのアクセス権を持つIDなど、一般的なリスクに対応するダッシュボードを構築できます。
これは有用ですが、最も重要な課題は往々にして個々の環境に特有のものなのです。
- 過去2週間に作成されたエージェントのうち、人間から継承された認証情報を通じて本番環境にアクセスできるものはどれか?
- プロジェクト終了後も、どのローカルコーディングエージェントが有効なトークンを保持しているか?
- AIエージェントを介して、あるシステムから別のシステムへ至る潜在的な攻撃経路は何か?
これらの問いは、汎用的なワークフローにはすんなりとは当てはまりません。これらは、組織のクラウド利用状況、SaaSスタック、開発慣行、所有権モデル、コンプライアンス要件、そしてAIの導入パターンに依存します。あらゆる組み合わせを予測できるベンダーのロードマップなど存在しません。
これこそが「運用化のギャップ」です。セキュリティチームはリスクのカテゴリーを特定できることが多くても、それを自組織の環境に必要な正確な是正策へと常に変換できるとは限りません。AIエージェントは、従来のツールのライフサイクルよりも迅速に動作するため、このギャップをさらに広げてしまいます。
エージェントがアクセス権限を蓄積し続ける中、ベンダーの機能実装を2四半期も待つことは、効果的なセキュリティ戦略とは言えません。それは単なる待ち行列に過ぎないのです。
スピードを落とさずにAIを安全に運用する
シャドウAIやエージェントの無秩序な拡大は、セキュリティチームがそれらに対処できる能力を上回るペースで進行しています。
Token Securityは、すべてのエージェントを検出し、リスクのあるアクセスを可視化し、意図ベースのポリシーを自動的に適用します。制御を失うことなく、イノベーションのスピードを落とすことなく、AIを安全に拡張できます。
なぜ「とにかく作ればいい」という考え方は正解ではないのか
AIを活用した開発は、チームが構築できるものの範囲を一変させました。Retoolの「2026年 Build vs. Buy」レポートによると、35%のチームがすでに少なくとも1つのSaaSツールを自社開発のツールに置き換えており、78%が今年さらに多くのツールを自社開発する見込みであることが明らかになりました。
AIによってカスタムツールの構築がはるかに迅速かつ容易になったため、この傾向はセキュリティ面でも重大な影響を及ぼしています。かつては数週間のエンジニアリング作業を要していた作業も、今では数時間でプロトタイプを作成できるようになりました。
しかし、サイバーセキュリティには、他の多くの業務機能よりも困難な課題があります。それは「データ層」です。有用なセキュリティワークフローの有効性は、その基盤となるID、アクセス、権限、所有権、およびアクティビティデータの質に左右されます。カスタムアプリを構築することと、それを稼働中のエンタープライズシステムに安全に接続することは、別問題なのです。
セキュリティチームは、AWS、Azure、GitHub、Salesforce、Okta、シークレットマネージャー、CI/CDパイプライン、SaaSプラットフォーム、エージェントフレームワーク、オンプレミスシステムにまたがる統合を、いちいち再構築する必要はないはずです。
また、すべてのスキーマを自ら正規化したり、上流のAPIが変更されただけで動作しなくなる脆弱なスクリプトを維持したりする必要もありません。
これこそが、「ただ構築すればいい」という考え方に伴う隠れたコストです。難しいのはコードを生成することではなく、実際の意思決定を支えるのに十分なほど、稼働中であり、正規化され、安全で、完全なデータに基づいて構築することです。
基盤を購入して運用層を掌握する
サイバーセキュリティの未来は、純粋な「構築」でも純粋な「購入」でもありません。それは、適切な基盤の上に構築することにあります。
セキュリティチームは、構造的に複雑で組織全体に広く採用されているレイヤー——継続的な検出、統合、正規化、IDの相関分析、アクセスマッピング、ガバナンス制御、監査可能性、およびセキュアな実行境界——に投資すべきです。
これらの機能には、深み、規模、そして継続的なメンテナンスが必要です。これらは、ほとんどのセキュリティチームが限られたエンジニアリングリソースを費やすべき領域ではありません。
しかし、チームは運用レイヤー――つまり、自組織の特定の環境を反映したワークフロー、アプリケーション、レポート、レビュー、自動化――を自ら管理すべきです。
そこにこそ差別化の要素があります。セキュリティチームは、組織が実際にどのように機能しているかをそこに組み込むのです。具体的には、誰がどのエージェントを管理しているか、どのシステムが最も重要か、どのようなアクセスが許容されるか、どのような例外が認められるか、リスクはどのように優先順位付けされるか、そして次にどのような是正措置を講じるべきか、といった点です。
成功するモデルは、「すべてを購入する」でも「すべてを構築する」でもありません。「基盤を購入し、運用層を構築する」ことです。
アイデンティティは、その基盤となる層です
AIエージェントにとって、基盤となるのはアイデンティティでなければなりません。意味のあるエージェントは、いずれアクセスが必要になります。エージェントは認証を行い、認証情報を使用し、ツールを呼び出し、データにアクセスします。
多くの場合、エージェント自身に固有のアイデンティティすら持たず、代わりに従業員からアイデンティティを借りています。そのため、企業内で既に稼働しているエージェントは、監査ログ上では、そのエージェントがなりすましている人物と見分けがつかないことがあります。
だからこそ、アイデンティティこそがエージェント型AIを実際に統制する唯一のコントロールプレーンであり、構築の基盤となるのです。こここそが、チームがすべてのエージェントの検出、所有権、アクセス権、ライフサイクルを一括して把握し、適用できる唯一の場所なのです。
ガードレール、プロンプトフィルタリング、および行動制御は、エージェントの発言に対して作用します。アイデンティティはエージェントがアクセスできる範囲を管理し、そのアクセス範囲こそが影響範囲を決定づけるのです。
動的なアイデンティティ基盤は、セキュリティチームに、重要な質問を投げかけ、それに答えるために必要なコンテキストを提供します:
- このエージェントの所有者は誰か?
- このエージェントは何をすべきなのか?
- どのアイデンティティを使用しているか?
- どのシステムにアクセスできるのか?
- そのアクセス権限は本来の意図と一致しているか?
- このエージェントが放棄されたり、侵害されたり、変更されたりした場合はどうなるのか?
その基盤がなければ、カスタムワークフローは砂上の楼閣に過ぎません。それらは、古いエクスポートデータ、不完全なインベントリ、そしてその場限りのスクリプトに依存しているからです。
この基盤があれば、セキュリティチームは、エージェントが出現、変更、消失しても、実際の環境と常に連携した運用ロジックを構築できます。
効果を維持し続けるチーム
予測可能な環境向けに構築されたセキュリティ・プレイブックが復活することはありません。AIエージェントがそれを確実なものにしました。次のプレイブックは、より適応性の高いものです。
それは、環境が変化し続けることを前提としています。また、どのベンダーもすべてのワークフローを事前に構築することはできないと想定しています。さらに、セキュリティチームには、自らの現実に合った制御、レポート、レビュー、および是正措置の経路を組み立てる能力が必要であると想定しています。
しかし、チームが基盤を自ら一から構築すべきではないことも認識しています。先を行くチームとは、ツールのリストが最も長いチームでも、最も汎用的なダッシュボードを持つチームでもありません。どのレイヤーを自ら管理すべきかを知っているチームこそが、先を行くのです。
エージェント型AIの場合、答えは明確です。ライブID基盤の上に構築し、適応が求められる運用レイヤーを管理するのです。エージェント時代において、これこそがセキュリティチームが制御を失うことなく迅速に動くための方法です。
エージェント型AIのセキュリティ対策をお考えの方は、Token Securityの簡易テクニカルデモをご予約ください。組織の規模拡大に伴い、どのようにセキュリティを確保できるかをご確認いただけます。
本記事はToken Securityによる提供・執筆です。
出典:https://www.bleepingcomputer.com/news/security/ai-agents-broke-the-security-playbook-heres-what-replaces-it/



Comments