Skip to main content
CC Safety Net は、コーディングエージェントと保護対象ツールの間にあります。対応する各ツール操作を実行前に検査します。その後、操作を許可するか、エージェントが対応できるブロック結果を返します。このページでは、1 つのツール呼び出しを最初から最後まで説明します。 各エージェントを CC Safety Net に接続する連携については、連携アーキテクチャを参照してください。

1 つのツール呼び出しのライフサイクル

1

エージェントがツール呼び出しを準備する

エージェントは、git reset --hard などの shell コマンド、またはファイルの書き込み、編集、検索、patch を実行すると決定し、ツールレイヤーに渡します。
2

連携がツール呼び出しをインターセプトする

そのエージェント用の CC Safety Net 連携が、ツールの実行前かつオペレーティングシステムが処理する前に呼び出しを受け取ります。一部のエージェントは、CC Safety Net を短時間の subprocess hook として呼び出します。その他のエージェントは、プロセス内のプラグインまたは拡張機能として読み込みます。どちらの場合も同じ guard が動作します。各エージェントが使用する方式については、連携アーキテクチャを参照してください。
3

CC Safety Net が操作を確認する

CC Safety Net は、深さ、サイズ、フィールド数の上限を適用してツール入力を読み取ります。入力を 1 回解析し、確認する順序に示す固定手順を実行します。順序はエージェントによって変わりません。
4

許可またはブロックの結果を返す

安全な呼び出しは許可され、通常どおり実行されます。ブロックされた呼び出しは実行されません。エージェントは、理由、問題のコマンド、次に実行すべきことを示すブロックメッセージを受け取ります。ブロック結果の形式を参照してください。
5

判定を監査できる

拒否はローカル監査ログに追加します。対象となる許可済みコマンド判定も、設定済みの監査 scope に含まれる場合は記録します。監査記録を参照してください。

確認する順序

すべてのツール呼び出しは、次の順序で同じ段階を通ります。
  1. 上限付き入力抽出。 深さ、node 数、key 数、サイズの走査上限を適用して、ツール入力からコマンドを読み取ります。上限を超える呼び出しは、無制限の走査を防ぐためにブロックします。
  2. 1 回の解析。 コマンドを 1 回解析し、後続のすべての段階が再利用する構造的事実を作成します。parser の作業予算を使い切ると、すべての安全レベルで呼び出しをブロックします。
  3. ポリシーファイル保護。 CC Safety Net 自身の policy.json、そのディレクトリ、または祖先を変更または削除するすべての操作を停止します。
  4. Git メタデータ保護。 リポジトリの .git メタデータまたは hooks ディレクトリを削除、移動、上書き、patch するすべての操作を停止します。作業ディレクトリ内からの操作も対象です。
  5. 設定の読み込み。 ポリシー、rulebook、安全レベルを解決します。
  6. 機密パス保護。 コマンド、パス、検索、patch を、組み込みの機密場所(.env~/.ssh、cloud およびコーディング CLI の認証情報ファイル)と設定済み deny path に照らして確認します。
  7. 破壊的コマンド解析。 コマンドを segment に分割し、wrapper と interpreter を展開し、各 segment を対応する analyzer で分類します。対象は gitrmRemove-Itemfindxargsparallel、device コマンド、およびカスタムルールです。
手順 3 と 4 は、意図的に手順 5 のに実行します。この 2 つの保護は常に有効であり、設定を読み取る前に適用されるため、設定で弱めることはできません。手順 6 はポリシーで制御できます。無効にするか、独自の deny path を追加できます。 段階名と evidence を含む maintainer 向けの同じ手順については、アーキテクチャを参照してください。分類器の内部については、解析エンジンを参照してください。

文字列ではなく意図を解析する理由

CC Safety Net は、コマンドの見た目ではなく、コマンドの動作を解析します。実行ファイル、subcommand、flag、引数を解析します。その実行ファイルの analyzer が option grammar を適用します。 どちらも git checkout で始まります。単純な prefix ルールでは、Git の option logic を複製しない限り、この 2 つの結果を区別できません。構造解析は、順序を変えた flag(rm -r -f /)、shell wrapper(sh -c "rm -rf /")、interpreter の 1 行コード(python -c 'import os; os.system("rm -rf /")')も処理します。CC Safety Net は、最大 10 階層までネストしたコマンドを展開して再解析します。 このページはすべてのルールを示しません。停止するものの完全な動作 matrix については、ブロックされるコマンドを参照してください。意図的にブロックしないものについては、許可されるコマンドを参照してください。

ブロック結果の形式

エージェントは、ツール結果としてブロックメッセージを受け取ります。
該当する場合、メッセージには一致した Rule: id、Tool: 名、ブロックを発生させた特定の Segment:、およびフォールバック設定が有効な場合の Config warning: も含まれます。コマンドと segment のテキストは抜粋され、プロセス外に出る前にメッセージ全体から機密情報をマスクします。 ブロックによってエージェントセッションが終了することはありません。メッセージは通常のツール結果として届き、別の形式を再試行せずにタスクへ戻るようエージェントに指示します。ルールの intent によって最後の指示が決まります。 このメッセージ形式を使う理由と、指示は助言である一方で enforcement は guard に残す理由については、設計原則を参照してください。

監査記録

CC Safety Net は、拒否を常にローカル監査ログに記録します。許可されたコマンド判定は既定で記録します。次のコマンドでログを読み取ります。
ログの場所、各記録の内容、保持期間、および書き込み前にマスクする情報については、監査ログのリファレンスを参照してください。

判定が予想と異なる場合

1

理由を確認する

npx cc-safety-net explain "<command>" はコマンドの解析を再実行し、一致したルールと理由を示します。構造化トレースには --json を追加します。
2

保護が実際に有効か確認する

npx cc-safety-net statusready または degraded を 1 画面に表示し、無効な Claude Code プラグインを含む、適用されていない項目を Not active に示します。degraded は設定ソースが拒否され、フォールバックが適用されていることを示します。有効なもの、無効なもの、修復方法については、設定の復旧を参照してください。npx cc-safety-net doctor は完全なレポートを表示します。
3

調整または報告する

ブロックが正しいがワークフローには厳しすぎる場合は、安全モードを変更するか、ルールごとの override を追加します。安全なコマンドがブロックされた場合、または破壊的なコマンドがブロックされなかった場合は、トラブルシューティングセキュリティポリシーで報告先を確認してください。

対象外のもの

CC Safety Net はエージェントが実行しようとするツール呼び出しを解析するため、任意の binary、未設定または不透明なコマンド proxy、network activity に隠された動作は検出できません。これは静的な実行前 policy gate です。OS sandbox でも privilege boundary でもありません。インストール済み連携を経由しないコマンドはまったく保護しません。完全な一覧と推奨される緩和策については、既知の制限を参照してください。 次に、各エージェントが CC Safety Net に接続する方法について、連携アーキテクチャを参照してください。
最終更新日 2026年8月12日