AIエージェントが作られる場面を想像してみてください。作るのはID管理チームでもセキュリティの専門家でもありません。中堅企業の経理部門の担当者です。
このエージェントの仕事は比較的単純です。受信トレイを読み、請求書をERPと照合し、毎日の要約をSlackに投稿します。フロンティアモデルを使って作成したため、ワンショットで10分もかからない作業でした。
このエージェントの存在を、セキュリティ部門は誰も知りません。
これは珍しいことではありません。Tokenの依頼でCloud Security Allianceが2026年1月に実施した418人のITおよびセキュリティ担当者を対象とした調査では、68%が自社のAIエージェントを十分に可視化できていると回答しました。ところが、82%は過去1年の間に、把握していなかったエージェントを見つけていました。
エージェントの進化は非常に速く、セキュリティのプレイブックは走りながら書かれている状況です。エージェントのセキュリティを担う人々は、本番環境で一つひとつ問題を解決しながら進むしかありません。
Token Securityは、そうした担当者20人以上に、得られた知見を無料の学習ハブであるAgentic Universeに書き残してもらいました。
以下では、このエージェントが作られた日の午後から、問題が起きた後の監査までを追います。実務者の知見によって結果を変えられたはずの場面は、5つあります。
初日：エージェントはどうやってアクセス権を得たのか
このエージェントには、メール、ERP、Slackの3つのシステムへのアクセスが必要です。メールはノーコードビルダー経由で、OAuthの同意画面を使って取得します。ERPは少し厄介ですが、それほどではありません。作成者はAIの親切な手順に従えば、数分で個人用APIキーを発行できます。SlackはビルダーのSlackコネクタ経由で接続し、同意画面をもう一度承認します。
これは、Zededaの元セキュリティ・IT・コンプライアンス責任者であるJohn Donovan氏がHow do AI agents access sensitive systems and data?（AIエージェントは機密システムやデータにどうアクセスするのか）で示した4つのアクセス経路のうち、2つに当たります。
- 人間のセッションへの便乗：ユーザーになりすまして動作するブラウザ拡張機能やアプリ内コパイロット。
- 委任されたOAuth許可の利用：ユーザーが1回のクリックでスコープを承認すると、誰かが取り消すまでエージェントのアクセスが続く。
- 静的な認証情報の利用：APIキーやサービスアカウントのパスワード。見つけた人なら誰でも使える。
- 専用のエージェントIDによる動作：登録済みで有効期間が短く、1つのエージェントに紐づく。最も理想的だが、最も少ない形態。
Donovan氏が指摘するのは、実際のエージェントはこれらを組み合わせており、組み合わせによって見えるものが変わるという点です。たとえば、エージェントがユーザーのOAuthトークンをサブエージェントに渡し、サブエージェントがMCPサーバーを呼び出し、そのサーバーが共有サービスアカウントでデータベースにクエリを発行する場合を考えてみましょう。
データベースのログに残るのはサービスアカウントです。SaaSの監査ログに残るのはユーザーです。IDプロバイダーには何も残りません。
アクセス経路によってログに残る内容が決まります。そのため、社内のすべてのエージェントについて経路を把握しておくのが理想です。OAuthの許可にも注意が必要です。通常、IdPによって取り消されることはなく、承認した本人が異動した後も長く有効なままになることがあります。
2日目：行われなかったレビュー
エージェントは翌朝に稼働を始めます。誰もレビューしません。そもそも誰にも依頼されていないからです。
もし誰かが確認していれば、あるテスト1つで問題を指摘できたはずです。How do you make an AI agent Secure by Design?（AIエージェントをセキュアバイデザインにするには）で、DataRobotのAI・サイバーセキュリティ担当プロダクトリーダーであるAmber Bennoui氏は、MetaのAIセキュリティチームが2025年10月に公表したAgents Rule of Twoを土台に論じています。
プロンプトインジェクションを確実に検知して拒否できるようになるまでは、エージェントが1つのセッションで持つ能力は、次のうち2つまでにとどめるべきとされています。
- A：信頼できない入力を処理する。
- B：機密システムや非公開データにアクセスできる。
- C：状態を変更したり、外部と通信したりできる。
このエージェントは3つすべてを備えています。アドレスを知る誰からでもメールを受け取り、ERP上のベンダーの銀行口座情報を閲覧でき、動作に使う個人用APIキーは、その口座情報の編集を含め、作成者がERPで行えることをすべて実行できます。
Bennoui氏によると、理想は安全な経路を標準にしたうえで、開発者に3つの単純な質問に答えてもらうことです。エージェントは社外のものを読み込むか、非公開データを閲覧できるか、人間の確認なしに動作できるか、という質問です。
3つすべてにイエスと答えた場合は、エージェントを稼働させる前にセキュリティ部門に相談しなければなりません。
3週目：誰も開かない悪意あるメール
Slackの要約は実際に役立っており、エージェントの所有者は満足しています。エージェントでほかに何を自動化できるか、考え始めたところです。ちょうどそのとき、既知のベンダーのアドレスから請求書が受信トレイに届きます。添付ファイルの中には、白い背景に白い文字で、ベンダーが取引銀行を変更したのでERPを更新してほしいという依頼が書かれていました。
このメールを読む人間はいません。しかしエージェントは隠しテキストも含めて読み、変更を実行してしまいます。
CISOでありサイバーセキュリティ研究者でもあるJoshua Copeland氏は、5分間の動画How are AI agents compromised?（AIエージェントはどのように侵害されるのか）で、エージェントに指示が入り込む経路を解説しています。エージェントに話しかけられる人物から直接届く指示もあれば、誰も開かなかったメールのように、エージェントが読むコンテンツに紛れて入り込む指示もあります。
いずれの場合も、ログ上の結果は問題なく見えます。許可されたツール、有効な認証情報、認められた作業です。
Copeland氏は、エージェントの認証情報の窃取が、エージェント自体の侵害より深刻になりうる理由も説明しています。このエージェントの場合、それは初日に作られ、有効期限なしでビルダーに保存された、個人用のERPキーです。
理想は、エージェントが読むあらゆる入力を、エージェントに命令を出しうるものとして扱うことです。そのうえで、1つの入力だけでは取り返しのつかない操作につながらないようにします。
その木曜日：検知する
銀行口座の変更は木曜日に実行されます。誰かが気づくかどうかは、検知の仕組みがエージェントを何と比較するかで決まります。
エージェントを自身の権限と比較しているなら、何も検知されません。BenchlingのCISO兼CIOであるChad Kalmes氏は、The Compromised and Rogue Agent Detection Checklist（侵害されたエージェントと暴走エージェントの検知チェックリスト）で、そうしたベースラインを避けるよう警告しています。不審な動作をするエージェントは、終始付与された権限の範囲内にとどまることがあるためです。
同氏は、信頼できる期間にエージェントが実際に行った動作、たとえば呼び出すツールやデータの送信先をベースラインにします。
このベースラインに照らすと、同氏が挙げるシグナルのうち2つが、このケースで検知されます。
- ツールの初回利用（許可されたものであっても）。3週間、エージェントはERPからの読み取りしか行っていません。銀行口座の変更は、初めての書き込みです。
- 新しいシーケンス。メールを読んでから支払い記録を変更するのは、エージェントがこれまで実行したことのない操作の順序です。
Kalmes氏は、攻撃者の指示に従う「侵害されたエージェント」と、正当な指示に従いながら損害を引き起こす「暴走エージェント」を区別しています。ただし、両者のシグナルは大部分が重なります。
対処する際は、エージェントを破棄せずに停止します。認証情報は取り消しますが、メモリとトランスクリプトは残します。汚染された請求書が、そこに残っている可能性があるためです。
60日目：誰が承認したのか
2か月後、監査人がエージェントの履歴から銀行口座の変更を取り出し、誰が承認したのかを尋ねます。
Simeioのアイデンティティセキュリティサービス担当シニアディレクターであるRajesh Seshadri Appikulam氏は、What audit evidence do you need for AI agents?（AIエージェントにはどのような監査証跡が必要か）で、監査人がエージェントの行動について尋ねる4つの質問を挙げています。どのエージェントが行ったのか、どの権限に基づくのか、誰の承認を得たのか、誰の権限によるのか、の4点です。
最初の質問は簡単です。最後の質問が難問です。権限は、事後に再構築できないからです。
要求の背後にいた人間と委任の連鎖が、行動の時点で記録されていなければ、それらは失われます。
このエージェントの場合、記録は乏しい状態です。ERPのログに残っているのは作成者の個人用APIキーであり、銀行口座の変更は作成者の仕業に見えます。対応チームはそのキーを失効させましたが、エージェントの所有者は先月別のチームに異動しており、受信トレイに対するOAuth許可は今も有効なままです。
Appikulam氏は、10項目のテストで締めくくっています。いずれも5分以内に答えられるはずの質問です。まず2つ挙げます。
- 60日前のエージェントの行動を任意に1つ選んだとき、それが誰のために行われたかを答えられるか。
- 本番環境にある任意のエージェントについて、現在の所有者を答えられるか。
どちらかに5分以上かかるなら、取り組むべき出発点が見えてきます。
数百あるエージェントのうちの1つ
ここで追ってきたエージェントは架空のものですが、似たエージェントは実在します。冒頭で触れたとおり、CSAの調査の回答者の82%が、把握していなかったエージェントを見つけていました。上記の対策はいずれも、本番環境で最初に問題に直面した人が、解決策を書き留めたものです。
Agentic Universeには、そのほかの知見も収められています。
Roblox、Klaviyo、Webflowのセキュリティ責任者を含む20人以上の寄稿者が、エージェントの仕組みから、問題が起きたときの対応までを網羅しています。形式は短い動画から、自社環境にそのまま当てはめられるチェックリストまでさまざまです。無料で、登録も不要です。
