Skip to main content
Playbook: Onboarding · Recommended Starting Policies · Threat Model · Tool Policy Examples
Your AI coding agents can run anything a developer can — including the handful of commands that wipe a database, tear down production, or leak a secret. This is the pack that draws the line. It covers the highest-impact actions across every command family Unbound classifies. The genuinely catastrophic and production-scoped actions are stopped; everything else is audited so you build the evidence to decide what to lock down next. The family and field values below are exactly what Unbound matches on.
Create these under Policies → Tool Policies → Create Policy. Leave User Groups empty to apply org-wide, or scope to a team. The four actions are Audit, Warn, Block, and Require Slack Approval (the last needs the Slack integration).Warn surfaces an inline confirmation on Claude Code, Copilot, Codex, Augment Code, and Claude Cowork. It is a UX nicety, not a security boundary. On Cursor a Warn policy is not enforced at all — the command runs with no prompt, so use Block if you need it stopped. On OpenClaw, Warn blocks outright.
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 (the one-pager to share with your security team), see Threat Model. For the reasoning behind each default — why it blocks, warns, or audits — see What each default protects. For platform background, see the Onboarding Playbook.

​
Live in three steps

1

Apply the pack

Drop in the whole pack — the high-risk actions enforced, everything else on Audit. The dangerous handful is stopped; routine work is logged, not interrupted.
2

Watch your agents work

Give it a few days. Every audited action — and every enforced one — lands in Analytics → Tool 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.
Rolling out safely. Pin the pack to one team first (scope via User Groups) and let it run for a week before going org-wide. Any rule can be disabled or moved back to Audit instantly from Policies → Tool Policies — enforcement isn’t a one-way door. If a single rule turns noisy mid-rollout, narrow its scope (tighter pattern or smaller user group) rather than turning the whole pack off.

​
Enforce — stop or confirm

The actions that can cost you a weekend: irreversible operations, production-scoped changes, and hard security boundaries. The agent is stopped — or asked to confirm — before it runs one. 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.
Some commands match more than one rule by design — e.g. kubectl apply --context prod matches both kubectl apply to production and the broader Deployment to production. That’s intentional layered coverage, but it means a single command can be enforced by either. If you’d rather one rule own that path, scope Deployment to production to exclude kubectl (add a provider constraint) once you’ve decided which rule should.

​
Audit — log silently

Routine, but worth a paper trail. These never interrupt anyone — they quietly build the evidence you’ll use to decide what to lock down next. Same demo flow as above — paste the prompt into your agent and watch the matching command land in Analytics → Tool Use → Terminal Run. Plus a family-wide safety net. The pack also adds one Audit rule with Match = any to each high-risk family, so every command that lands in that family is logged — even ones the specific rules above don’t name. Why Audit, not block: a match-any rule would catch routine work too, so it logs for visibility while you learn the baseline, then you tighten from the data.
These family-wide Audit rules are the biggest driver of analytics volume — they log every classified command in the family. That’s exactly what you want while you’re learning your baseline; once you’ve seen a few days of activity, narrow to the targeted rules above (or add retention/rollup) so the signal stays sharp.

​
Two layers of coverage

This pack is built in two complementary layers, so a risky operation is caught by one layer or the other:
  • Precise, production-scoped rules key on the environment Unbound reads straight from the command — a host like prod-db.internal, a container named prod-api, a namespace production. When a command names its environment, it gets the tighter, production-specific treatment.
  • Family-wide Audit rules sit underneath every high-risk family (e.g. Audit all cloud resource destruction, Audit all database writes) and log everything that lands in that family, however it’s named.
The specific rule fires when the target names its environment; the family rule has your back when it doesn’t. Together they give you broad, defense-in-depth coverage across the high-risk families, and the audit trail shows you anything worth tightening next.

​
Go live

Create these by hand with the When → If → Then values above, or ask your Unbound contact to seed the whole pack — you’ll be live in minutes. Review a few days of analytics, promote what matters from Audit to enforcement, relax anything noisy, and you’ve got enforcement tuned to how your team actually works.