この記事は自動翻訳されています。原文は、こちらをクリックしてください。
prompt injection に対する防御は、しばしば不安定な地面の上に立っているように感じられます。
より強い system prompt を追加する。フィルターを追加する。いくつかの allowlist を用意する。そして、次の変な入力が前提を壊さないことを祈る。
だからこそ FIDES が興味深いのです。
この話の強みは、セキュリティをより決定論的なものへと移している点にあります。
- コンテンツに対するラベル
- ワークフロー全体でのラベルの伝播
- 権限付きツールが実行される前の middleware による強制
- 信頼できないコンテキストが影響できる範囲に対する明確なポリシー境界
元の記事は、ちょうどいい直球さで語っている
冒頭で prompt injection は “OWASP LLM Top 10 の第 1 リスク” だと述べています。
いいですね。
ここではこの率直さが好きです。というのも、あまりにも多くのチームが agent security を、今まさにある runtime 設計の問題ではなく、将来の懸念のように扱っているからです。
そして記事は、実践的な対比をはっきり示します。現在の防御の多くはヒューリスティックですが、FIDES はシステムをポリシーと強制へと向かわせようとしています。
それこそが、まさに正しい転換です。
なぜ別のセキュリティホワイトペーパーより説得力があるのか
AI セキュリティについての文章は、抽象的なまま終わることが多いです。
この記事はそれより良いことをしています。GitHub issue triage エージェント、悪意のある issue 本文、権限付きのファイル読み取り、そして公開コメントの漏えい試行という、かなり具体的な例をたどります。
これは、議論全体を実際のワークフローに結びつけるので有用です。
そしてそのシナリオを見ると、決定論的な制御の価値がずっと理解しやすくなります。
重要なのは「モデルをもっと賢くする」ことではない
ここで最も重要なのは、FIDES がモデルに攻撃検知を魔法のように上手くやれと求めていないことです。
それは runtime の契約を変えています。
つまり:
- コンテンツにラベルを付ける
- ラベルを伝播させる
- ツールが受け入れるものを明示する
- middleware が実行前に安全でない経路をブロックする
これはずっと健全なアプローチです。
なぜなら、エージェントが現実的な結果を伴うツールを呼び出せるようになったら、セキュリティはモデルの機嫌が良いかどうかだけに依存できなくなるからです。
私の見解
これこそ、私がもっと見たいエージェントセキュリティの方向性です。
「モデルが悪い指示を無視してくれると信じる」のではなく、「ポリシーフェンスを runtime の内側に構築する」のです。
こちらのほうがはるかに健全なモデルです。
そして、エージェントフレームワークが本番環境で真剣に受け止められたいなら、こうした話がもっと必要になります。
