エージェントセキュリティはシステムの問題である：プロンプトインジェクションからランタイム制御まで

LLMエージェントのセキュリティに関する2026年の主要な調査は、企業チームが真剣に受け止めるべき結論を導き出しています。モデルがツールを使用し、状態を保持し、他者に代わって行動できるようになると、セキュリティはもはや単なるプロンプトフィルタリングの問題ではなくなります。それは、以下の要素にまたがるシステムの問題となります。 情報の流れ、委任された権限、永続的な状態。

1. エージェントのセキュリティがLLMの安全性と異なる理由

この調査は、単純なアーキテクチャ上の事実から始まります。LLMエージェントは単にテキストを生成するだけではありません。計画を立て、ツールを呼び出し、ブラウジングを行い、コードを実行し、状態を更新し、他のエージェントと連携することさえあります。これらの機能により、モデルの出力はソフトウェアの制御フローへの入力へと変わります。

それが障害モードを変化させます。Webページに隠された悪意のある指示は、後のツール呼び出しに影響を与える可能性があります。汚染されたツールの結果は、別の意思決定のコンテキストになるかもしれません。侵害されたメモリのエントリは、元のセッションを超えて存続する可能性があります。委任された認証情報は、誤った計画を現実の副作用へと変えてしまう恐れがあります。マルチエージェントシステムでは、汚染された情報が最初に遭遇したエージェントを超えて伝播する可能性があります。

そのため、この調査ではエージェントのセキュリティを、相互に作用する3つの特性を中心に構成しています。

ここから得られる有益な示唆は、セキュアなエージェントのアーキテクチャにおいて「悪意のあるプロンプトをブロックしたか？」と問うだけでは不十分だということです。次のように問うべきです。 そのコンテンツは何に影響を与え得るか、その結果生じる軌跡はどのような権限を行使し得るか、そしてその軌跡はどのような状態を残し得るか。

2. 攻撃対象領域はエージェントのライフサイクル全体に及ぶ

Ling氏らは、攻撃名のリストを並べるのではなく、ライフサイクルに基づいたシステム指向のフレームワークを採用しています。運用上、入力、計画、意思決定、ツール実行、出力というコアとなるアクションパスを、メモリ、監視、マルチエージェント調整といった横断的な領域から分離することは有益です。これらの領域は、実行の複数の段階に影響を与えたり、それを観測したりできるためです。

このライフサイクルの視点は、調査で指摘されているように、防御がなぜ「弱くしか構成できない（weakly compositional）」のかを説明しています。コンテンツフィルターは特定のクラスの悪意のあるテキストをブロックできても、権限が過剰な認証情報には無力かもしれません。サンドボックスはコード実行を封じ込めても、許可されたAPI呼び出しを防ぐことはできません。承認ゲートは一つの副作用を止めても、汚染されたメモリへの書き込みを防ぐことはできません。トレースはインシデントを観測可能にしても、それを未然に防ぐことはできません。

したがって、セキュリティは以下の要素から生まれます。 構成 境界、権限、状態制御、およびエビデンスについて。

3. 調査結果とTrueForgeおよびTrueFoundryのマッピング

最も明確な製品マッピングは、「TrueFoundryがエージェントのセキュリティを解決する」というものではありません。調査のシステムモデルにおいて、各レイヤーが現実的にどの部分を制御できるかを問いかけることです。

‍

‍