9月26日、Ismael Valenzuelaが「Zero Trust for AI Agents Starts With Fixing Zero Visibility」と題した記事を公開した。ある従業員が個人環境で動かしていたAIエージェントアプリが攻撃者に悪用され、60万ドル相当のトークンが3週間にわたって消費され続けた——にもかかわらず誰も気づかなかった。この事例を起点に、記事はAIエージェントへのZero Trust適用において「可視性の確保」が最初の一手でなければならない理由を論じている。

60万ドルのトークンを消費された実被害事例

AIエージェントの評価を専門とする非営利組織METRで実際に起きたインシデントだ。ある従業員が個人のEC2インスタンス上で「ノリと勢いで（vibe-coded）」作ったエージェントアプリを稼働させていた。「vibe coding」とは、設計や仕様を厳密に定めずAIの補完に乗りながら直感的にコードを書き進めるスタイルで、近年急速に広まっている開発手法だ。セキュリティレビューが省かれやすく、属人的な運用になりがちという側面を持つ。

攻撃者はこのアプリを発見し、認証をあっさり突破してエージェントにモデルプロバイダーのAPIキーを吐き出させた。

その後3週間にわたり、攻撃者はAPIキーを使い続けた。被害額は60万ドル相当のトークン消費。なぜ誰も気づかなかったかといえば、METRの内部ダッシュボードがレート制限されたリクエストのデータを表示しない仕様だったためだ。トークン消費量だけでは何もアラートが上がらなかった。

これは「AIエージェントが見えていない状態で運用されると何が起きるか」を端的に示している。

「見えないものは守れない」——なぜ可視性が先か

SANSのチートシート「Zero Trust for AI Agents: The Security Checklist」の冒頭原則は「You cannot govern what you cannot see（見えないものは統治できない）」だ。

現実はどうか。Veeamの調査によれば、70%の組織がAIワークフローは完全な監視なしにすでに機密データに触れていると認めており、67%はITが従業員の構築した自律ワークフローを完全に追跡できていないと報告している。

多くの組織はポリシー適用層や認可スキームを先に実装しようとするが、インベントリ（台帳）なしで作られたプロキシや認可レイヤーは、実態のない対象に対して何も強制できない。記事はこの「操作の順序の誤り」をZero Trustプログラムが失敗する根本原因と指摘する。

3つの可視性の課題

課題1：AIエージェントは新種のシャドーIT

新技術は常に「導入が先、ガバナンスは後」になる。前述のMETRの事例はこの典型で、従業員が個人インスタンスで動かしたエージェントは組織のどの台帳にも載っていなかった。

防御側の対策として、クラウド費用の管理と同様の発想をAIに適用することが提案されている。AWS/Azureの利用状況を監視するように、AIとエージェントの支出、APIキーの発行状況を発見シグナルとして扱うこと。財務・調達部門も見落とされがちな観測点になりうる。また何かをブロックする前に、まず承認済みプロバイダーへの正規ルートを公開し、「知ってから制限する」順序を守ることが推奨されている。

課題2：単一の監視手段では全体像が見えない

エージェントはネットワーク、エンドポイント、ブラウザ、SaaS上と分散して存在する。AIプロバイダーへのトラフィックはTLS暗号化されており、インラインセンサーには宛先とバイト数しか見えない。エンドポイントツールはブラウザ組み込みのAIを検知できず、SaaS内蔵のAIはその両方から見えない。

対策は複数ソースの相関だ。具体的には以下を組み合わせる：

• ネットワーク：DNS/SNI、JA4フィンガープリント、エグレスプロキシログ
• エンドポイント：プロセス、環境変数内のAPIキー、ローカルエージェントランタイム
• ブラウザ：拡張機能、インページコパイロット、エンタープライズブラウザログ
• ID・SaaS：OAuthグラント、APIキー発行記録、プロバイダー管理コンソール

LiteLLMのようなLLMゲートウェイは可視性とガバナンスを集中化できるが、すでに把握しているエージェントしか制御できないという根本的な制約がある。未知のエージェントは発見できない。

課題3：監査サイクルが監査対象に追いつかない

エージェントは秒単位でデプロイ・クローン化される。年次レビューが終わるころには、そのインベントリはすでに陳腐化している。

攻撃者はこの隙を突ける。侵害済みのエージェントに短命クローンを生成させ、各クローンが親のアクセス権を引き継いでデータを窃取し、定期レビューが行われる前に消滅するという手口が想定される。

対策としては、人間がエージェントを監視しつつ、エージェント同士が互いを監視する多層構造が提案されている。ただし「自動化されたシステムが自動化されたシステムを監視する」場合も、結果に責任を持つ担当者を明示的に設定することが前提となる。

カリフォルニア州知事が緊急シャットオフの行政命令を発令するなど、AIのキルスイッチを法的に整備する動きも出始めている。だが記事はこう釘を刺す。「何をオフにするかを知らなければ、キルスイッチは意味をなさない」。

エージェントには独立したIDを与えよ

記事はSubstackのThe Monday Briefでの言及を引いて、エージェントのIDについて重要な設計原則を述べている。

「エージェントのツールアクセスは、それを展開したユーザーの拡張としてではなく、独立したIDとポリシー強制の問題としてモデル化されなければならない。すべてのエージェントに固有のIDを与え、権限をアクティブなタスクに束縛し、環境外に出てよいデータを制約し、モデルと接続サービスの間に認可レイヤーを置くこと。」

ログについても、プロンプトの記録だけでなく、エージェントが実行したツールコールとアクションを記録する方向へのシフトが必要だとしている。

まとめ

可視性の確保→インベントリの構築→継続的な監視→ポリシー適用、という順序が崩れると、どの強制レイヤーも機能しない。AIエージェントのセキュリティは、既存のZero Trust原則をそのまま適用するだけでなく、インベントリが存在しないという出発点の特殊性を踏まえた設計が求められる。METRの事例が示すのは、60万ドルという金銭的損失よりも本質的な問いだ——自組織でいま動いているAIエージェントの数を、あなたは正確に答えられるか。その問いに答えられない組織は、すでに可視性の問題を抱えている。

詳細はZero Trust for AI Agents Starts With Fixing Zero Visibilityを参照していただきたい。