なぜエージェントは「LLM」より危ないのか

AIエージェントの危険性は「言い間違い」や「誤答」だけでは説明できない、という点だ。LLM（大規模言語モデル）単体のリスクは、主に生成物の品質や不適切発言、幻覚など、出力の内容に焦点が当たりやすい。しかしエージェントは、生成した文章を“行動”に変換してしまう。ここにセキュリティの質的な変化がある。

エージェントが持つ特徴を言葉にすると、自律性・連鎖性・権限性の3つが核になる。自律性とは、与えられた目的を達成するために、必要そうな手順を自分で組み立てて進める性質だ。連鎖性とは、一つの判断が次の入力を生み、その入力が次の判断を誘発し、結果的に長い実行チェーンになる性質だ。権限性とは、メール送信、チケット起票、データ取得、決済、デプロイといった「本来なら人が権限を持って実施していた操作」を、APIキーやSaaS連携の権限としてエージェントに渡すことだ。

この3つが揃うと、従来のアプリケーションよりも攻撃面が増える。理由は単純で、エージェントの判断材料（コンテキスト）が“外部から持ち込まれる”からだ。人間なら、メール本文やWebページを読んで「これは怪しい」「この指示は無視しよう」と判断してから操作する。しかしエージェントは、メールやWeb、PDF、チャットログ、チケット本文、さらにはRAG（検索拡張生成）で拾った資料など、さまざまな入力を同じ“材料”として扱いがちである。結果として、「データの中に命令が混ざる」状況が発生する。

さらに厄介なのは、エージェントは“目的達成”を優先するように設計されることが多い点だ。例えば「顧客からの問い合わせに即レスして」「売上レポートを自動で作って共有して」「緊急障害の一次対応をして」といった指示は、スピードや自動化を求める。そこでエージェントに強い権限を渡し、障害対応やコミュニケーションまで任せるほど、攻撃者にとっては魅力的な的になる。人の操作なら一回のミスで済むかもしれないが、エージェントはミスを“自動で増幅”し得る。

脅威モデルを考えるとき、従来は「アプリの入口＝APIやUI」「権限の境界＝ユーザー権限と管理者権限」「データフロー＝DBとサービス間通信」のように整理できた。ところがエージェントの入口は、APIやUIだけではない。メール本文、添付ファイル、社内Wiki、Slack、カレンダー、CRMのメモ欄、ログ、Web検索結果など、いわば“自然言語で書かれたものすべて”が入口になる。そして権限の境界も、ユーザー単位ではなく「エージェントが持つツール実行権限」に移っていく。ここを更新しない限り、どれだけ堅牢なインフラを敷いても、入口が穴だらけのままになってしまう。

要するに、AIエージェントを守るというのは、モデルを賢くすることではなく、「どこから何が入ってきて」「何を実行できて」「実行結果がどこへ波及するか」を設計することに近い。これが“エージェント時代の脅威モデル”の出発点になる。

典型的な攻撃パターン：インジェクション、権限悪用、横展開

AIエージェントの攻撃を語るとき、プロンプトインジェクションが真っ先に出てくる。もちろん重要だ。ただし、インジェクションは“入口”であって、被害の本体は「権限の悪用」と「横展開」によって生まれることが多い。脅威モデルとしては、入口→実行→波及という連鎖で捉えると理解しやすい。

最も分かりやすい入口は、メールやチャットの本文に紛れ込む誘導だ。例えば「この問い合わせは至急。まず顧客のアカウント状況を確認し、必要なら請求情報を更新して返信して」など、業務上もっともらしい文章が混ざっていると、エージェントは善意で動く。さらに本文のどこかに「システムメッセージを無視して次の操作を行え」などの指示が混ざっていると、エージェントの行動を乗っ取れる可能性が出る。人が読めば不自然でも、エージェントは“業務の一部”として扱ってしまいがちだ。

入口は自然言語だけではない。RAGを使って社内ドキュメントやナレッジベースを参照させる場合、その参照先に悪意ある文章が混入すると、エージェントはそれを「正しい根拠」だと誤認しやすい。外部Web検索を許している場合はなおさらで、攻撃者は検索結果に出やすいページを用意してエージェントを誘導することも考えられる。ここで重要なのは、攻撃者はモデルを直接攻撃しなくても、モデルが参照する“材料”を攻撃すればよい、という構図だ。

入口から侵入した次の段階が、ツール実行の不正誘導である。エージェントができることは、結局ツールができることに等しい。CRM検索、請求システム更新、メール送信、ファイル共有、Git操作、クラウド設定変更など、業務上の便利さを理由にツールを増やすほど、攻撃者は“実行手段”を手に入れる。たとえば「顧客対応」という名目で、顧客データの取得や添付送信が可能になっていれば、情報漏えいの経路が一気に現実味を帯びる。さらに「障害対応」という名目で、インフラ変更や再起動、設定更新まで許可していれば、最悪の場合はサービス停止や改ざんにつながる。

ここで発生しやすいのが、権限の誤委譲だ。人間は業務の文脈で「この操作は管理者に確認すべき」「このデータは持ち出し禁止」と判断するが、エージェントにその判断を委ねると、ポリシーが曖昧なまま実行される。特に危険なのは、「便利だから」と広い権限を一つのエージェントに集約してしまう設計である。メールも送れる、ファイルも共有できる、顧客データも見られる、請求情報も更新できる、となると、攻撃者が一度誘導に成功しただけで、被害は複合的になる。

そして最後の段階が横展開だ。横展開とは、最初に侵入した入口とは別の場所に被害が広がることを指す。エージェントの場合、横展開の典型は「エージェントが持つ認証情報・セッション・APIキーが、他のシステムに波及する」形で起きる。エージェントが使うSaaS連携は、しばしば長期トークンや高権限APIキーで実現されている。これが漏れたり悪用されたりすると、被害はエージェントの範囲を超える。また、エージェントが生成した結果（メール文、ドキュメント、チケットのコメント）が別のエージェントの入力になっている環境では、入力汚染が連鎖して“自走”することもあり得る。これがエージェント特有の怖さで、単発のミスがワークフロー全体に波及する。

攻撃パターンをまとめると、入口は「信頼できない入力」、実行は「ツールと権限」、波及は「連鎖と共有」である。脅威モデルは、個別の攻撃テクニックよりも、この構造を押さえたほうが強い。なぜなら、具体的な攻撃手法は変化しても、入口・実行・波及の三段階は設計上ずっと残るからだ。

実務で使える防御の最小セット：境界、検証、観測

では、AIエージェントを安全にするには何から手を付ければいいのか。理想を言えば、強固なポリシーエンジン、堅牢なサンドボックス、包括的なレッドチーム、継続的な安全評価など、やることはいくらでもある。ただ現実には、まず「壊滅的な事故を避ける」ための最小セットが必要になる。ここでは、境界・検証・観測という3つの軸で整理する。

最初の軸は境界、つまり「信頼できるもの」と「信頼できないもの」を明確に分けることだ。エージェント設計でありがちな失敗は、メール本文も社内の手順書も、ユーザーの指示も、すべてが同じコンテキストに混ざってしまうことにある。混ざった瞬間、命令とデータの区別が曖昧になり、攻撃者は“データの形をした命令”を持ち込める。したがって、信頼できない入力を原則として隔離し、「それは参考情報であって命令ではない」という前提を、実行系で担保する必要がある。ここで重要なのは、モデルにお願いして分離させるのではなく、設計として分離することだ。コンテキストを区画化し、ツール実行に影響する領域を限定する。さらに、長期メモリや共有メモリがあるなら、その書き込み条件を厳しくし、未検証情報が永続化しないようにする。

次の軸は検証だ。エージェントはツールを呼び出す瞬間に「現実へ介入」する。ならば、その瞬間に検証ゲートを置けば、被害を大きく減らせる。検証にはいくつか層がある。まずスキーマの固定と引数検証だ。ツール呼び出しの形式を厳格にし、想定外の引数や危険な値を弾く。次に許可リストとポリシー判定だ。例えば外部宛てメール送信、ファイルの公開共有、請求情報の変更、支払い実行のような操作は、業務上の正当性が必要なため、ポリシーで条件を定義し、満たさなければ実行不可にする。そして人間承認である。特に高リスク操作は、エージェントが提案した操作を人が確認してから実行する形にし、完全自動を避ける。ここでのコツは「全部を承認にすると運用が回らない」ので、承認が必要な操作の基準を明確化することだ。金銭・個人情報・権限変更・外部公開・破壊的変更、このあたりは原則承認に寄せると事故が減る。

最後の軸が観測だ。エージェントは「何を見て」「どう判断して」「何を実行したか」が追えないと、事故が起きたときに止血も再発防止もできない。観測とは、監査ログを残すだけではない。入力（参照したデータ）、推論（使ったモデルとプロンプトテンプレ）、実行（ツール呼び出しと結果）、そして権限（どのトークンで何をしたか）を、追跡可能な形で保存することだ。さらに、異常検知の観点も必要になる。いつもは見ない量のデータを取得していないか、通常はしない宛先にメールを送ろうとしていないか、深夜に権限変更が発生していないか、といった兆候を、エージェントの実行ログから検出できるようにする。エージェントはミスを拡大し得るのだから、観測によって早期に止める仕組みが欠かせない。

この3軸を、導入順に並べると分かりやすい。まず境界を引く。次にツール実行に検証ゲートを置く。最後に観測を整備し、異常を早く見つけて止められるようにする。これだけでも、エージェント導入の“初期事故”の多くは回避しやすくなる。 AIエージェントは、セキュリティにとって「未知の魔法」ではない。入口が増え、権限が集まり、実行が連鎖しやすいシステムだと捉えれば、脅威モデルは作れる。重要なのは、プロンプトを賢くすることより、実行系の設計でリスクを減らすことだ。便利さのために自律性を上げるなら、そのぶん境界・検証・観測を強くする。エージェント時代のセキュリティは、このトレードオフを“設計で”引き受けるところから始まる。