Playbook: Onboarding · Recommended Starting Policies · Threat Model · What Defaults Protect · Tool Policy Examples
You apply this pack yourself. It is the last step of onboarding — Load Policies. You are asked one question per category, you keep the categories you care about, and every policy inside a kept category shows its default Block or Audit, which you can flip before you confirm. Skipping a category creates none of its policies.First-Run Setup walks through that step and everything before it. Afterwards the policies live in Policies → Agentic Use → Tool Policies, where you can edit, rescope, disable or delete any of them. Anything you skipped you can create by hand with the When → If → Then values below.
The pack uses Block and Audit only. Warn is available when you author your own policies, but 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 — so it isn’t used for a baseline that has to hold everywhere. Actions has the per-agent behaviour, including headless runs.Where an action must actually be stopped, use Block; where you want a Slack confirmation step, use Require Slack Approval, sent to the developer by default (needs the Slack integration).
This pack covers terminal commands — what your agents run through the shell. For policies on MCP tool calls (GitHub, Slack, Notion, Linear, the filesystem MCP, …), see Tool Policy Examples. For the threat-modelling view of this same pack, see Threat Model. For what each default protects you from, and what it deliberately leaves alone, see What each default protects. For platform background, see the Onboarding Playbook.
Live in three steps
1
Apply the pack
Answer the seven questions at the Load Policies step and confirm. The irreversible handful is stopped; routine work is logged, not interrupted.
2
Watch your agents work
Give it a few days. Every audited action — and every blocked one — lands in Analytics → Agentic Use → Terminal Run, attributed to the user and session. Now you can see exactly what your agents do, not guess.
3
Tune to your data
Promote any noisy Audit rule to enforcement once you’ve seen the traffic, or relax one that’s getting in the way. Your enforcement is now shaped by your team’s traffic, not generic defaults.
The Try it column gives a natural-language prompt you can paste into your AI agent — Claude Code, Cursor, Copilot, etc. — to watch the policy fire end-to-end. The arrow shows the command the agent will issue that Unbound catches.
1. Production — 10 policies (10 Block)
Can your agents deploy or change production directly? Nine of the ten rules are scoped to a production target, so the same command against staging or local is untouched. The tenth — Block cloud project or account switch — carries no production scope: it fires on any project, account or profile switch, production or not.2. Cloud & Infrastructure — 10 policies (2 Block · 8 Audit)
Do your agents have cloud credentials (AWS, GCP, Azure, Terraform)? Provisioning is daily work, so it is logged. Decommissioning that takes a service down is stopped.3. Identity, Access & Privilege — 7 policies (3 Block · 4 Audit)
Can your agents change access or escalate to root? This is where an agent grants itself authority it can’t be asked to give back.There is no
sudo rule in this pack. It governs how an agent reaches a privileged boundary — remote access as root, IAM grants, Kubernetes RBAC — and audits local privilege escalation rather than blocking it. A sudo command on the developer’s own machine is logged, not stopped. If you want local escalation stopped, add a Custom policy matching the whole command; see Tool Policy Examples.4. Secrets & Credentials — 8 policies (1 Block · 7 Audit)
Should agents be able to read your secrets and tokens? Agents need to read secrets to work, so reads are logged. Deleting one can’t be undone, so that stops.5. Databases & Data Movement — 8 policies (3 Block · 5 Audit)
Do your agents have database access or move data in bulk? Dropped tables and bulk exports don’t come back.TRUNCATE counts as Database Admin, not Database Write, so its rule sits beside DROP and a Database Write rule will not catch it. UPDATE stays on Audit — it is logged, not stopped.6. Source Control & Delivery — 2 policies (2 Block)
Should agents be able to force-push or push to protected branches? Both rewrite history other people depend on.Force push needs the Custom family. A
git_action policy matches on branch, remote, repo and operation, and a force push and a plain push are both push — no field tells them apart. The Custom family matches one pattern against the whole raw command, which is what makes --force catchable. It is the same escape hatch you use for any command a field can’t express.7. System & Runtime Safety — 4 policies (2 Block · 2 Audit)
Should agents be able to run destructive commands likerm -rf? Corrupting the machine an agent runs on is never a normal coding step.
How the coverage layers up
Twelve of the 26 Audit rules match ANY field in their family — Audit all cloud provisioning, Audit all database writes, Audit all remote access and so on. They sit underneath every high-risk family and log whatever lands there, however it is named. The targeted rules above them fire when a command names its environment, its operation or its path — and the family-wide rule has your back when it doesn’t. Together that is defense-in-depth coverage across every high-risk family, and the audit trail shows you what’s worth tightening next.Those family-wide Audit rules are the biggest driver of analytics volume — by design, while you’re learning your baseline. Once you’ve watched a few days of activity, lean on the targeted rules and narrow or disable the family-wide ones so the signal stays sharp.
kubectl apply --context prod matches Block kubectl apply to production, the broader Block deployment to production, and Audit all cloud provisioning. Block wins over Audit, and either Block rule stops the command. If you’d rather one rule own that path, narrow the broader one once you’ve decided which should.