What CC Safety Net protects
CC Safety Net treats every command an agent generates as untrusted. Prompt injection, confused context, or adversarial instructions can make an agent emit a destructive command, so the hook checks each supported tool call before the host runs it and denies the call when it finds a block reason. How much of a call gets checked depends on the tool:- An integration’s own shell tools get full command analysis at your safety level.
- A tool you declare in
command_toolsis analyzed like a built-in shell tool when the call carries a non-empty stringcommand. - Every other tool gets policy-file, Git-metadata, and sensitive-path checks only. CC Safety Net never treats its text as a shell command.
- A command that does not go through an installed integration is never checked.
/ or your home directory, and the protections for Git metadata and policy.json. While secret protection is on, no level relaxes reading a recognized secret file’s contents or a path you listed in deny_paths.
What CC Safety Net trusts
Three inputs from outside the hook can change what it enforces. CC Safety Net validates each one before it takes effect.
An invalid configuration never denies ordinary work on its own. CC Safety Net drops the rejected source and reports the runtime as
degraded. Dropping a rulebook removes its denials, so a command it blocked can run again until you fix it. Configuration recovery lists every failure and its fallback.
What happens when analysis fails
When analysis of one tool call cannot finish, CC Safety Net denies that call instead of letting it run:- An unexpected analyzer error produces a deny with a “failed closed” reason.
- CC Safety Net denies malformed hook input, and any command too large or too deeply nested to analyze, at every safety level, standard included. A command that hits an analysis budget gets a reason that tells the agent to simplify or split it.
- Strict and paranoid also deny a command the parser cannot read. Standard lets safe-looking unparseable text through and still scans it for destructive patterns.
What redaction hides and what it keeps
Before CC Safety Net writes command text to the audit log or returns it in a denial message, it replaces recognized credentials with<redacted>. The list covers private keys, URL credentials, secret-bearing environment assignments and HTTP headers, presigned-URL signatures, JWTs, AWS access key IDs, and known token prefixes. The audit log reference gives the full list.
Redaction matches known credential shapes only. It keeps absolute paths, project and directory names, hostnames, IP addresses, usernames, and any credential in an unlisted format. Avoid passing real credentials through commands an agent runs. explain and doctor output carries the same raw text, so read it before you share it. See Before you share a trace.
How an attacker could try to get past it
Network attacks, attacks on the agent platform itself, and a symlink swapped between the check and the run are outside what a pre-execution hook can stop. See Out-of-scope protections.
Related pages
- Security policy explains whether to report a problem publicly or privately.
- Protection layers shows what a sandbox covers that CC Safety Net does not.
- Known limitations lists the remaining gaps and each host’s limits.