AIコーディングエージェントの危険な操作をOSS「Doberman」はどう止めるのか

「コーディング用のAIエージェントに作業を任せたいが、間違ってファイルを消したり、鍵を外へ送ったりしないか心配だ」「エージェントの設定で禁止しておけば、それで十分なのではないか」——開発部門にAIエージェントを広げようとしている情報システム部門やセキュリティ担当の方から、こうした相談が増えています。問題は、エージェントがどれだけ賢いかではありません。本当に問うべきなのは、危険な操作が実行される直前に、エージェントの外で止める関門があるかどうかです。この記事では、エージェントと道具の間に入って操作を一件ずつ判定するOSS「Doberman」を取り上げ、何をどう止めるのか、開発元が認める限界、公開されている高深刻度の勧告、導入前に企業が決めておくべき点を整理します。導入や設定の手順は扱いません。

Dobermanとは何か。2026年10月時点で確かめられる事実

Dobermanは、GitHubで公開されているOSSです。READMEの見出しは「AIコーディングエージェントのための適応的な認可と実行時のガードレール（安全柵）」で、リポジトリの説明には、すべての入力・出力・道具の呼び出しを実行時に関門にかけ、危険な操作や意図しない操作を実行前に止める、とあります。Pythonで書かれ、Python 3.11以上で動くとされ、パッケージの登録所PyPIでも配られています。

このラインで精査した2026年10月19日時点で、スターは282、派生は44、主枝の変更の記録は727件、未解決の課題は51件でした。リポジトリは2026年6月7日に作られ、最後の更新は10月18日です。ライセンスはApache-2.0で、商用も含めて使える条件です。READMEには「アルファ版」を示す表示があります。

運営元も確かめます。リポジトリを持つのはDobermanCoreという組織のアカウントで、作られたのは2026年8月24日と、リポジトリそのものより後です。公開しているリポジトリは1件、フォロワーは7人で、会社名やウェブサイトの登録はありません。リポジトリの作成日のほうが古いことから、別のアカウントから移されてきた可能性がありますが、経緯は確認できませんでした。セキュリティ方針の文書には、保守をボランティアが担っていると書かれています。

なぜ「実行の経路」に関門を置くのか

READMEは、問題意識を短い一文で示しています。実行の経路の上にないガードレールは助言しかできない、というものです。多くの安全柵は、利用者の指示文やモデルの出力を調べ、モデルが何をするか決めたあとに注意を促すにとどまる、とREADMEは指摘します。

これに対してDobermanは、エージェントが道具を呼ぶ経路の上に座ります。READMEの説明では、止められた操作は、モデルの安全対策をどう言いくるめて通り抜けてきたものであっても実行されないとされています。外部の文書やウェブページに仕込まれた指示に、エージェントがだまされた場合を想定した設計です。

READMEは、守りたい場面として、リポジトリをまるごと消す命令、鍵の漏えい、隠れた指示にだまされたエージェントによる情報の持ち出しを挙げています。いずれも一度起きると取り消しがきかない種類の事故です。想定する利用者は、自律的に動くコーディングエージェントを使う開発者、エージェントやMCPの安全を評価するセキュリティ担当、複数のエージェントを展開して方針・記録・人の承認を必要とする基盤チームだとされています。

三つの判定：通す・承認を待つ・止める

Dobermanの中心は、道具の呼び出し一件ごとに、実行前に必ず一つの判定を出すことです。READMEでは判定を三つに分けています。一つ目のPASSは、日常の作業としてそのまま通すもの。二つ目のAUTHは、慎重に扱うべき操作として一時停止し、人の承認を待つもの。三つ目のBLOCKは、危険な操作として止め、実行させないものです。

承認待ちには、便利さのための例外があります。READMEによると、まったく同じ操作を5分以内に繰り返した場合は、一回の確認で通せる簡易な確認が出ます。ただし壊す種類の作業には、この簡易な確認は使われないとされています。公式ドキュメントでは、判定には理由を示す符号と一行の説明が付くと書かれています。

判定の流れは、公式ドキュメントで次のように説明されています。まず入口が呼び出しを受け止め、共通の形に整えます。次に、決まった規則で判定する層と、状況に応じて判定を調整する層が評価します。二つの層の結果は、どちらか厳しいほうより弱くならない形で合わせるとされています。片方が通すと言っても、もう片方が止めるなら止まる、という考え方です。

二つの約束：迷ったら止める、緩めるのは人だけ

READMEは、二つの性質を「保証」として掲げています。一つ目は、迷ったら止める（フェイルクローズ）です。エラー、判断のつかない状態、想定していない場合は、すべて操作を拒否する扱いになります。判定の仕組みを迂回して道具に届く経路はない、とされています。

この約束は、人が応答しない場合にも及びます。承認を求める画面に誰も答えなければ、決められた期限で拒否として処理されます。READMEによると、端末上の確認画面は2分、承認の流れ全体の歯止めは10分で、記録には「拒否」ではなく「時間切れ」と区別して残ります。エージェントは人が見ていない時間にも動くため、応答のない承認が素通りにならないことは、守る側にとって大切な性質です。

二つ目は、緩めるのは人だけ、という約束です。規則や学習による調整は自動で厳しくなることはあっても、黙って緩むことはないとされています。恒久的に規則を弱めるには、記録の残る人の承認が必要で、さらに本人が持っているものによる確認（認証アプリの使い捨て番号、なければ手元で決めた合言葉）を求めます。エージェントが自分の都合で規則を緩める経路を断つための仕組みです。

どうつなぐのか：フックと、MCPの中継

Dobermanは、二つの方法でエージェントと道具の間に入ります。一つはフックで、エージェントの実行環境が道具を呼ぶ前後に自動で走らせる処理に組み込む方法です。もう一つはMCPの中継で、MCP（エージェントと道具をつなぐ標準の約束事）のサーバーの手前に入り、呼び出しを受け止めてから本来のサーバーへ渡す方法です。

READMEの対応表では、Claude Codeはフックで組み込む方法が推奨とされ、組み込みの道具とMCPの道具の両方の呼び出しを関門にかけるとされています。Codexはフックで組み込む方法が試験的な扱いです。Claude DesktopとCursorはMCPの中継で守り、Cursorはフックによる組み込みも試験的に用意されています。OpenClawには専用の組み込み部品があり、そのほかのMCP対応のエージェントはMCPの中継でつなぐとされています。つまり、使っているエージェントによって、守られ方と成熟度が違うということです。

READMEには、エージェントごとにどの守りが働くかを示す対応表への言及があり、各項目は自動の試験に結びついていると説明されています。空いている項目は、まだ証明されていない部分です。導入を考えるなら、自社で使うエージェントの欄に何が並んでいるかを先に確かめるのが近道です。なお、組み込んだ設定が後から書き換えられた場合に警告を出す機能もありますが、READMEは「検知だけで、止めはしない」と明記しています。

方針をコードとして管理する仕組みと、厳しさの段階

Dobermanは、止める対象や承認に回す対象を、リポジトリに置く方針の文書で決められます。READMEによると、止めるファイルの範囲と慎重に扱うファイルの範囲を書き、プログラムの変更と同じ審査の流れで見直す使い方が想定されています。例として、秘密情報を置く場所や証明書のファイル、基盤の設定などが挙げられています。

ここでも、緩める方向には歯止めがあります。新しい版の方針から範囲を一つ外しても、人が変更を受け入れるまでは、厳しい側の設定が保たれるとされています。方針の文書をエージェントが書き換えて守りを外す、という筋書きを想定した作りだと読めます。

厳しさは、軽め・標準・厳格・最も厳格の四段階から選べます。加えて、実際に止める・見張るだけ・切る、の三つの切り替えがあります。READMEによると、設定を下げる変更には本人確認が必要で、追記しかできない台帳に記録される一方、上げる変更は自由です。見張るだけの状態で使えば判定は記録に残るだけで止まらないため、どの状態で運用しているかは管理側が把握しておく必要があります。

記録と承認の画面、そして外へ送られる情報

判定は記録に残ります。公式ドキュメントによると、判定の記録は守っているリポジトリの中の専用の場所に、手元のデータベースとして書かれます。書き込む前に伏せ字の処理がされ、残るのはパスの分類、理由の符号、判定、必要な場合の照合用の指紋だけで、生の秘密情報や指示文、ファイルの中身は記録に入らないとされています。設定しない限り、記録が端末の外へ出ることはないとも書かれています。

記録を外部の仕組みへ送る拡張の口もあり、ウェブへの通知と、監視基盤の標準形式への送り出しが組み込みで用意されています。どちらも設定で有効にしない限り動きません。動いている判定や承認待ちを眺める画面もあり、そこから承認待ちに答えることもできます。一方で、記録そのものに改ざんを見抜く仕組みがあるかは、確認した資料には書かれていませんでした。

外へ送られる情報として注意したいのが、利用状況の送信です。公式ドキュメントによると、匿名の利用状況の送信は既定で有効で、米国のPostHogの基盤へ送られます。送るのは版、基本ソフトの種類、使った命令の名前、判定の件数などで、パス、ファイルの中身、指示文、秘密情報などは送らないとされ、止めることもできます。リリースノートを見ると、8月26日の0.18.2では利用者が選んだ場合だけ送る扱いでしたが、翌日の0.18.4で既定で有効に変わっています。また9月9日の0.18.7のリリースノートには、電話での承認の通知に、実行しようとしている命令の文字列が載って通知用のサーバーへ送られると書かれています。

公開されている評価の数字をどう読むか

Dobermanは、攻撃をどれだけ止め、無害な操作をどれだけ誤って止めるかを測る仕組みを公開しています。評価の文書によると、これは実際のエージェントを動かした試験ではなく、用意した道具の呼び出しの見本に対して、判定の仕組みだけを当てはめた試験です。主な結果を、評価の文書の数字のまま抜き出します。

評価の対象	攻撃の件数	攻撃が通った割合（守りなし→あり）	無害な操作を止めた割合
RedCode-Execのうち対象範囲内	720	100%→約1%（7件）	約6.7%（60件中4件）
LLMail-Inject（一回ずつ判定）	500	100%→100%	0%
LLMail-Inject（一連の流れで判定）	500	100%→5%（25件）	0%
独自の検知用の見本（標準の厳しさ）	130	検知できた割合は78%	約3%（38件中1件）

表から読み取れるのは、得意な型と苦手な型の差が大きいことです。危険な命令の実行を集めた見本ではほとんどを止めていますが、メールに紛れ込ませた指示の見本では、一回ずつの判定では一件も止められていません。独自の見本の内訳では、自然な文章による指示の紛れ込みの検知が0%で、開発元は「文書にした弱点」と位置づけています。

評価の文書自身も注意書きを付けています。承認待ちは壁ではなく引き綱で、人が中身を見ずにすべて承認すれば、守りの効果はなくなるとしています。一連の流れで判定した数字の多くは試験用の仕組みにしかない処理によるもので、配布されている版の既定の設定ではその検知は記録されないこと、範囲外として除いた攻撃の見本が1,410件中690件あることも書かれています。数字は開発元が条件を限って測った参考値として読み、自社の使い方で確かめ直すのが妥当です。

開発元が文書で認めている限界

Dobermanの限界をまとめた文書は、判定が一般的な脅威の見立てではなく、決まった規則に基づいていると前置きしています。そのため、規則ごとに守れる攻撃の型が決まっており、既知の隙間があります。主な点は、見た目の似た文字、秘密情報、大きなデータの塊、壊す命令の検知が既知の形にしか反応しないこと、誤検知を減らすために一部の判定を緩めた結果、形によっては秘密情報を見逃しうることです。

通信についても限界があります。外への通信は、命令の文字列から推し量って判定しており、接続が実際にどこへ向かうかは確かめられないとされています。実際に接続を閉じ込めるには、選んで有効にする別の仕組みが必要で、既定では動いていません。名前の問い合わせの仕組みを使った隠れた持ち出しのような経路は、ほとんど検知の対象外とされています。

ほかにも、状況に応じた判定の層はMCPの中継の経路でしか働かず、Claude CodeやOpenClawのフックでは決まった規則だけが使われること、パッケージの確認に使う一覧が小さな固定の一覧であることが挙げられています。さらに、手元の端末に入れる人は、フックを外せると明記されています。Dobermanが守るのは見張られているエージェントからの改ざんで、キーボードの前の人からではありません。言語モデルに判定させる審査役は測定用で、実際の判定には使われていないとも書かれています。

似た手段と何が違うのか

エージェントの危険な操作を抑える方法は、ほかにもあります。確認できた事実をもとに、止める場所の違いとして比べます。優劣ではなく、重ね方を考えるための比較です。

見る点	エージェントの設定で禁止	端末や実行の場を隔離する	Doberman
止める場所	エージェントの内側	エージェントが動く環境の外枠	エージェントと道具の間
見ている対象	道具の名前や許可の一覧	ファイルや網への出入り	一件ずつの道具の呼び出しの中身
人の承認	提供元の作りによる	仕組みによる	承認待ちとして組み込み、期限で拒否
規則の緩め方	設定を書き換えれば緩む	仕組みによる	本人確認と記録が必要
通信の行き先の確認	提供元の作りによる	接続の段階で制限できるものが多い	既定では命令の文字列から推し量るだけ

表のとおり、Dobermanが強いのは、道具の呼び出しを意味の単位で判定し、人の承認と記録を組み込める点です。逆に、実行が始まったあとのプログラムの振る舞いは静的な判定では見えないと、公式ドキュメント自身が書いています。隔離の仕組みとDobermanは、置き換えではなく重ねるものと考えるのが妥当です。開発元も、自らを多層防御の一つで、完全ではないと説明しています。

安全性の評価：注意付きとした根拠

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。Dobermanの判定は「注意付き」です。

前向きな事実から挙げます。ライセンスはApache-2.0で、READMEによると中核部分は独占的な依存を持たず、各リリースに部品の一覧（ソフトウェア部品表）が付きます。取り込んだだけで自動的に動く処理は、精査では見つかりませんでした。弱点の報告は非公開の窓口で受け付け、3営業日以内の受領、7日以内の初期評価を目標としています。

一方で、注意付きとした根拠は三つです。一つ目は、高深刻度のセキュリティ勧告（GHSA-4vvj-9m89-648r）が公開されていることです。二つ目は、運営する組織のアカウントが2026年8月24日に作られたばかりで、公開リポジトリは1件、会社名などの登録もない点です。三つ目は、本人がアルファ版と表示している点です。なお、勧告がない、あるいは修正済みであることは安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

高深刻度の勧告と、運営体制の注意点

勧告のページで内容を確かめました。勧告は2026年8月6日に公開され、深刻度は「高」、共通の評価基準CVSSの点数は7.1です。内容は、Windowsで動かした場合に、パスの表記の扱いに不備があり、保護しているはずのファイルに対して止める判定や承認待ちの判定を回避して、守られたエージェントが読み書きできてしまうというものです。Windows以外で動かしている場合でも、Windowsのファイルの領域を守っている構成は対象になると書かれています。それ以外の環境は対象外とされています。

対象はPyPIのパッケージで0.16.0以前の版、修正された版は0.17.0です。勧告によると、修正は保護の対象に一致するパスを増やす方向だけの変更で、減らすことはないとされています。部分的な回避策も示されていますが、勧告自身が完全ではないとし、更新を本来の対処としています。確認した時点の最新版は10月18日の0.19.0でした。なお、リリースの一覧では、8月15日の0.18.0の説明にもこの勧告とWindows形式のパスに関する修正が載っています。0.18.0以降を使えば、どちらの記載でも修正後の版に当たると読めます。

運営体制の面では、セキュリティ方針の文書が、修正は最新のリリースにだけ配り、古い版には個別に配らないと明記しています。リリースは7月から10月にかけて小刻みに出ており、その多くに検知のすり抜けを塞ぐ修正が含まれています。守りの仕組みそのものが、今まさに固められている途中と受け止めるのが現実的です。保守をボランティアが担っていること、利用状況の送信の既定が短い間に変わったことも、社内で使う段階かどうかを判断する材料になります。

悪用されうるリスク

Dobermanは守りのための道具で、攻撃のための道具ではありません。それでも、使い方しだいで生まれる危険はあります。最も大きいのは、「関門を入れたから、エージェントに何を任せても大丈夫」という安心が独り歩きすることです。判定は既知の型が中心で、自然な文章による指示の紛れ込みや隠れた通信経路には弱いと、開発元自身が書いています。

次に、古い版が残り続ける危険です。Windowsの勧告のように、守りの仕組みの穴は、そのまま守っているつもりのファイルが読み書きされる結果につながります。開発者の端末ごとに入れる性格の道具のため、端末によって版がばらばらになり、修正前の版が残ることは十分に考えられます。これは推測ですが、管理されていない端末ほど起こりやすいでしょう。

さらに、承認の運用が形だけになる危険があります。評価の文書が書くとおり、承認待ちは人が中身を見て初めて意味を持ちます。通知が多すぎれば、人は確かめずに承認するようになります。また、電話で承認する仕組みを使う場合は、命令の文字列が通知用のサーバーを通るため、その経路の扱いも検討の対象になります。なお、Dobermanが実際に悪用された事例は、2026年10月19日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

検討は、OSSを動かす前に、資料と社内の取り決めで確かめられることから始めます。下の手順は、動かす前の段階で終えられるものに絞っています。

この手順の要は、関門を入れることと、関門の限界を補う守りを同時に決めることです。判定の仕組みがどれだけ丁寧でも、見ていない経路が開いたままなら、守りは成り立ちません。

企業が取るべき対策

一つ目は、エージェントに与えている権限の棚卸しです。Dobermanを使うかどうかにかかわらず、エージェントが届くファイル、命令、鍵、外への通信を一覧にします。そもそもエージェントの手元に置かなくてよい鍵は置かないことが、どの関門よりも確かな守りです。

二つ目は、版の管理です。開発者の端末に入れる道具は、管理しなければ版が散らばります。使ってよい版の下限を決め、端末ごとの版を確かめる方法を用意します。三つ目は、承認の運用です。承認に回す操作を絞り込み、通知の量を、人が中身を見られる範囲に収めることが大切です。誰が承認者で、時間切れの記録を誰が見るかも決めます。

四つ目は、守りの重ね方です。通信の行き先を接続の段階で制限する仕組みや、実行の場の隔離を組み合わせ、Dobermanが文書で認めている弱点を補います。五つ目は、調達の際の確認です。アルファ版であること、保守がボランティアであること、運営する組織のアカウントが新しいこと、修正が最新版にしか配られないことを踏まえ、社内で使える段階かを文書で判断し、判断の理由を記録に残すようにします。

AIに任せる範囲と、人が決める範囲

Dobermanは、AIエージェントに開発の作業を任せるための守りの道具です。だからこそ、AIに判断させない部分を先に決める必要があります。開発元自身も、言語モデルの審査役を実際の判定には使わず、決まった規則と人の承認で判定する作りにしています。

人が決めるのは、どの操作を常に止めるか、どの操作を承認に回すか、誰が承認するか、規則を緩める変更を誰が認めるかです。AIに調査や下書きを手伝わせる場合も、判定の根拠を書かせ、人が確認する範囲を先に決めることで、後から判断を振り返れるようにします。やってはいけない向き合い方を挙げます。

• 関門を入れたことを理由に、エージェントに渡す権限や鍵を見直さない
• 勧告の修正前の版がWindowsの端末に残っていないかを確かめない
• 承認の通知を大量に流し、担当者が中身を見ずに承認する状態を放置する
• 見張るだけの状態のまま運用し、止めているつもりになる
• 公開されている評価の数字を、そのまま自社での防御率として説明する
• 規則を緩める本人確認の手段を複数人で使い回し、誰が緩めたか分からなくする

裏を返せば、人が決める範囲ははっきりしています。何を止め、誰が承認し、どの版を使い、どこを別の守りで補うか。これが決まっていないまま関門を置いても、守りの厚みは増えません。

• Dobermanの機能・版・限界・評価の数字は、GitHubのリポジトリとその中の文書、セキュリティ勧告のページ、リリースノート、公式ドキュメントを2026年10月19日に確かめた範囲に基づきます。アルファ版のため内容は変わる可能性があります
• 勧告の修正版は勧告のページの記載（0.17.0）に従いました。リリースの一覧では0.18.0にも関連の記載があります。導入の判断では最新の勧告とリリースノートを確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、勧告の回避の方法は扱いません

まとめ

Dobermanは、AIコーディングエージェントと道具の間に入り、すべての呼び出しを実行前に通す・承認待ち・止めるに振り分けるOSSです。迷ったら止める、規則は人の確認なしに緩めない、という二つの約束を掲げ、承認に応じなければ期限で拒否する作りになっています。Apache-2.0で公開され、Claude CodeやCodexなど複数のエージェントに対応しています。

一方で、判定は既知の型が中心で、自然な文章による指示の紛れ込みや隠れた通信経路には弱いと開発元が認めています。Windowsで保護したパスの判定を回避できる高深刻度の勧告があり、0.17.0で修正されています。運営する組織は新しく、保守はボランティアで、本人はアルファ版と表示しています。止める操作、承認する人、使う版、補う守りを先に決めたうえで検討することが、エージェントに開発を任せる時代のDobermanとの付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。