Wildcard pattern より semantic analysis
コーディングエージェントは、git reset --hard に対する wildcard rule など、wildcard matching を使う deny rule に対応します。wildcard pattern は raw command string と pattern を比較するため、space、flag order、command wrapping の変化で block が静かに失敗する可能性があります。flag の並べ替え（rm -r -f /）、shell での wrapping（sh -c "rm -rf /"）、interpreter の背後への隠蔽は、すべて string matching を回避します。
代わりに CC Safety Net は各 command を parse し、git、rm、Remove-Item、find、xargs、parallel の実際の option grammar を理解する analyzer に渡します。このため、判定は command の見た目ではなく、command が実行する動作に基づきます。
tradeoff は複雑さです。parser は shell syntax を正しく処理する必要があり、対応する各 command には独自の analyzer が必要です。利点は、最も重要な command に対する bypass resistance です。pipeline はアーキテクチャで、各 analyzer の正確な動作は解析エンジンで規定します。
常時有効な保護を先に置く 1 つの固定順序
すべての連携で、各ツール呼び出しは同じ順序付き stage を通ります。そのうち 2 stage（canonical policy file と Git metadata の保護）は、意図的に policy snapshot の読み込み前に実行します。 この順序が重要です。設定後に評価する保護の強さは設定に依存し、侵害されたエージェントが最初に編集しようとするのは設定だからです。policy file を読み込む前に拒否することで、この 2 guard は config state を持たず、preset や override で緩和できず、保護対象の file 自身で無効化できません。その代わり、safety level と fallback reason はまだ不明なため、denial で報告できません。これは unconditional guarantee のために diagnostic detail を減らす意図的な tradeoff です。 Sensitive-path protection は snapshot の後にあります。これは policy で制御できます。どの path を sensitive とするかは実際に local decision であり、独自の deny path を追加できなければ役に立たないためです。 具体的な stage table はアーキテクチャにあります。解析を完了できない場合は fail closed
CC Safety Net は解析を完了できない場合に、許可せずブロックします。- guard 内の throw error は、すべての entry point で、throw した stage に属する deny になります。
- tool-input bound または parser budget の超過は、すべての safety level で deny になります。
- Strict modeは fail-closed をさらに拡張し、parser が完全に理解できない command と検証できない destructive target を対象にします。
エージェントが作業を続けられる denial
denial は error state ではありません。active session で通常の tool result としてエージェントに届きます。この動作が、各 block message の書き方を決めます。 単なる「permission denied」は、エージェントに類似 command を再試行させるか、task 全体を停止させる可能性があります。variant の反復は未保護の形式を見つけ、agent turn を消費する可能性があります。task 全体を止めると、1 つの safety action が作業停止になります。 そのため、各 message はエージェントに生産的な次の操作を渡すよう構成します。reason は command が実行したはずの動作を平易に示し、安全な代替がある場合はその名前を示します。各 rule には、closing instruction を選択する intent もあります。block を報告して task の残りを続行する、指定した代替に切り替える、狭い明示 target で再試行する、操作をユーザーに渡す、variant の総当たりではなく command を再構成する、のいずれかです。internal error の fail-closed denial にも intent（retry せず再構成）があるため、tool 自身の予期しない failure でも、有用な response へ導きます。 instruction は意図的に advisory です。エージェントに強制はしません。enforcement は guard が行い、従わない retry も同じように block します。message の目的は compliant path を最も簡単にすることです。このため通常は、session が block を吸収して続行します。message の構造と完全な intent table は仕組みを参照してください。最小限の dependency surface
CC Safety Net は runtime dependency surface を遅延読み込みする 1 package に保ちます。segment splitting、quoting、redirection、command substitution、dynamic-word provenance という構造情報はすべて、third-party grammar ではなく独自の上限付き POSIX parser と PowerShell parserから取得します。これは意図的な build-versus-buy decision です。- 小さい dependency tree は supply-chain attack surface を縮小します。parser は攻撃者が最も混乱させたい構成要素です。
- analysis には一般的な tokenizer が保持しない fact が必要です。どの word が expansion 由来か、どの target が working directory に固定されるか、どの quoting form が使われたかです。owned parser だけが、これらを first-class fact にできます。
- parser budget を configuration ではなく fixed constant にできるため、resource exhaustion は open-ended problem ではなく、上限付きで test 可能な failure mode になります。
- CC Safety Net を hook subprocess として実行するエージェントでは、shell tool call ごとに新しく開始するため startup time が重要です。dependency が少ないと cold start が速くなります。
Rulebook system
以前の version は、custom rule を 1 つの project file に inline JSON として保存しました。CC Safety Net は、4 つの理由で rulebook system に置き換えました。- 共有：rulebook は GitHub repository から取得し、lockfile の SHA-256 digest で固定できるため、team は JSON を copy-paste せず blocking policy を共有できます。
- Integrity：remote rulebook content は使用前に lockfile digest に対して検証します。inline config には integrity の仕組みがありませんでした。
- Scoping：rulebook は、別々の config directory を持つ user（global）scope と project scope に対応します。
- Validation：rulebook content は、blocking decision に影響する前に schema validation を受けます。
1 設定ではなく段階的な level
保護は単一の on/off switch ではなく、standard、strict、paranoid の 3 preset として提供します。「検証できない command を block すべきか」への正しい答えは、command の source によって異なるためです。 Standard は、人間が監督する session 向けに最適化しています。認識できる destructive command と sensitive-content access を block し、parse できないが無害な text は許容するため、日常作業を中断しません。敵対的または動的な input に対しては明示的に best-effort であり、prompt injection や他の信頼できない context から command が来る場合には適しません。 Strict と paranoid は摩擦と引き換えに確実性を高めます。Strict は検証できないものを block し、paranoid は通常は問題ないが時に壊滅的な category も block します。この設計は、standard-mode parser heuristic の追加によって standard の gap を閉じようとはしません。静的に解決できない target は、推測を増やしても安全にはならないためです。新たな gap への所定の対応は、strict または paranoid の fail-closed fixture です。このため、standard mode の residual-risk family を隠さず記録します。 個別 capability は別々に設定でき、rule ごとの override で standard 下でも strict-tier rule を強制できます。ただし、catastrophic rule または always-on protection を override で弱めることはできません。level はモード、各 boundary の正確な位置は解析エンジンを参照してください。代替ではなく多層防御
CC Safety Net は完全な security solution とは主張しません。多層防御 stack の 1 layer と位置づけます。- Permission deny rule は、迅速でユーザー設定可能な block を提供します。CC Safety Net は permission system の前に実行するため、deny rule の設定に関係なく各 command を検査します。
- OS-level sandboxing は filesystem と network access を制限しますが、その境界内の操作が destructive かは理解しません。sandboxed directory 内の
git reset --hardは sandbox の視点では技術的に安全ですが、依然として危険な操作です。
Worktree relaxation
linked git worktree には usability problem があります。worktree で作業する developer は、その worktree の local change を破棄するためにgit checkout -- . または git reset --hard を実行したい場合がありますが、default rule は local-discard operation として block します。
rule 全般を緩和する代わりに、worktree modeは local discard だけを、linked worktree と確実に検証された directory 内だけで、かつ git context が redirect されていない場合だけ許可します。verification が設計を支える要素です。worktree のように見えるだけの directory は対象外で、check を完了できない場合は command を block したままにします。
この緩和は意図的に狭くしています。remote-affecting operation（force push、branch delete、stash drop）はすべて block のままです。使い捨て worktree の外へ到達できる local discard も block します。正確な条件と緩和不能な場合は解析エンジン、mode の有効化方法はモードを参照してください。
次に読むページ
技術ガイドは、ユーザー向け lifecycle から設計理由まで順に説明します。このページは最後の step 5 です。- 前：解析エンジン：これらの tradeoff から生じる正確な classification behavior。アーキテクチャ：それらが正当化する guard order。
- 最初から：仕組み：同じ system をユーザー向けの深さで説明します。
ready / degraded contract。