AIエージェントの`rm -rf`を実行前に止める「Doberman」──自己申告ベンチマークを読むと見えてくる限界

3行まとめ

1. Dobermanは、AIコーディングエージェントとツール（ファイル・シェル・MCPサーバー・API）の間に入り、すべての呼び出しをPASS（素通し）／AUTH（人間承認待ち）／BLOCK（実行前に停止）の3段階で判定する実行時ガードレール。alphaステータスのOSS。
2. 「失敗時は拒否する（fail closed）」「制約は自動的に厳しくなるだけで、勝手には緩まない（raise-only）」の2つを保証として掲げる。
3. GitHub上で開発者自身が公開しているベンチマーク（112件の攻撃検証セット）では、AUTHとBLOCKを合わせた検知率が74%（strictモードで79%）、そのうち完全ブロック（BLOCK）まで到達したのはわずか8%だった。

プロンプトを読むのではなく、実行の手前で止める

READMEの書き出しはストレートだ。「あなたのAIコーディングエージェントはrm -rfでリポジトリを消せるし、APIキーを漏洩させられるし、プロンプトインジェクションでデータを持ち出すよう誘導されうる。しかも自律的に、取り消しなしで」。多くの「AIガードレール」はプロンプトを検査してアドバイスするだけで、モデルがすでに決断した後に動く。Dobermanはそうではなく、ツール実行のパス自体に割り込む——MCPプロキシまたはホストフックとして、Claude Code・Codex・OpenClaw、その他MCP対応エージェント全般の前段に立ち、すべてのツール呼び出しを次の3段階のいずれかに振り分ける。

保証は2つ。1つは「fail closed」——エラーや不確実性、想定外のケースはすべて拒否に倒れる。承認プロンプトに誰も答えなかった場合も、タイムアウト（デスクトップダイアログは2分、全体のバックストップは20分）で自動的に拒否扱いになり、これはdeniedではなくtimeoutとして区別してログに残るという。もう1つは「raise-only」——ガードレールや適応学習は自動的に厳しくなることはあっても、勝手に緩むことはない。恒久的なポリシー緩和には、TOTP（登録済みの場合）またはローカルパスワードによる、明示的かつ監査可能な人間の承認が必要とされている。

自己申告ベンチマークの数字

READMEは「防御の主張は再現可能な数字に帰着すべきで、形容詞であるべきではない」として、docs/BENCHMARKS.mdにベンチマーク結果を公開している。実際にこのファイルを取得して確認したところ、次の指標が定義されていた。

• ASR（攻撃成功率）: 攻撃がツールまで到達してしまった割合。asrはBLOCKのみを「阻止」とカウント、asr_strictはハードブロックのみを阻止とカウントする（AUTHは阻止に数えない、人間がまだNoと言っていないため）
• FPR（誤検知率）: 正常な操作に摩擦（AUTH/BLOCK）が発生した割合
• オペレーター指標: AUTHに対して人間が常に拒否した場合／常に承認した場合の結果を分けて示す、"AUTHは壁ではなく引き綱"という前提を数字にしたもの

docs配下の「detection corpus」（攻撃112件・正常系25件の決定論的セット、2026-08-13時点・Doberman-Core組み込みルールのみ）の結果は次の通りだった。

正常系25件に対する誤検知率（FPR）は0.00で、無害な操作を巻き込んで止めることはこのセット上ではなかった、という数字だ。一方でBLOCKまで到達した割合（tpr_strict）はbalancedモードでわずか0.08——つまり検知した攻撃のほとんどはAUTH（人間承認待ち）止まりで、人間が誤って承認すればすり抜ける。README自身も「AUTHは壁ではなく引き綱」という表現でこの限界を繰り返し明記している。自然言語によるプロンプトインジェクション（injection）はカテゴリ全体で検知率0.00と、決定論的な検知ルールでは構造的に手が届かない領域として、隠さずに「ドキュメント化された既知の穴」と書かれている。このカテゴリの実行結果はdocs/BENCHMARKS.mdによれば2026年8月13日、doberman-core組み込みルールのみで計測されたと明記されている。

誤検知の具体例もdocs/BENCHMARKS.mdは隠していない。「.env.exampleのようなテンプレートファイルを読むだけの操作が過剰にブロックされる」ケースが、シークレットパス用ルールが.env.*という命名パターンに対してfail-closed（不確実なら止める）で反応するために起きる、と自己申告している。

公開されていない項目もある

docs/BENCHMARKS.mdには、上記の「detection corpus」（自前112件）とは別に、外部の攻撃ベンチマークセット「AgentDojo」を使った、より大規模な評価の章がある。ただしその中身を確認すると、この章は現時点では空欄のままだった。原文は次の通り。

Pending an operator run, populated at release time per RELEASING.md. Record the pinned agentdojo commit and the before_after table here.

（運用側の実行待ち。RELEASING.mdに従い、リリース時に記入される。固定したagentdojoのコミットとbefore/afterの表をここに記録すること）

つまり、この記事で紹介した74%／79%／8%という数字は、開発者自身が「小規模」と断っている自前の112件セットに対するものであり、より広いカバレッジを測るはずの外部ベンチマークの結果はまだ存在しない。同じファイルの「Fixed bypasses（報告され修正済みのバイパス）」欄も、確認した時点では「None disclosed yet.（まだ何も開示されていない）」という記載だった。

もう一つ、docs/BENCHMARKS.mdが公開しているのが「cross-session baseline poisoning（セッションをまたいだ学習データの汚染）」への耐性評価だ。Dobermanの適応学習レイヤーは「許可された操作」だけを学習するため、攻撃者が危険な操作を少しずつ複数セッションに分けて「正常」と学習させ続ける、という緩慢な攻撃に理論上さらされる。この評価で、攻撃者が承認ゲートを一切通さず学習させられた操作だけを対象とする「admitted」条件での汚染成功率は0だったと報告されている。ただし、これは開発者自身が公開したベンチマーク結果であり、この記事では再現していない。

「89%しか防げない」という数字は確認できなかった

事前のリサーチメモには「AIガードレールは危険なコマンドの89%しか防げない＝1/9は素通り」という問題意識が記録されていたが、README本文およびdocs/BENCHMARKS.mdのいずれにも、この「89%」という数値そのものは見当たらなかった。実際にcurlで取得できた一次資料の数字は上記の74%/79%/8%であり、本記事ではこちらだけを採用している。

リポジトリとしての実態

GitHub APIでfu351/Doberman-Coreのメタデータを直接取得すると、次の数字が確認できた。

作成から取得時点まで3ヶ月に満たない、比較的若いプロジェクトであることが分かる。直近のpushが取得前日となっており、開発は継続中とみられる。

確認できた範囲・できなかった範囲

本記事はDoberman-CoreのGitHub README、docs/BENCHMARKS.md本文、GitHub APIのリポジトリメタデータを2026年8月29日にcurlで取得した内容にもとづく。手元では実際にDobermanをインストールしてエージェントの前段に配置し、攻撃を再現して動作を検証したわけではない。ステータスは「alpha」とREADMEに明記されており、ベンチマークの数字自体も「合成攻撃セットに対する決定論的なCIスモークテスト」（3件の攻撃と3件の正常系）と「検知コーパス」（112件と25件）という比較的小規模なセットに対するものである点は、開発者自身が繰り返し断っている通りだ。上述の通り、より大規模な外部ベンチマーク（AgentDojo）の結果は公開時点でまだ埋まっておらず、この記事もその欠落を埋め合わせる情報は持っていない。198という星の数についても、実際の導入事例や本番運用での報告をこの記事では確認できていない。

日本語カバーはまだない

Zenn・Qiitaともに実質的な言及は見当たらなかった。「エージェントのツール実行を実行前に止める」という発想自体は日本語圏でもプロンプトインジェクション対策の文脈で語られるが、Dobermanという固有名詞での紹介はまだない。

関連記事

• AIセキュリティリスク──プロンプトインジェクション・データ漏洩対策【2026年】
• AIエージェントにrm -rf ~を打たれても平気にする──macOS向けサンドボックスAgent Safehouseの仕組み
• MCP（Model Context Protocol）とは──AIとツールをつなぐ共通規格
• 生成AIのセキュリティリスク──企業が押さえるべき6つの脅威と対策