CC Safety Net は LLM を使いますか？
使いません。判定はすべて、ローカルのルールベースのパーサーが行います。コマンドを実行ファイル、サブコマンド、フラグ、引数に分解し、固定のルールを適用します。コマンド、作業ディレクトリ、設定が同じなら、判定は常に同じです。モデルにもネットワークにも何も送らないため、プロンプトの書き方でブロックを許可に変えることはできません。1 つのツール呼び出しのライフサイクル
1
エージェントがツール呼び出しを準備する
エージェントが
git reset --hard のようなシェルコマンドや、ファイルの書き込み・編集・検索・パッチを用意し、自身のツール層に渡します。2
連携が呼び出しをインターセプトする
そのエージェント用の CC Safety Net の連携が、ツールの実行前に呼び出しを受け取ります。受け取り方はエージェントによって異なります。連携方式を参照してください。
3
CC Safety Net が操作を検査する
CC Safety Net は入力を 1 回だけ解析し、検査の順序に示す検査を実行します。
4
許可またはブロックが返る
許可された呼び出しは通常どおり実行されます。ブロックされた呼び出しは実行されず、エージェントはツールの結果としてブロックメッセージを受け取ります。
5
判定が記録される
判定はローカルの監査ログに記録されます。
連携方式
CC Safety Net は 4 つの連携方式で 16 のエージェントに対応しています。どの方式でも検査の内容は同じで、同じ呼び出しには同じ判定が出ます。
保護されるツールと設定の場所は、「インストール」にある各エージェントのページに載っています。同じ検査を自分の Node.js プログラムから呼び出す方法は、ライブラリ API を参照してください。
検査の順序
どのツール呼び出しも、同じ段階を次の順に通ります。- 上限付きの入力抽出。 深さ、フィールド数、サイズに上限を設けたうえで、ツール入力からコマンドを読み取ります。上限を超えた入力はブロックします。
- 1 回だけの解析。 コマンドを 1 回だけ解析し、後続のすべての段階がその結果を使い回します。パーサーの処理上限を使い切った入力は、どの安全レベルでもブロックします。
- ポリシーファイルの保護。 CC Safety Net 自身の
policy.json、そのディレクトリ、上位ディレクトリを変更・削除しようとする操作をブロックします。 - Git メタデータの保護。 リポジトリの
.gitメタデータやフックディレクトリを削除・移動・上書き・パッチしようとする操作をブロックします。作業ディレクトリの中から行う操作も対象です。 - 設定の読み込み。 ポリシー、ルールブック、安全レベルを解決します。
- 機密パスの保護。 コマンド、パス、検索、パッチを、組み込みの機密の場所（
.env、~/.ssh、クラウドやコーディング CLI の資格情報ファイル）と、設定した拒否パスに照らして検査します。 - 破壊的コマンドの解析。 コマンドをセグメントに分割し、ラッパーとインタープリターを展開します。そのうえで、該当するアナライザーが各セグメントを分類します。アナライザーの対象は
git、rm、Remove-Item、find、xargs、parallel、デバイス系コマンド、カスタムルールです。
アナライザーが見抜く書き方
コマンドを別のコマンドの中に隠しても、手順 7 はすり抜けられません。- ラッパーとインタープリター。
sh -c、bash -c、sudo、env、python -cやnode -eのワンライナーを展開し、中のコマンドを最大 10 階層まで解析します。それより深いネストはブロックします。シェルラッパーとインタープリターのワンライナーを参照してください。 - 1 つのコマンド内の
cd。cd dir && rm -rf xはdirを基準に判定します。解決できないcdがあると、それ以降の対象は検証できなくなります。ファイルシステムコマンドを参照してください。 - シェル関数。 関数の本体は呼び出し位置で検査するため、
cleanup() { rm -rf ../outside; }; cleanupはブロックされます。定義だけで呼び出さない場合は許可されます。ファイルシステムコマンドを参照してください。 - heredoc。
cat > note.md <<'EOF'はデータを書き込むだけなので、本文の内容にかかわらず許可されます。bash <<'EOF'のように、シェルが heredoc をプログラムとして実行する場合は、本文のコマンドを 1 つずつ解析します。strict と paranoid での heredoc を参照してください。 - シェルスクリプト。
sh x.sh、source x.sh、./x.shが実行するスクリプトは、同じコマンド内の heredoc が書いたものでも、すでにディスク上にあるものでも、中身を読んで解析します。ブロックの理由には、ファイルと行番号を示します。python3 tool.pyのようなインタープリター向けのファイルは読みません。ファイルから実行するスクリプトを参照してください。 - 複合コマンド。
if、while、until、{ …; }の本体にあるコマンドも、トップレベルのコマンドと同じように検査します。そのためif true; then rm -rf ~; fiはブロックされます。 - 動的な対象。
rm -rf "$target"のように変数や置換で組み立てた対象は、実行前に検証できません。standard では許可し、strict と paranoid ではブロックします。ファイルシステムコマンドを参照してください。
文字列一致ではなく意図で判定する理由
CC Safety Net は、コマンドが実際に何をするかで判定します。先頭の語が同じでも、結果が分かれることがあります。
どちらも
git checkout で始まるため、前方一致のルールでは、Git のオプション解釈を作り直さないかぎり区別できません。コマンドを解析すれば、フラグの順序の入れ替え（rm -r -f /）、シェルラッパー（sh -c "rm -rf /"）、インタープリターのワンライナー（python -c 'import os; os.system("rm -rf /")'）も検出できます。
何を止め、何を止めないかはブロック・許可されるコマンドにまとめています。
ブロック時の表示
エージェントは、ツールの結果としてブロックメッセージを受け取ります。Rule: 行には、呼び出しをブロックしたルールまたは固定の拒否の ID が入ります。この行が付かないのは、フックの入力がない、または有効な JSON でない呼び出しをブロックした場合だけです。コマンドとセグメントのテキストは短縮され、メッセージ全体からシークレットがマスクされます。
次の行は、該当する場合だけ付きます。
ブロックによってエージェントのセッションが終わることはありません。最後の指示はルールの意図（
intent）によって決まり、別の書き方を試すのではなく本来のタスクに戻るようエージェントを促します。
コマンドは実行されないため、ブロックそのものはエージェントがこの指示に従うかどうかに左右されません。
ブロックせずに確認を求める場合
Claude Code では、standard モードで検証できなかったコマンドは、ブロックではなく権限確認のプロンプトとして届きます。メッセージの項目は同じで、最初と最後の行だけが変わります。監査記録
CC Safety Net は、すべての拒否と、既定では許可したコマンドの判定もローカルの監査ログに記録します。ログはnpx cc-safety-net logs で読めます。場所、フィールド、保持期間、マスク処理は監査ログのリファレンスを参照してください。
判定が予想と異なる場合
1
理由を確認する
npx cc-safety-net explain "<command>" は解析を再現し、どのルールがなぜ一致したかを表示します。構造化されたトレースが必要なら --json を付けます。2
3
設定を調整する、または報告する
ブロックは正しいものの自分のワークフローには厳しすぎる場合は、安全モードを変えるか、ルール単位のオーバーライドを追加します。安全なコマンドがブロックされた場合や、破壊的なコマンドがブロックされなかった場合の報告先は、トラブルシューティングとセキュリティポリシーを参照してください。