Policy Recipes

Copy-paste policies for the scenarios users hit most often. Every recipe on this page:

• Starts from a one-paragraph problem statement in plain language.
• Ships a complete, annotated policy.yaml -- ready to drop into the dashboard or your local controlzero.yaml.
• Lists exactly what gets blocked and what gets allowed, with the extracted action and reason_code for each case.
• Fixture-backed enforcement recipes include a machine-readable scenarios.json file run in CI; walkthrough-only recipes may not.

On Claude Code, Gemini CLI, Cursor IDE, and Kiro CLI, a deny on an enforcing event stops the tool call before it executes. Coverage is declared per event, not per host, so an enforcing event never implies protection for another event the vendor does not expose. The capability matrix is derived from those declarations in the code; run controlzero coverage --json to export them for your installation (a bare controlzero coverage prints only a short per-host summary).

The enforcement path fails closed by default when it cannot establish coverage. Signed policy bundles make policy tampering detectable, and the audit trail distinguishes a control that did not run from one that ran and found nothing. For modify-and-proceed DLP, the Python SDK masks matching secrets in place on Claude Code and Gemini CLI and returns the redacted arguments for forwarding.

New here? Start with Read-only database -- it is the canonical example and the one most customers wire up first.

Shipped recipes

#	Recipe	What it solves
1	Read-only database	Agent can SELECT but never DROP. Piggyback-proof.
2	Block secrets and PII egress	LLM calls allowed, but API keys / SSNs / cards never leave.
3	Dev warns, prod denies	One policy, two postures: soft in dev, hard in prod.
4	LLM model allow-list	Only the models you have vetted can be called.
5	Scoped file access	Read/write your repo and /tmp; deny SSH keys, AWS creds, /etc.
6	Block outbound network	Stop curl / wget / ssh / nc from exfiltrating data.
7	Multi-tenant isolation	Team A agents never touch Team B resources.
8	Tamper response	Four postures when the bundle is altered: warn, deny, deny-all, quarantine.
9	Deny-list: block the dangerous few	Let the agent work freely; hard-block only rm, DROP, disk wipes, and SSH-key writes.
10	Approval (HITL) for destructive actions	Green-light rm / DROP / TRUNCATE / DELETE / GRANT / REVOKE before they run; fail closed otherwise.
15	Prompt-level PII redaction	Python SDK only; supported coding hosts are Claude Code and Gemini CLI.

COMING SOON

Four recipes are blocked on features that are either in flight or need doc surfacing. Reach out via support with the TODO-RECIPE-NN tag if you want one prioritized.

#	Recipe	Blocked on	Tracking
11	Time-windowed access	Condition DSL for time + principal matching	TODO-RECIPE-11
12	Alert on repeated denies	Alert-rule builder (new feature)	TODO-RECIPE-12
13	Git branch-scoped operations	Shell extractor (T4 -- spec landed, SDK copies in flight)	TODO-RECIPE-13
14	Rate-limit per org	Feature exists, needs doc surfacing + condition DSL	TODO-RECIPE-14

The recipe format

Every recipe page follows the same template so you can skim quickly:

1. The problem -- one paragraph in the user's voice.
2. The policy -- full YAML, copy-paste ready.
3. Why it works -- which extractor runs, which rule matches, which decision fires.
4. What gets blocked -- table with extracted action, decision, reason_code.
5. What gets allowed -- table with extracted action, decision, reason_code.
6. Test it yourself -- controlzero test invocations for the documented scenarios and, where available, the fixture that backs the tables above.
7. Caveats -- what the recipe does NOT cover. Honest about the gaps so you pair it with a second recipe or a tool-layer control.
8. Related recipes -- the next two or three you will likely want.

How the test fixtures work

Fixture-backed enforcement recipes under docs-site/docs/recipes/ have a matching directory at tests/fixtures/enforcement-spec/recipes/{recipe-name}/ in the main repo:

• policy.yaml -- byte-identical to the YAML shown in the recipe.
• scenarios.json -- an array of {input, expected} cases covering at least one allow, one deny, one piggyback attempt, and one "falls through to default" case per recipe.

A driver at tests/fixtures/enforcement-spec/recipes/test_recipes.py iterates every recipe directory on every CI run and asserts decision + reason_code + extracted method match the expectations. If a recipe page ever contradicts what the code actually does, CI goes red.

Adding a recipe

Recipes are product statements, not just docs pages. Before you write one, ask:

1. Is it a problem at least three customers have asked about?
2. Can the product actually enforce it today?
3. Is there one policy that fits 80% of the shape, with caveats listed for the other 20%?

If all three answers are yes, follow the format above and add both the markdown file AND the fixture directory in the same PR. The CI driver does the rest.

If the answer to question 2 is "not yet," contact support so the roadmap team can file the gap, add the recipe to the "COMING SOON" table above with a fresh TODO-RECIPE-NN tag, and stop. A half-working recipe is worse than no recipe.