不安から、備えへ。
高度AI時代の、最初の一歩。

社会の不安を、少しでも減らしたい。

AIは素晴らしい技術です。しかし攻撃側もそれを使えます。問題はAIそのものではなく、社会の準備が追いついていないこと。Zeeが向き合うのは、攻撃能力の進化速度と、防御準備の普及速度の差です。

Zeeが有名になることが成功ではありません。社会が安定すれば成功です。誰かがより良い方法を作るなら、それでも良いと考えています。

機械の速度で動く攻撃が現れた。

脆弱性の「発見」と「武器化」が、安く・速く・大量になっています。以下はいずれも、AIを開発するAnthropic自身が公表した数字です。

準備・設計・研究方向と、動く軽量 MVP。

現段階の Zee が提供するのは、以下です。

AIスキル・MCP・パッケージを、
インストールする前にスキャン。

公開されている AI スキルや MCP サーバー、npm / PyPI パッケージには、エージェントを外部へ開かせるプロンプトインジェクションが仕込まれていることがあります。いま最も大きい攻撃面の一つです。Zee の入口ゲートは、導入する前にその成果物を隔離下で静的に検査し、不審な指示・過剰な権限要求・既知の脅威リスト該当を洗い出して、入れる／入れないの判断材料を返します。

静的検査であり、すべての悪意を検出できるわけではありません（正直に）。Semgrep / Snyk / Socket を置き換えるものではなく、それらと併用する一層です。GitHub Action として CI / pre-install に組み込めます。詳細は docs/gate.md ／ 脅威リストの形式は docs/threat-list.md を参照してください。

既定 dry_run。明示昇格まで実遮断はしない。

Zee は侵入を防ぐ層ではなく、侵入後に狭く高信頼な検知信号（囮への接触）を1本足す層です。「あなたの検知体制全般」を肩代わりするものではありません。

検知能力マトリクス

macOS・Windows は OS の制約で「読み取り検知」が直接できません。環境変数 ZEE_CANARY_BASE_URL に外部 webhook 受信器の URL を設定すると、seeder が囮ファイルに canary URL を埋め込み、攻撃者がその URL を辿った瞬間に外部受信器で発火します（Zee 本体には戻りません・out-of-band）。未設定では canary URL は埋め込まれず、macOS / Windows での「読むだけ」の攻撃は観測されません（既定で安全側）。Linux は inotify が読み取りも直接観察するので canary 不要です。
受信器の例：Canarytokens.org（無料・推奨）／自前 Cloudflare Worker・AWS Lambda・Vercel Edge Function 等。

意図する5つの層と、実装の現在地。

それぞれが単独でも働く設計を意図しています。実装状況はそれぞれ正直に表示します。

何を守り、何を守らないか。

※「防御率○%」のような数字は出しません。実環境はそれほど単純でなく、誇張は信頼を損なうためです。

取得しない設計。

• 現 MVP は 攻撃者の IP を取得・保存しません（watcher / responder / telemetry のいずれの経路でも IP やPII を扱いません）。記録するのは「どの囮に・いつ・どの種類（read / change）の接触があったか」と遮断レイテンシだけです。
• canary URL は operator が指定した外部エンドポイント（自前 webhook 受信器・Canarytokens.org・AWS Lambda 等）で発火します。発信元 IP がそこで捕捉されえますが、それは Zee の外側であり、operator が選んだ外部エンドポイントのプライバシー方針の責任範囲です。
• 蓄積データは期限を過ぎると自動的に削除する（設計目標）。
• 相関を追加する場合は「個人」ではなく「セッション」を軸とする。

将来 IP 取得経路を追加する場合の方針（末尾オクテット切り捨てを第一候補とし、ハッシュ化は逆引き耐性が崩れるため採用しない）は ARCHITECTURE.md を参照してください。

失敗条件を先に書いておきます。

• 侵入そのものは防がない — 入口防御（ファイアウォール・EDR・パッチ）の役割を置き換えるものではありません。
• 検知中心・既定 dry_run — 自動の封じ込め機構は資産プロファイルで response_mode: auto を明示し dry_run: false にしたときだけ動きます。
• 自動遮断は「変更系の接触」のみ — open / read / 属性参照などの読み取り系は自動遮断しません。通知のみで、必要なら zee cut <asset_id> で手動遮断します。プロセス特定ができない現バックエンドでは、正規ソフトが普通やらない操作だけを自動遮断の根拠にするのが構造的に安全だからです。
• macOS / Windows の読み取り検知は ZEE_CANARY_BASE_URL 設定時のみ — kqueue / ReadDirectoryChangesW は read を通知しません。環境変数を設定すると seeder が canary URL を decoy に自動埋め込みし、外部受信器で発火します（Zee 本体には戻りません）。未設定では canary URL は埋め込まれず、macOS / Windows での「読むだけ」の攻撃は観測されません。Linux は inotify で read を直接観察するので canary 不要です。
• プロセス allowlist は現バックエンドでは効かない — 誤検知制御は「配置ガイド」＋「変更系トリガー限定」で行います。allowlist 路線は v4 で撤回しました（v2 で同梱した既定 allowlist と auto+dry_run:false ハードブロックも撤回）。
• zee restore には restore_token が必要（v0.3 から） — zee init-restore-token で生成したトークンを --token または ZEE_RESTORE_TOKEN で渡します。同一ユーザーで動作する別シェルからの誤った巻き戻しは塞げますが、~/.zee/restore_token（0600）を読める root 相当の攻撃者にはバイパスされます。マルチユーザー本番では sudo で囲うか専用ユーザーで運用してください。
• イベントログは decoy_ref（asset_id#index）で記録（v0.3 から） — 絶対パスは記録されないため、ログを読まれても囮位置は一括列挙できません。対応関係は assets.toml 経由でのみ復元できます。
• 限界がある — 機械の速度で動く相手や、ごく小さく具体的な秘密（単一の API キーなど）の保全は、Zee の範囲を超えます。
• 検証の範囲 — 入口ゲートの判定は合成検体による社内の再現試験とテストスイートで（自然文の言い換えによる指示すり込みは、未知の検体の盲検試験で検出できていません）、囮・封じ込めはテストスイートと隔離した macOS 環境での dry_run の実演（v0.10.1 付近の版で実施）で確認しています。専門家・第三者機関による独立評価は受けておらず、OS のファイアウォールに対する実遮断（dry_run: false）の試験は未実施です。結果と条件は docs/verification/。本番運用の前に、ご自身の環境でも確認してください。

これは床であって天井ではありません。安全だと言う前に、失敗条件を先に書きました。
全 Limitations は README の Limitations セクション を参照してください。

Zee は seed 型 OSS。育てるのは皆。

Zee はメンテナがリファレンス実装と設計を公開して終わりにする seed（種まき）型 OSS です。あなたの環境で動かす、OS の更新に追従させる、業種に合わせて改造するのは 各自。一人の管理者が永続的に全 OS を追従する OSS のメンテナ疲れ問題から最初から外れます。

代わりに、修正の知恵を皆で共有する場 が用意されています。次に同じ問題に当たった人の作業を 3 時間 → 30 秒 に縮めるのが目的です。

全部この場で、オープン。

Zee は MIT ライセンスのもとで、すべての文書とコードを GitHub で公開しています。クラウド契約や外部サービス登録は不要です。

万能ではありません。Zee は“もう一層”です。

無料で使えます。応援は任意です。

Zee は無料です。もし役に立ったら、GitHub Sponsors からの支援を歓迎します。