Skip to main content
Playbook: Onboarding · Recommended Starting Policies · Threat Model · What Defaults Protect · Tool Policy Examples
The Recommended Starting Policies pack covers the actions AI coding agents can take that a security team would otherwise have to discover the hard way. This page is the threat-modelling view of that same pack — the categories it ships in, the rules in each, and what each action tier covers. It’s the one-pager to bring to your security review.

​
Categories and coverage

The pack is 49 policies — 23 Block and 26 Audit — in the seven categories the onboarding wizard asks you about, one question each. You keep the categories that match your risk and skip the rest, and you can flip any individual policy between Block and Audit before you confirm. Twelve of the Audit rules match ANY field in their family, so every command in that family is logged even when no targeted rule names it — the backstop under each high-risk family. The Recommended Starting Policies page has the exact Command Family · Match (If) for every rule above, plus a prompt you can paste into your agent to watch it fire.

​
What each tier covers

The pack ships Block and Audit only. Block — the action is irreversible or production-scoped, and there is no realistic recovery if the agent gets it wrong. A dropped table, a deleted CloudFormation stack, a force push over shared history — none of these are undone by a polite “are you sure?” five minutes later. Block stops the command before it runs, with a message the agent itself reads back, so it changes course rather than retrying. Block is enforced whenever the policy check runs. Your If Unbound is unreachable setting chooses what happens if it cannot — Allow by default, or Block — and to cover a command that falls outside every family, add a Custom rule. See Tool Policies. Audit — the action is routine but worth a paper trail. The point isn’t prevention, it’s giving your security team the data to decide what to lock down next. Once you’ve watched a few days of traffic in Analytics → Agentic Use → Terminal Run, you’ll know which Audits to promote and which to narrow. Warn is available when you author your own policies, and the pack deliberately doesn’t use it: its effect depends on the coding agent. It prompts on some, is not enforced on others, and stops the command outright on Codex and OpenClaw — see Actions for the per-agent behaviour and what happens on a headless run. For a baseline that has to hold across a mixed fleet, Block and Audit are the two that behave the same everywhere. Require Slack Approval is the action to reach for when you want a Slack confirmation step, sent to the developer by default.

​
Category-by-category reading guide

If your security review goes category by category, the rule of thumb for each:
  • Production: every rule ships as Block, and nine of the ten name a production target, so they never fire against staging or local. The exception is Cloud project or account switch, which blocks any project, account or profile switch, production or not.
  • Cloud & Infrastructure: Block only the two that take a running thing away — namespace deletion and container stop/kill/rm. Terraform, Helm, EC2 and scaling stay Audit; blocking them globally breaks standard pipelines.
  • Identity, Access & Privilege: Block what grants standing authority — an IAM policy attach, a cluster-admin binding, ssh root@. Local sudo is audited, not blocked — it is logged and still runs. If you want it stopped, add a Custom policy that matches the raw command.
  • Secrets & Credentials: Audit every read, generation and update — agents need secrets to function and a wall here breaks pipelines. Block deletion alone: it’s the one that can’t be undone.
  • Databases & Data Movement: Block DROP, TRUNCATE and DELETE. Audit UPDATEs and every data transfer; agents legitimately patch settings rows and publish artifacts, and a legitimate upload and an exfiltration look identical until you’ve seen your own baseline.
  • Source Control & Delivery: both rules Block. Note that force push is matched on the raw command, not on a field — a force push and a plain push are both operation push, so no git_action field can tell them apart.
  • System & Runtime Safety: Block deletes under the system roots — /etc, /usr, /var, /opt, /bin and the rest — and modifications under a system root too. The two path lists are not identical: the modification rule narrows /usr to a named set of subdirectories, so Homebrew’s install prefixes stay open. Each rule’s exact path list is on the policy itself in your dashboard. Audit everything else you delete, and SIGKILL, which is sometimes the only way out of a hung process.

​
Where this maps in the product

  • The 49 rules in Recommended Starting Policies implement everything above, each with the exact Command Family · Match (If) values Unbound matches on and a prompt you can paste into Claude Code, Cursor or Copilot to watch the policy fire end-to-end.
  • What each default protects is the same pack read as prose — what each default stops, what it leaves alone, and how to narrow one to a single action.
  • For policies on MCP tool calls (GitHub, Slack, Notion, Linear, filesystem MCP), see Tool Policy Examples — same threats, different surface.
  • For platform background and where things live in the UI, see the Onboarding Playbook.

​
Sharing this with your team

It’s stable enough to drop into a security deck verbatim — share the URL, screenshot the table, or paste the category rows into your own threat-model template. Once you’ve reviewed the categories and decided which to enforce first, head back to Recommended Starting Policies and apply the pack at the Load Policies step — the page has the When → If → Then for every rule.