11月10日、IEEE Spectrumが「Can We Trust AI Agents When Zero Trust Isn't Really Zero」と題した記事を公開した。AIエージェントが急増する中でゼロトラストアーキテクチャが実際には「ゼロ」トラストになっていないという根本的な矛盾と、その実装上のリスクについて詳しく論じた内容だ。

「ゼロトラスト」なのに信頼せざるを得ない矛盾

ゼロトラストアーキテクチャ（ZTA）とは、「決して信頼せず、常に検証する（never trust, always verify）」を原則とするセキュリティモデルだ。エンタープライズのネットワーク設計に広く採用されており、NIST SP 800-207として標準化されている。

ところが、この原則をAIエージェントのオーケストレーションに適用しようとすると、根本的な問題が浮かび上がる。ZTAにはポリシー強制ポイント（PEP: Policy Enforcement Point）という信頼の要となるコンポーネントが存在するが、このPEP自体を「信頼」しなければシステムが成立しない。つまり「ゼロトラスト」と言いながら、どこかに必ず信頼の起点が生まれる構造になっている。

記事はこの矛盾を率直に問う：「真のゼロトラストは存在するのか？」

コンテキスト回復攻撃と削除命令の無効化

問題をより具体的に示す事例として、記事はAIエージェントチームの運用シナリオを挙げている。リスク評価やクライアントプロファイリングを担う複数のエージェントを、オーケストレーターが管理する構成だ。意思決定の偏りを防ぐため、エージェントには定期的に過去の履歴情報を削除するよう指示（チェックポイント）が設けられている。

しかし、記事が概念的リスクとして指摘するのは、その後のプロンプト次第で「削除したはずの情報」を再び引き出せる可能性だ。これは「コンテキスト回復攻撃（context recovery attack）」と呼ばれる手法であり、削除命令が実行されたかどうかを証明する手段がなく、「指示に従ったか」を検証できないという根本的な課題を示している。なお、この点は後述するQUBの実験的証拠とは異なり、あくまで設計上の脆弱性として記事中で論じられているものだ。プロンプトインジェクションを含むこうした攻撃の類型については、OWASPのLLMセキュリティガイドも参照に値する。

エージェント規模が攻撃速度を引き上げる

クイーンズ大学ベルファスト（QUB）のチームが実施した実験では、エージェントによるオーケストレーションを使った場合、認証解除攻撃（de-authentication attack）をわずか2〜3秒で実行できたことが示された。これは実際の実験環境での計測値として記事に報告されている数字だ。

通常の攻撃対応ではパッチ適用や判断に一定の時間が必要だが、このウィンドウが2〜3秒まで圧縮されると、現実的な対応はほぼ不可能になる。エージェントの数が増えれば増えるほど、攻撃の実行速度と影響範囲が拡大する。

「水平方向の異常」という未探索のリスク

記事が特に強調するあまり議論されていないリスクが、水平方向の異常（horizontal anomalies）という概念だ。

あるエージェントが特定のタスクや環境では期待通りに振る舞っていても、別のコンポーネントや別の文脈では異なる挙動を示す可能性がある。エージェントAが信頼できると確認されたとして、それはエージェントAが関連するすべての操作において信頼できるという意味にはならない。

この異常をどう検出するか、またエージェントの協調を損なわずに検出手法をどう実装するかは、現時点で未解決の問題として提示されている。従来の垂直方向（レイヤー間）の異常検知とは異なり、同一エージェントの文脈横断的な挙動のばらつきを追うという発想自体が新しく、既存のモニタリングフレームワークでは十分にカバーされていない領域だ。

サプライチェーンリスクと「封じ込め不可能」な障害

エージェントが「ローグ（制御不能）」化した場合、影響はそのエージェント単体に収まらない。エージェントはプロキシエージェントをトリガーし、直接には関係しないエコシステムにまで波及する。記事はこれをサプライチェーン問題として捉え、「被影響エージェントのすべてのタッチポイントを横断的にスウィープする必要があり、もはや封じ込め可能な小さなタスクではない」と述べている。

この問題への対応策として記事が示すのは以下の2点だ：

• AI部品表（AI-BOM: AI Bill of Materials）の整備
• 分散台帳技術（Distributed Ledger Technology）を活用した、プラットフォーム非依存のトレーサビリティ確保

AI-BOMはソフトウェアのSBOM（Software Bill of Materials）をAIシステムに拡張した概念であり、モデルの出所・学習データ・依存コンポーネントなどを体系的に記録するものだ。分散台帳と組み合わせることで、エージェントの活動と信頼ベクトルを追跡可能かつ改ざん不可能な形で記録する基盤を構築できるとしている。

「バイブコーディング」がもたらす攻撃面の拡大とその位置づけ

記事はセキュリティ観点からバイブコーディング（vibe coding）にも言及している。AIモデルを使ってコードを生成する手法だが、組織外の信頼されていないエンティティにコードベース全体を渡す行為は、複数の攻撃面にわたって脆弱性を生む可能性があると指摘している。

この言及は単独のトピックというよりも、エージェントへの信頼境界がコード生成のレイヤーにまで広がっていることを示す事例として記事中に位置づけられている。開発フローにAIエージェントを組み込む場合、コード生成段階からサプライチェーンリスクへの意識が求められるという論点の延長線上にある。

問いは残る

記事の結論は明快な答えではなく、問いの提示で終わる。「実世界にエージェントをデプロイする際、完全に穴のない保証なしで済ませられるのか。もしそうでないなら、どこまでの影響を制御できるのか。残る部分の責任は誰が負うのか。」

信頼を半ば欠いたガバナンスのもとでエージェントを運用することは短期的には高い効果をもたらすが、システム障害時のリカバリコストはまだ誰も測っていない、というのが記事の最後のメッセージだ。

詳細はCan We Trust AI Agents When Zero Trust Isn't Really Zeroを参照していただきたい。