OpenAPPAが攻撃率0%を達成、LLMエージェントのデータ漏洩を防ぐ設定法

• 事実と背景：ArchestraがLLMエージェントのデータ漏洩を防ぐOSS「OpenAPPA」を公開し、主要ベンチマークで攻撃成功率0%を記録。
• 技術的変革：LLMによる確率的判定を排除し、実行ループ外で動作する決定論的な「エージェント権限ポリシー代数（APPA）」を採用。
• 現場への影響：開発者はappa.tomlを記述するだけで、エージェントの利便性を損なわずに強固なセキュリティ境界を構築可能になる。

我々エンジニアが本番環境でLLMエージェントを稼働させるとき、常に背筋を凍らせる悪夢があります。それは、プロンプトインジェクションによる機密データの外部流出（データエクスフィルトレーション）です。深夜の障害対応で、自社データベースの顧客情報が外部の悪意あるAPIに送信されたログを見つけたときの絶望感は、デッドロックや無限ループの比ではありません。これまで業界が提示してきた解決策は、Claude Codeの「auto mode」やMicrosoftの「FIDES」に代表される、いわゆる「LLMにLLMを監視させる」確率論的なアプローチでした。しかし、私はこのアプローチに強い技術的懸念を抱かざるを得ませんでした。なぜなら、監視役のLLM自体がプロンプトインジェクションに対して脆弱であり、本質的な解決になっていないからです。

確率論的な分類器（Classifier）は、どれほどチューニングを重ねてもその精度は99.3%あたりで頭打ちになります。一見すると高い数値に見えますが、システムがスケールし、数百万回、数千万回のツールコールが実行されるエンタープライズ環境において、残りの「0.7%の隙間」は致命的なセキュリティホールを意味します。さらに、エージェントの「賢さ」も仇になります。例えば、危険なコマンドである「rm -rf」を禁止するブラックリスト（禁止リスト）を作ったとしても、エージェントはそれを回避するために、同等の処理を行うPythonスクリプトを動的に生成して実行してしまいます。ルールを厳しくしすぎれば、今度はエージェントが「安全のために何もしない」という無用の長物と化し、開発現場は「セキュリティ」と「実用性」の不毛なトレードオフに引き裂かれてきました。この膠着状態を打破すべく登場したのが、Archestraの「OpenAPPA」です。

OpenAPPAがもたらした最大のパラダイムシフトは、セキュリティ制御を「LLMの推論（確率）」から「代数的なルール（決定論）」へと完全に切り離した点にあります。Arseny Kravchenko氏らによって提唱された「Agentic Permissions Policy Algebra（APPA）」は、エージェントの実行ループの外側（Out-of-Loop）で動作するプラグイン可能なエンジンとして実装されています。これにより、基盤となるLLMがどれほど巧妙に騙されようとも、セキュリティポリシーをバイパスしたり、交渉によってルールを書き換えたりすることは物理的に不可能です。ポリシーは、開発者にとって馴染み深い単一の「appa.toml」ファイルに宣言的に記述されます。

この代数モデルの根幹を支えるのが、格子代数（Lattice Algebra）を用いた「audience（閲覧権限）」と「trust（信頼度）」の単調変化（Monotonic Composition）です。データがシステム内を流れる際、そのセキュリティラベルは「より厳格な方向」にしか変化しません。例えば、CRMから顧客チケットを読み込むツールを実行すると、そのエージェントのコンテキスト全体のaudienceは自動的に「internal（社内限定）」に狭められます。その後、データを外部に送信するような「public」権限を必要とするツールを呼び出そうとしても、エンジンが即座にこれをブロックします。同様に、信頼できない外部ウェブページを読み込むと、信頼度は「suspicious（不審）」に低下し、データベースのマイグレーションといった「trusted（信頼済み）」を要求するアクションは自動的に拒否されます。以下に、そのポリシー記述の具体例を示します。

• データソースと権限の紐付け: ツールごとに「requires（実行に必要な条件）」と「delta（実行後に適用される制限）」を厳密に定義。
• 決定論的なフロー追跡: LLMのプロンプトを隠蔽するのではなく、データフローそのものを追跡して動的に権限を制限。

しかし、単にルールを厳しくするだけでは、エージェントはすぐに「権限エラー」で動作を停止し、開発者は再び「 approval fatigue（承認疲れ）」に悩まされることになります。OpenAPPAの真に実用的な部分は、エラー時にシステムをクラッシュさせるのではなく、安全に処理を継続するための「回復セマンティクス（Recovery Semantics）」を備えている点です。具体的には、個人情報（PII）を自動的にマスキングして閲覧権限を広げる「Sanitizers」、人間のオペレーターや内部検証APIに承認を求める「Authorities」、そして最も興味深い、未信頼のデータを一時的に隔離された環境で処理する「Disposable Child Branches（使い捨て子ブランチ）」という3つのアプローチが用意されています。

このアプローチの有効性は、企業の複雑なマルチステップワークフローを模した「Bench-Corp」や、OWASP Top 10 for Agentic Applications (2026)をベースにした「AgentThreatBench」といった過酷なベンチマーク結果が証明しています。以下の比較表が示す通り、OpenAPPAは競合を圧倒する数値を叩き出しました。

特筆すべきは、回復戦略（Remedy Plans）をすべて無効化した場合、OpenAPPAのタスク完了率は89%から35%へと急落したという実験結果です。これは、エージェントのセキュリティにおいて「回復機能」がいかに実用性を担保するための生命線であるかを物語っています。現在、OpenAPPAはプレビュー版として公開されており、AgentThreatBenchはすでにUK AI Safety Instituteの公式評価リポジトリに統合されています。

我々エンジニアは、明日からでもエージェントの設計思想を「LLMによる自己監視」から「決定論的な情報フロー制御」へとシフトさせるべきです。あなたの開発しているエージェントは、本当に「0.7%の悪夢」に耐えられますか？それとも、利便性と引き換えにセキュリティのロシアンルーレットを回し続けますか？この問いに対する答えが、これからのエンタープライズAI開発の成否を分けることになるでしょう。