Anthropic の『Zero Trust for AI Agents』を、自分の調査エージェント基盤に当ててみた

出典は Anthropic・Claude Security team の eBook、Zero Trust for AI agents（PDF）。全 36 ページ。

便利機能カタログだと思って開けたら、攻撃面の地図だった

以前、Anthropic が出した業種特化のエージェント製品を基盤開発者の目で分解したことがある（「業種特化の AI ツール」だと思って開けたら、縦型エージェント基盤の設計図だった）。あのときは「権限・継ぎ目・信頼境界を、どう構成ファイルで縛るか」を読んだ。今回はその対になる文書だ——なぜそう縛るのか、縛り損ねたら何が起きるのか、を書いている。

いま自分が作っているのは、ざっくり言えば「調べて、まとめて、書く」を担う汎用エージェント基盤だ。ハイブリッド検索で資料をまとめて持ってきて、ingest → extract → compile → query のパイプラインで論理的な文章を組み立てる。題材は色々あるが、本丸は「題材」ではなく「この基盤がどこまでできるか」のほうにある。

その視点でこの eBook を開いたら、想定と違った。てっきり「Claude Code でセキュアにエージェントを動かす便利機能カタログ」だと思っていたら、もっと手前の問いを立てていた。

そのエージェント基盤は、そもそも信頼できるのか？

便利さの紹介ではなく、「あなたが作っているその実行系は、新しい攻撃面だ」と言ってくる文書だった。だから刺さった。

この文書が言っていること（三行で）

Zero Trust そのものは新しくない。NIST SP 800-207（2020）が下敷きで、原則は3つ。

1. 何も信頼せず、常に検証する — 社内からの要求も外部 IP と同じ精査を受ける
2. 侵害を前提に設計する（assume breach） — 防ぐより、起きたときの被害範囲を限定する
3. 最小権限 — タスクに必要な最小限だけ与える

新しいのは、これを自律エージェントという実行系に当てたときの帰結のほうだ。

• フロンティアモデルが「脆弱性発見→悪用」の時間を数ヶ月から数時間に圧縮した。攻撃側のコストは数ドル。だから摩擦（レート制限・追加の手間）でしかない防御はもう効かない。無限の忍耐とゼロコストで試行してくる相手には、面倒なだけの壁は壁ではない。
• エージェントは「正規の権限・正規のバイナリ・正規の資格情報」の中で悪用される。だから従来のアクセス制御では止まらないし、ホスト監視にも映らない。

この文書が出してくる2つの語彙が、設計の解像度を上げてくれる。

• Blast radius（爆発半径） — そのエージェントが壊れたとき、どこまで被害が及ぶか。読み取り専用の単一 DB なら半径は小さい。クラウド管理権限を持つなら甚大。投資はこの露出に見合わせろ、という。
• Least agency（最小エージェンシー） — OWASP の造語で、最小権限のエージェント版。「何を・どれだけ・どこで」できるかまで絞る。要約ツールに送信権限は要らない、DB ツールは読み取りだけ、と。

「パイプラインのセキュリティ」か「セキュリティのパイプライン」か

読みながら一度迷ったのが、これが二義的だということだ。

• パイプラインのセキュリティ — エージェントの実行経路（取り込み→推論→ツール→メモリ→連携）そのものを守る話
• セキュリティのパイプライン — セキュリティ業務に AI/エージェントを使う話

この eBook の主軸は前者だ。8〜9割は「あなたが作る agentic な実行系を、各段で信頼ゼロに縛れ」という話。ingest → extract → compile → query の各ノードを、どう信頼せずに繋ぐかのチェックリストとして読める。

だが後半（Part V）で役割が反転する。「アラートキューの先頭に AI を置け」「Agentic SOAR で数秒で対応しろ」——エージェントを防御の道具として使う話になる。

そしてこの文書の一番うまいところは、その反転にすぐ釘を刺すことだ。

防御に使うエージェントにも、同じ Zero Trust を適用しろ。防御自動化を盲信するな。

つまり「セキュリティのパイプライン」を作った瞬間、それ自体が「守るべきパイプライン」になる。基盤を一つ作るとは、守るべき対象を一つ増やすこと——この入れ子が、文書全体の通奏低音になっている。

図にすると分かりやすい。Zero Trust で実行系を縛る。防御を速くするためにエージェントを足す。するとその防御エージェント自身に、また同じ Zero Trust が要る——矢印が出発点に戻る。終わりのないループに見えるが、これは欠陥ではなく、自律システムを足すという行為の正体だ。

自分の基盤に当ててみる

ここからが本題で、自分の「調べてまとめて書く」基盤に重ねると、機能の売りがそのまま攻撃面の説明になっていることに気づく。

機能の各段が、そのまま論点に化ける。取り込みは脅威に、組み立ては信頼の設計に、応答は権限の設計に。そして三つとも、同じ一点に収束する。

1. ハイブリッド検索の裏面＝ RAG ポイズニング。 「資料をまとめて持ってくる」のが売りだが、それは裏返すと汚染された資料を取り込む経路でもある。eBook は RAG ポイズニング・メモリポイズニングを脅威として明記している。出典の正しさが命の領域では、これは機能の話であると同時に信頼の話だ。

2. 「論理的文章生成」の品質保証＝トレーサビリティ。 eBook が Part III/IV で求める 来歴チェーン（どの一次資料からこの結論を導いたか辿れること） は、自分が基盤で謳いたい「論理的に組み立てる」とほぼ同じものを別の言葉で言っている。「説明可能性は規制業界では必須」という主張と、「根拠を辿れる文章生成」という売りは、地続きだった。

3. ツール権限＝ least agency。 取り込み・検索・整形・出力で、各ツールに必要最小の権限だけを与える。deny-by-default、書き込みは要るときだけ、外部送信は別承認。これは制約というより、基盤の信頼性そのものの設計だ。

結局なにを持ち帰るか

一番大きい収穫は、語彙でもチェックリストでもなく、主張の高さだ。

「便利な調査エージェントを作った」ではなく、「検証可能な知的労働のパイプラインを作った」と言えるかどうか。来歴が辿れて、権限が最小で、壊れたときの半径が見えている——そこまで設計して初めて、それは「便利ツール」ではなく「土台」になる。

そしてこの eBook 自身が、その構えで書かれている。エージェント基盤を作るとは、守るべき新しい世界を作ることだ、という構え。自分が記事で出したいトーンと、奇しくも同じだった。