AIエージェントによる情報の持ち出しをOSS「Lilith Zero」はどう止めるのか

「社内でAIエージェントに道具をつなぎ始めたが、勝手に社外へ情報を送られたらどう止めればよいのか」「AIの判断に任せず、決めた規則で確実に止める仕組みはないのか」——AIエージェントの試験導入を任された情報システム部門から、最近よく聞く声です。AIエージェントは、MCP（AIと外部の道具をつなぐための共通の取り決め）を通して、ファイルを読み、ウェブを調べ、外部へ送信します。便利になるほど、一つの指示が届く範囲は広がります。ここで問われているのは、AIを賢くすることではありません。本当は、AIが何をしようとしても、許していない道具の呼び出しは仕組みの側で止まる状態をつくれるかという問題です。この記事では、その問いに答えようとするOSS「Lilith Zero」が何をどう止めるのか、どこまでが確かめられた事実で、どこからが未確認なのかを、2026年10月時点の公開情報をもとに整理します。導入や設定の方法は扱いません。

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

Lilith Zero は、GitHub で公開されているソフトウェアです。リポジトリの説明によれば、MCPの道具の呼び出しに対する安全のための中間層で、Rust という言語で書かれています。AIエージェントと、エージェントが使う道具（MCPサーバー）の間に入り、行き来するやり取りを点検して、通してよいものだけを通す役割を持ちます。

公開の状況を、2026年10月23日に確かめた範囲で並べます。リポジトリの作成は2026年1月、最初の版0.1.0が2026年2月16日、最新の版0.2.2が2026年4月26日に公開され、これまでに6つの版が出ています。コードの最後の更新は2026年7月下旬です。スターは23、派生は3と、利用者の広がりはまだ小さい段階です。

ライセンスはApache-2.0です。これはOSI（オープンソースの定義を管理する団体）が承認したライセンスで、この記事で「OSS」と呼ぶ根拠になっています。商用での利用や改変も認められますが、利用条件や免責の範囲は、導入時にライセンス本文で確かめてください。

提供しているのは BadCompany と名乗る組織で、公式サイトでは「AIエージェントのための強制的な利用制御」をうたう製品群の一部として、Lilith Zero をオープンソース版と位置づけています。サイトには料金や有料版の説明は見当たらず、有料の製品と無料のOSSの境目がどこにあるかは、2026年10月時点で確認できる情報が限られる状態です。

なぜ今、道具の呼び出しに関所が必要とされるのか

AIエージェントが広がるにつれ、問題の中心は「AIが何を答えるか」から「AIが何を実行するか」へ移りました。エージェントは、読み込んだ文書やウェブの内容に紛れ込んだ命令に引きずられることがあります。いわゆるプロンプトインジェクション（外部の文章に仕込まれた指示でAIを操ること）です。答えを間違えるだけなら人が気づけますが、道具を通して社外へ送信してしまえば取り消せません。

特に危ういとされるのが、三つの条件がそろう場面です。社内の機密に触れられること、外部の信頼できない内容を読み込むこと、そして外へ情報を送れること。この三つが一つのエージェントにそろうと、外から仕込まれた命令で機密が持ち出される経路ができてしまいます。Lilith Zero のREADMEも、この「機密に触れる、信頼できない内容に触れる、外へ送る」の順の流れを自動で止めることを中心の機能の一つに挙げています。

こうした危険に対して、AIの側に「怪しい命令は断る」よう教える対策もあります。ただ、断るかどうかはモデルの版や頼み方で揺れ、設計上の保証にはなりません。そこで、AIの外側に、AIの判断とは無関係に動く関所を置くという考え方が注目されています。Lilith Zero は、その関所を一つの部品として提供しようとする試みです。

仕組みの土台：既定で拒否し、AIに判断させない

Lilith Zero の設計で最も目立つのは、既定ではすべてを拒否するという方針です。READMEによれば、規則の定義が無い、読み込みに失敗した、内部で異常が起きた、といった場合には、すべてのやり取りを止める作りになっています。壊れたときに開くのではなく閉じる、という考え方で、安全のための部品としては筋の通った選び方です。

もう一つの特徴は、判断にAIや推測を使わないことです。READMEは、道具の種類（機密を読む道具か、外へ送る道具か、など）は規則の中で人が明示的に宣言し、実行時に推測で分類することはしない、と説明しています。つまり、同じ入力には必ず同じ判断を返す、決定的な仕組みを目指しています。

これは長所でも短所でもあります。判断が揺れないので、なぜ止まったか、なぜ通ったかを後から説明しやすくなります。一方で、規則に書かれていない危険は見逃されるということでもあります。道具の分類を誤れば、その誤りのまま忠実に動きます。関所の強さは、規則を書く人の目の確かさに左右されます。

主な機能1：道具ごとの許可と、引数まで見る規則

いちばん基本の機能は、道具の名前や、道具が触れる対象の場所ごとに、許可と拒否を固定で決めておくことです。READMEはこれを、決まった許可・拒否の対応表として説明しています。たとえば「この道具は使わせない」「この場所のファイルには触れさせない」といった線を、エージェントの外で引けます。

さらにREADMEによれば、道具を呼ぶときに渡される中身（引数）の値まで見て判断する規則も書けます。同じ道具でも、渡す値によって通すか止めるかを変えられるということです。道具を丸ごと禁じるのではなく、危ない使い方だけを止める細かさが出せる点は、業務で使う道具を活かしたまま守りたい場面で意味があります。

ただし、細かく書けるほど規則は複雑になり、誤りも入りやすくなります。どこまで細かく書くかは、守りの強さと保守の手間の釣り合いで決める必要があります。規則そのものを変更するときの承認と記録の手順を、道具の導入と同時に決めておくのが現実的です。

主な機能2：機密に触れた後の送信を止める「汚れの追跡」

Lilith Zero が中心に据えるもう一つの機能が、READMEで「汚れの追跡」と呼ばれる仕組みです。やり取りの単位（セッション）ごとに「機密に触れた」「信頼できない内容を読んだ」といった印を付けていき、その印の状態によって、後の道具の呼び出しを止めるかどうかを決めます。

前の章で触れた三つの条件の流れを止めるのが、この仕組みの役目です。一度機密に触れ、続けて外部の内容を読み込んだセッションでは、外へ送る道具の呼び出しを止める、という形です。個々の呼び出しだけを見ていると見逃す「一つずつは問題ないが、続けると持ち出しになる」流れを、セッション全体で捉えようとする点が、単純な許可表との違いです。

READMEによれば、利用する道具の仕組みによっては呼び出しのたびに Lilith Zero が起動し直すため、この印の状態を利用者の端末の中のファイルに保存して引き継ぐとされています。ここから先は推測ですが、印を保存したファイルが書き換えられれば判断も変わりうるため、保存場所の権限や、端末を共有する使い方には注意が要る可能性があります。

主な機能3：署名つきの記録と、子の処理の見張り

READMEによれば、Lilith Zero は通した・止めたという判断をすべて記録し、その記録には改ざんを見抜くための署名が付きます。後から記録を書き換えられていないかを確かめられるので、「AIが何をしようとして、何が止められたか」を事後に説明する材料になります。監査や事故の調べの場面で役立つ機能です。

また、Lilith Zero が道具の処理を子として立ち上げる使い方では、親が終わったときに子だけが残り続けないよう、各基本ソフトの仕組みで見張るとされています。放置された道具の処理が裏で動き続けることは、それ自体が穴になりうるため、地味ですが意味のある配慮です。

このほか、やり取りの大きさに上限を設けて大きすぎるものを読む前に捨てる、別の処理をまたいで動きを追跡する仕組みと連携する、といった機能も挙げられています。処理の遅れは1ミリ秒未満とREADMEは説明していますが、性能の数値は提供元が自ら測ったもので、第三者による検証は確認できない点は押さえておいてください。

どこに組み込むものか。つなぐ先として挙げられている道具

READMEは、Lilith Zero を組み込める先として複数の道具を挙げています。Claude Code や GitHub Copilot の各種の利用形態で、道具を呼ぶ前後に外部の点検を挟める仕組み（フック）と組み合わせる形、OpenClaw という別のエージェント基盤では道具の処理を包み込む形、そして Microsoft の業務用エージェント作成の仕組みに向けた外部の点検窓口として動かす形です。

つまり Lilith Zero は、特定のAIエージェント専用ではなく、複数のエージェントに共通の関所を置くことを狙っています。社内で複数のAIの道具が混在しているなら、同じ規則で見張れることは管理の手間を減らします。ただし、組み込み先ごとに受け渡しの形が違うため、実際に同じ強さで守れるかは組み込み先ごとに確かめる必要があります。

README には、OpenClaw について公表された139件の勧告と Lilith Zero の対策との対応表がある、とも書かれています。これは提供元自身による整理であり、その対応が実際の攻撃で有効かは第三者の評価を確認できていません。対応表は、自社で検証するときの手がかりとして読むのが適切です。

なお、この記事では組み込み方や設定の書き方には触れません。組み込みの作業は、利用するエージェントの設定に手を入れることを意味し、誤れば守りのつもりで穴を空けることにもなります。必ず検証用の環境で、社内の手順に沿って進めてください。

想定される使い方と、向く場面・向かない場面

Lilith Zero が向くのは、AIエージェントに業務の道具をつなぎ、その呼び出しを規則で縛りたい場面です。たとえば、開発者がAIのコーディング支援を使う環境で、社外への送信や特定の場所のファイル操作を止めたい場合や、業務用のエージェントに外部の道具をつなぐ前に、許可の範囲を仕組みで固めたい場合が考えられます。

一方で向かないのは、何を止めるべきかがまだ決まっていない段階です。Lilith Zero は推測で危険を見つける道具ではなく、人が決めた規則を確実に守らせる道具です。規則を書く前提となる「どの道具が機密を読み、どの道具が外へ送るか」の棚卸しができていなければ、効果は出ません。

また、道具の呼び出しを経由しない危険は対象外です。AIの回答の文章そのものに機密が含まれて画面に表示される、といった経路は、道具の関所では止められません。Lilith Zero は守りの一部品であり、利用者への教育や、扱う情報の区分と組み合わせて初めて意味を持ちます。

類似の手段とどう違うか

AIエージェントの道具の呼び出しを守る手段はいくつかあります。Lilith Zero の立ち位置を、代表的な手段と並べて整理します。下の表は一般的な比較で、個別の製品の評価ではありません。

手段	止める仕組み	強み	弱み・注意点
AIの側の断り（モデルの安全対策）	モデルが怪しい依頼を断る	追加の部品が要らない	頼み方や版で揺れ、保証にならない
AIで判定する防護フィルタ	別のAIが入出力の危険を判定する	規則に無い危険も拾える可能性	判定が揺れ、理由の説明が難しい
Lilith Zero のような規則型の関所	人が書いた規則で呼び出しを通す・止める	判断が一定で説明しやすい。既定で拒否	規則に無い危険は見逃す。規則の質が全て
隔離した実行環境	エージェントを囲いの中で動かす	行きすぎても被害が外に出にくい	囲いの中で許した範囲の操作は防げない

表のとおり、どの手段にも穴があります。Lilith Zero のような規則型の関所は、判断の一定さと説明のしやすさが強みで、AIで判定する仕組みとは得意なところが逆です。現実的には、隔離した環境の中でエージェントを動かし、その出入りを規則型の関所で縛り、人の確認を最後に置く、という重ね方が考えられます。

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

このラインでは、OSSを記事にする前に、公開情報だけを使って安全性を精査しています。Lilith Zero の判定は「注意付き」です。根拠は次のとおりです。まず、ライセンスはApache-2.0で、2026年10月23日時点で、このリポジトリに公開されたセキュリティ勧告は見当たりませんでした。

注意点は二つです。一つ目は、リポジトリの最上位に、導入用の命令の書かれたファイル（基本ソフトごとの導入用の台本）と、コンテナを作るための定義ファイルが置かれていることです。こうしたファイルは、中身を読まずに実行すると、何が端末に入るかを利用者が把握できないという一般的な危うさがあります。このラインではOSSを入手も実行もしていないため、中身の安全性までは確かめていません。

二つ目は、提供元の実績の乏しさです。提供元の組織のアカウントは2025年10月に作られ、公開しているリポジトリは9つ、フォロワーは8です。Lilith Zero のスターは23で、利用者が多く、多くの目で点検されているとは言えません。安全のための部品を、実績の浅い提供元から取り込むことになる点を、判断の材料として明示しておきます。

なお、問題が見つからなかったことは、安全の保証ではありません。この判定は公開情報から読み取れる範囲のもので、コードの中身を監査したものではない点に留意してください。

注意点の詳細：運営体制と、自己申告の保証

Lilith Zero のREADMEとセキュリティ方針の文書は、形式的な証明、壊れた入力を大量に与える試験、依存部品の監査、攻撃を想定した試験群など、多くの品質の取り組みを挙げています。取り組みの多さ自体は評価できますが、いずれも提供元の自己申告で、第三者の監査の結果は確認できません。

セキュリティ方針の文書には、弱点を見つけたときの連絡先と、公開の場で報告しないよう求める方針が書かれています。一方で、どの版を保守の対象にするのか、報告からどれくらいで対応するのかは書かれていません。企業で使う部品としては、弱点が見つかったときにどの版まで直してもらえるかが読めない点は、導入前に確かめるべき事項です。

更新の状況にも目を向けておきます。最新の版は2026年4月で、コードの最後の更新は2026年7月下旬です（2026年10月時点）。半年ほど新しい版が出ていない状態で、開発が続くかどうかは現時点では判断できません。関所のような部品は、守る相手の手口に合わせて更新が要るため、保守が止まると価値が下がりやすい点に注意が要ります。

もう一点、組織名の BadCompany は、名前だけ見ると誤解を招きかねません。公式サイトとリポジトリが同じ組織を指していることは確かめられますが、名前の似た偽物の配布物と取り違えないよう、入手元は公式のリポジトリに限り、配布物と元のコードの対応を確かめることを勧めます。

悪用されうるリスク

Lilith Zero は守るための道具ですが、守りの部品だからこその危うさもあります。ここでは概要にとどめます。第一に、関所が「守られている」という安心を生み、他の対策が手薄になる危険です。規則に穴があれば、関所があっても持ち出しは起きます。

第二に、関所そのものが狙われる可能性です。すべての道具の呼び出しが通る場所は、裏を返せば、そこを乗っ取れば全体を操れる場所でもあります。提供元のセキュリティ方針も、規則のすり抜けや汚れの追跡の回避を、報告を受け付ける対象に挙げています。これは、そうした弱点が理論上ありうると提供元が認識していることを示します。実際にそうした弱点が見つかったという報告は、2026年10月時点で確認できていません。

第三に、配布の経路の危うさです。一般論として、利用者の少ないOSSは、名前を似せた偽の配布物や、乗っ取られた配布経路の標的になりえます。守りの部品ほど端末の深いところに入るため、偽物をつかまされたときの被害は大きくなります。これは Lilith Zero に特有の話ではなく、守りの道具を外から取り込むとき全般の注意です。

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

Lilith Zero を評価してみたい場合に、どの順で確かめるとよいかを整理します。操作の手順ではなく、判断の段取りです。

この段取りで特に大切なのは、検証の段階です。止めたいものが止まることと同じくらい、壊れたときに閉じることを確かめる必要があります。既定で拒否という設計が、自社の組み込み方でも実際に効いているかは、説明書きではなく検証で確かめるものです。

企業が取るべき対策

Lilith Zero を導入するかどうかにかかわらず、AIエージェントに道具をつなぐ企業が整えておきたい対策を挙げます。

• エージェントにつなぐ道具の一覧を作り、機密を読む・外部を読む・外へ送るの区分を付けて管理する
• 三つの条件（機密・外部の内容・外への送信）が一つのエージェントにそろう構成を、原則として作らない
• 道具の呼び出しの記録を残し、改ざんされない場所に保管して定期的に見る
• 守りの部品を外から取り込むときは、提供元の実績・保守の体制・弱点への対応の方針を調達の確認項目に入れる
• 関所や防護フィルタに頼り切らず、隔離した実行環境と人の承認を重ねる

これらは、特定の製品に依存しない対策です。Lilith Zero のような道具は、このうち「規則で止める」部分を仕組みにする選択肢の一つにすぎません。道具を選ぶ前に、何を止めたいのかを社内で言葉にしておくことが先です。

社内規程に落とし込むなら、「エージェントに新しい道具をつなぐときは、区分を付けて申請する」「外へ送る道具をつなぐときは、責任者の承認を得る」といった項目が考えられます。仕組みで止める前に、つなぐこと自体を人の承認の対象にするのが、最も確実な関所です。

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

Lilith Zero の設計は、AIに判断させないことを明確に選んでいます。この考え方は、道具を使うかどうかに関係なく、AIエージェントを業務に入れるときの基本の姿勢として参考になります。AIに任せてよいのは、決められた範囲の中で、取り消せる作業を速く進める部分です。

人が決めるべきは、どの道具をつなぐか、どの呼び出しを止めるか、規則をどう変えるか、そして記録を見て何を直すかです。AIに規則の下書きを作らせる場合でも、なぜその規則にしたのか根拠を書かせ、人が確認してから採用することが欠かせません。人が確認する範囲を先に決めておけば、AIの提案に流されることを防げます。

• 関所を入れたことで安心し、つなぐ道具の棚卸しや人の承認を省く
• 規則の作成をAIに任せ、根拠を確かめずにそのまま本番に使う
• 導入用の台本やコンテナの定義を、中身を読まずに本番の端末で実行する
• 検証をせず、既定で拒否という説明書きだけを信じて異常時の動きを確かめない
• 署名つきの記録を取るだけで、誰も見ないまま放置する

よくある質問

Lilith Zero を入れれば、AIエージェントからの情報の持ち出しは防げますか

防げるのは、規則で止めると決めた道具の呼び出しを経由する持ち出しです。規則に無い経路や、道具を使わずにAIの回答そのものに機密が含まれる経路は対象外です。隔離した環境や人の承認と組み合わせる前提で考えてください。

無料で使えるなら、まず試してみてもよいですか

ライセンスはApache-2.0で、利用の自由度は高い部類です。ただし、提供元の実績は浅く、保守の方針も明示されていません。試すなら、本番の資格情報や機密を置かない検証用の環境に限り、導入用の台本の中身を社内で確かめてから扱ってください。

AIで判定する防護フィルタとどちらがよいですか

得意なところが違います。規則型は判断が一定で説明しやすい一方、規則に無い危険は見逃します。AIで判定する仕組みは想定外の危険を拾える可能性がある一方、判定が揺れます。どちらか一方ではなく、重ねて使い、最後に人の確認を置くのが現実的です。

• Lilith Zero の機能・構成・組み込み先・性能の数値は、公式リポジトリのREADMEとセキュリティ方針の文書を2026年10月23日に確かめた範囲に基づきます。性能や品質の取り組みは提供元の自己申告です
• 版の履歴・スター数・提供元のアカウントの作成時期は2026年10月23日時点の値で、変わることがあります
• このラインではOSSを入手・実行しておらず、コードの監査もしていません。問題が見つからなかったことは安全の保証ではありません

まとめ

Lilith Zero は、AIエージェントとMCPの道具の間に入り、人が決めた規則に沿って呼び出しを通すか止めるかを決めるOSSです。既定ですべてを拒否し、AIや推測に判断を委ねず、機密に触れた後の外部送信をまとめて止める仕組みを持つ、とREADMEは説明します。AIの判断に頼らず仕組みの側で止めるという考え方は、AIエージェントを業務に入れる企業にとって参考になります。

一方で、提供元の組織は2025年10月に作られたばかりで、スターは23、性能や品質の取り組みは自己申告です。保守の対象の版や弱点への対応の速さも明示されていません。導入を考えるなら、道具の棚卸しから始め、検証用の環境で止まることと壊れたときに閉じることを確かめ、規則の変更と記録の確認を人が担う体制を先に作ってください。関所はあくまで守りの一部品で、何を止めるかを決めるのは人です。

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