Skip to main content
CC Safety Net は、AI コーディングエージェントのような信頼できないコマンドの発生源と、実際の実行環境との間に位置します。このページでは、信頼境界、各安全レベルの保証、設定が壊れたときの扱い、シークレット保護、攻撃対象領域を示します。脆弱性の報告方法はセキュリティポリシーを参照してください。 CC Safety Net は、対応するコーディングエージェントのツール呼び出しを、実行前にベストエフォートで静的に検査するポリシーゲートです。OS のサンドボックスでも権限境界でもなく、インストール済みの連携を迂回するコマンドも守れません。

信頼境界

主境界:コマンドの発生源と実行環境の間

中心となる信頼境界は、AI コーディングエージェントとホストのシェルの間にあります。CC Safety Net は、この境界でコマンドを検査します。
  • 信頼できない側:AI エージェントが生成するコマンド文字列。プロンプトインジェクション、混乱したコンテキスト、敵対的な指示によって破壊的なコマンドを生成しうるため、潜在的に敵対的なものとして扱います。
  • 実行する側:コマンドを実行するホストのシェル。
対応プラットフォームのシェルツールに届くコマンドは、実行が許可される前に必ず解析エンジンを通ります。解析がブロックの理由を返した場合、そのコマンドは拒否されます。 この境界は、対応するツール名と形式の範囲で終わります。アダプターがコマンド実行として扱うのは、連携ごとに定めた特定のツール名だけです。未知のツールも、ポリシーファイル、Git メタデータ、機密パスについては保守的に検査されますが、その内容がシェルコマンドとして扱われることはありません。インストール済みの連携を完全に迂回するコマンドは、この境界の外側です。

副次的な境界

副次的な境界が 5 つあり、いずれも外部から CC Safety Net の内側へ入ってきます。どの入力も、解析に影響を与える前に検証されます。

各安全レベルの保証

standard、strict、paranoid は、fail_closedparanoid_rmparanoid_interpreters の 3 つの機能に既定値を与える preset です。保証の内容はレベルごとに異なります。
standard モードは敵対的な入力に耐える水準ではありません。動的な rm -rf の対象は、standard では一律にはブロックされません。rm -rf "$target" は standard では許可され、ブロックされるのは strict と paranoid だけです。コマンドがプロンプトインジェクションなど敵対的な文脈から来る可能性がある場合は、strict または paranoid が必要です。
シークレット保護が有効な間は、安全レベルによって、一致した機密情報の内容へのアクセスや、ユーザーが設定した deny path とその配下が緩和されることはありません。設定した secret_protection.allow_paths の項目により、特定のファイルやディレクトリツリーを CLI 以外の組み込みシークレットルールから除外できますが、deny path と secret.cli.* のルールは引き続き優先されます。致命的な操作に対する保護は常に適用されます。これには、root またはユーザーのホームディレクトリの再帰削除、保護対象の Git メタデータへの破壊的な変更、ユーザーまたはプロジェクトの policy.json への破壊的な変更が含まれます。

設定復旧の境界

設定は信頼境界であって、緊急停止スイッチではありません。設定が無効な場合、ランタイムは 2 つの状態のいずれかになりますが、設定が無効だというだけの理由で通常の作業を拒否することはありません
  • ready:有効なすべての設定元が検証済みです。
  • degraded:候補となった設定元が拒否され、代わりに安全なものが適用されています。rulebook ファイルが存在しない、読み取れない、無効、または設定元と名前が食い違う場合、その設定元は破棄され、ルールを提供しません。rulebook 名が重複した場合は、先に名前を確保した側が残ります。プロジェクトポリシーの audit セクションは無視されます。どちらかのスコープのポリシーファイルが読み取れない場合は、救済されたポリシーか、組み込みの安全側の既定値にフォールバックします。
拒否された候補が有効なものとして扱われることはありません。設定元を破棄すると、その設定元が提供していた拒否も失われます。設定したポリシーより実際の強制力が下がるということなので、安全性に関わる変化として扱い、すべての表示箇所で報告します。ただし、破棄によって組み込みのルールが弱まることはありません。rulebook が提供できるのはブロックのルールだけであり、読み取れない rule.json を無視すれば、その overrides が無効にしていた組み込みルールはむしろ復活します。例外は 1 つだけで、範囲も文書化されています。transparent_wrappersrule.json の中にあるため、rule.json を読み取れない場合、そのスコープでは組み込みの解析が透過できるラップ済みコマンドが減ります。設定できないことを理由に何かを拒否はしませんが、その代わりにコマンドやパスを許可リストへ追加することもありません。 ポリシーファイルの保護と Git メタデータの保護は、ポリシースナップショットの読み込みより前に評価されるため、どちらの状態でも同じように適用され、設定に関する情報を持ちません。 失敗の種類ごとの一覧、それによって生じるフォールバック、復旧用のコマンドを含む完全な取り決めは、設定の復旧にあります。

fail closed による強制

fail closed は、解析そのものを完了できない場合にその 1 回のツール呼び出しへ適用されます。アナライザーの予期しない失敗、パースできない入力、リソース上限への到達が該当します。設定が無効なときの動作を指す言葉ではありません。
1

hook のエントリーポイント

hook のアダプターは、解析の呼び出しを try/catch で囲みます。解析が例外を投げた場合、コマンドを続行させず拒否を出力します。解析の上限に達した場合の拒否には専用の理由が付き、コマンドを単純にするか分割するようエージェントに指示します。「failed closed」の理由は、アナライザーの想定外の失敗にかぎって使われます。これは標準入力方式の hook を使うすべてのエージェント(Antigravity CLI、Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot CLI、Grok Build、Kimi Code)に当てはまります。ただし、Grok Build だけは 1 点異なります。Grok Build の hook は fail open で、ホスト側に failClosed に相当する設定がありません。そのため、ツール呼び出しをブロックできるのは、標準出力に明示的な deny を返した場合だけです。アダプター自身が fail closed とするケース(ツール入力の切り詰めや、作業ディレクトリを利用できない場合)には、それでも明示的に deny を出力します。このホストでは、アダプターが出力を一切返せなくなる失敗が起きた場合、その呼び出しをブロックできません。
2

プラグインと拡張機能のエントリーポイント

Amp Code、OpenCode、OpenClaw、Pi のプロセス内連携も、同じパターンを使います。解析エラーを捕捉し、それをブロックメッセージとして返すため、各プラットフォームは拒否されたコマンドとして扱います。Codex はプラグインとしてインストールされますが、実行するのは標準入力 hook の cc-safety-net hook --codex なので、前のステップに含まれます。Hermes Agent は両方を重ねた構成です。管理対象の Python プラグインが同じ標準入力 hook(cc-safety-net hook --hermes-agent)を呼び出し、解析を完了できない場合はプラグイン自身がその呼び出しをブロックします。npx が見つからない、作業ディレクトリや Hermes のセッション記録を解決できない、プロセスの起動に失敗する、30 秒でタイムアウトする、アナライザーが 0 以外で終了する、出力を読み取れない、といった場合が対象です。各エージェントの方式は連携アーキテクチャを参照してください。
3

形式が不正、またはサイズが大きすぎるツール入力

信頼できない入れ子構造のツール入力には、次の上限を設けています。オブジェクトの深さ 64 段、走査する値 10,000 個、自身のキー 10,000 個、文字列 1 つあたり 1 MiB、文字列データの合計 4 MiB です。hook の標準入力は生のバイト数で 8 MiB が上限です。いずれかを超えた時点で、その呼び出しを拒否します。
4

パーサーのリソース枯渇

131,072 UTF-16 コードユニットを超える入力、16,384 を超える語数、64 段を超えるネストは、中途半端に解析せずに拒否します。これとは別に、派生トークン 16,384 個という上限があり、最初のパースの後にネストされたコマンドや埋め込まれたコマンドが追加する処理量を制限します。パーサーと実行時の依存関係を参照してください。いずれの上限も、standard を含むすべての安全レベルに適用されます。
5

strict モードでの動作

strict モードは、シェルのパーサーが安全にトークン化できないコマンドにまで fail closed を広げます。そのため、パースできない入力はブロックします。standard モードでは、安全に見えるパース不能なテキストは許可されます。
設定が無効な場合は、意図的にこの一覧に含めていません。拒否されたルールの設定元は破棄され、読み取れないポリシーファイルは安全側の既定値にフォールバックするため、通常の作業はそのまま続けられます。上記の設定復旧の境界を参照してください。
この方針の理由は、設計原則を参照してください。

シークレットのマスク

コマンドやセグメントのテキストは、監査ログに書き込まれる前、またはエージェントに返される前に、自動的なシークレットのマスク処理を通ります。マスク対象は次のとおりです。
  • PEM 形式の秘密鍵
  • データベース URL の環境変数
  • シークレットを含みやすい環境変数への代入
  • シークレットを含みやすい HTTP ヘッダー
  • URL 内の資格情報
  • 署名付き URL のクエリパラメーター(x-amz-signaturex-goog-signaturesigsignature
  • 既知のプロバイダーのトークン接頭辞(GitHub、Slack、npm、Stripe、PyPI)
  • JWT
  • AWS のアクセスキー ID
一致した値は <redacted> に置き換えられます。 このマスク処理は、パターンに基づく保守的な仕組みです。コマンドの引数に現れたシークレットが漏れるリスクは下げられますが、対象は認識済みの資格情報の形式に限られます。絶対パス、プロジェクト名やディレクトリ名、ホスト名、IP アドレス、ユーザー名、パターン一覧にない形式の資格情報は、そのまま残ります。新しいシークレットの形式は次々に登場するため、エージェントが実行するコマンドに本物の資格情報を渡さないでください。マスク処理の対象範囲は監査ログのリファレンスにまとめてあります。 同じ制限は cc-safety-net explain にも当てはまります。トレースには、指定したコマンド文字列、解析後のトークン、ホームディレクトリを含む絶対パスがそのまま残ります。どこかに貼り付ける前に、必ず内容を確認してください。explain トレースを参照してください。

攻撃対象領域

脅威モデルで想定する主な攻撃対象領域と、その緩和策は次のとおりです。 ネットワークレベルの攻撃と、エージェントのプラットフォーム自体に対する攻撃は対象外です。CC Safety Net はコマンド解析中にネットワーク通信を行わず、ネットワーク層を持ちません。リソース枯渇は封じ込めではなく上限で対処します。パーサーやツール入力の上限を超える入力は、中途半端に解析せずに拒否します。

開示の分類

報告手順の全体はセキュリティポリシーにあります。どちらの経路で報告すべきかは、次の表で判断してください。 未対応のコマンドを報告する場合は、コマンドの形式だけを示してください。そのまま貼り付けて悪用できるプロンプトインジェクションの攻撃コードは含めないでください。どちらの報告経路についても、セキュリティポリシーを参照してください。

関連ページ

最終更新日 2026年9月3日