Skip to main content
Playbook: Onboarding · Recommended Starting Policies · Threat Model · What Defaults Protect · Tool Policy Examples
For every example below you get the policy to create (When → If → Then) and a prompt you can paste into your AI agent to see the policy fire. The family and field values are exactly what Unbound matches on. MCP examples target either a specific tool by name or a whole action type — read, write or destructive. The tool picker lets you filter a server’s tools by type, so you can see which of them the rule will cover before you enable it.
Create these under Policies → Agentic Use → Tool Policies → Create Policy, then pick Terminal Commands or MCP Actions. 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 behaves differently per agent: it prompts for confirmation on Claude Code (run interactively), Copilot, Claude Cowork and Pi; on Cursor the command runs with no Unbound prompt; on Augment Code the prompt is left to Augment’s own tool-permission settings; and it stops the command outright on Codex and OpenClaw. Where Claude Code runs headless, Warn allows the command through unless your organization has set the headless Warn action to Block. Where the action must actually be stopped, use Block.
Looking for the day-one set we recommend most teams enable first? See Recommended Starting Policies — 49 policies in seven categories, applied at the Load Policies step of onboarding. For the threat-modelling view of that pack, see Threat Model. For platform background, see the Onboarding Playbook.

​
How patterns are read

Every Pattern you type is read as exact, glob or regex, from the syntax you wrote: Globs are anchored (*prod* covers the whole value), regexes are an unanchored substring search, and both ignore case. If a pattern is ambiguous, force the reading with an exact:, glob: or regex: prefix. Add more than one condition and they AND together — every one must match. Any tests your pattern against every field the family carries, so it stands alone. One value written several ways still matches: a host field matches on the bare host, and ~/.aws/credentials, .aws/credentials and the expanded absolute path all match each other. Every family and its fields are listed in Command family reference.

​
Terminal command examples

​
Block destructive database operations

Risk: an agent with DB credentials runs DROP DATABASE or TRUNCATE and wipes data irreversibly.
  • When Command Family = Database Admin
  • If Match Against = Operation, Pattern = *DROP* (add a second rule for *TRUNCATE*)
  • Then Block
Try it: “Drop the production database.” → the agent’s DROP DATABASE prod; is blocked. A normal SELECT is untouched.
TRUNCATE counts as Database Admin, not Database Write. A DELETE is a write, so that rule belongs on Database Write.

​
Block production infrastructure teardown

Risk: an agent with cloud credentials deletes a live environment.
  • When Command Family = Cloud Destroy
  • If Match Against = Environment, Pattern = *prod*
  • Then Block
Try it: “Delete the production namespace in our cluster.” → kubectl delete namespace production is blocked. Same for aws rds delete-db-instance --db-instance-identifier prod-db.

​
Require approval to tear down staging

Risk: staging teardown is sometimes legitimate, but you still want a human in the loop.
  • When Command Family = Cloud Destroy
  • If Match Against = Environment, Pattern = *staging*
  • Then Require Slack Approval
Try it: “Delete the staging database instance.” → aws rds delete-db-instance --db-instance-identifier staging-db is held, and an approver gets a Slack DM to Allow or Deny. (A namespace deletion is not a good test here: the recommended pack blocks it in every environment, and Block wins over approval.)

​
Audit every git push

Risk: agents push code — including pushes that overwrite shared history. Log them all so you can see what your agents ship.
  • When Command Family = Git Action
  • If Match Against = Operation, Pattern = push
  • Then Audit
Try it: “Push my feature branch to origin.” → git push origin feature-x runs as usual and is logged in Analytics → Agentic Use → Terminal Run. Plain and force pushes are both operation push, so this one rule logs both — and singling out a force push needs the Custom family, below. A push to main is a poor test with the recommended pack loaded, because the pack blocks it.

​
Audit every file deletion

Risk: you don’t yet know what your agents delete — get visibility before you enforce.
  • When Command Family = Delete File
  • If Match Against = Path, Pattern = *
  • Then Audit
Try it: “Delete the build directory.” → rm -rf build/ runs as usual, with a log entry in Analytics → Agentic Use → Terminal Run. Tighten the path later (e.g. */prod/*) and switch to Block.

​
Block a command by its raw text (Custom family)

Risk: the action you care about isn’t expressed by any field on any family — an interactive root shell, a house-specific release script, a particular flag. The Custom family is the escape hatch. It matches one pattern against the whole raw command, for every command an agent runs, whatever family it falls into. Its single field is always command. It is also the family that holds when nothing else does: a command Unbound cannot place in a family is allowed, and only a Custom rule still fires on it. Custom covers an agent’s own file tools too — a native read, write, edit or delete matches as its shell equivalent (cat <path>, echo "..." > <path>, rm <path>).
  • When Command Family = Custom
  • If Pattern = *sudo su*
  • Then Block
Try it: “Drop me into an interactive root shell.” → sudo su - is blocked, even though the recommended pack only audits privilege escalation.
This is the same approach the recommended pack uses to block git force push. A force push and a plain push are both operation push, so no Git Action field can separate them — only the raw command text carries --force.

​
MCP tool examples

​
Block destructive GitHub actions

Risk: an agent destroys something in a repo through the GitHub MCP, with no terminal command involved.
  • MCP Server = GitHub, Action type = destructive
  • Then Block
Try it: filter the GitHub tool list by destructive to see exactly which tools the rule covers, then ask your agent to use one. That call is blocked; reads and ordinary writes are untouched.

​
Require approval before merging a PR (GitHub)

Risk: an agent self-merges a pull request with no human review.
  • MCP Server = GitHub, Tool = merge_pull_request
  • Then Require Slack Approval
Try it: “Merge PR #128.” → the merge is held for Slack approval.

​
Block posting to Slack

Risk: an agent posts to channels — noise at best, data exfiltration at worst.
  • MCP Server = Slack, Tool = slack_send_message
  • Then Block
Try it: “Post this update to #engineering.” → the message is blocked before it sends.

​
Warn before editing Notion docs

Risk: an agent edits shared team documentation.
  • MCP Server = Notion, Tool = notion-update-page
  • Then Warn (prompts on Claude Code, Copilot, Cowork and Pi; runs with no Unbound prompt on Cursor; left to Augment Code’s own tool permissions; stops the call on Codex and OpenClaw)
Try it: “Update the launch checklist in Notion.” → the edit proceeds with a warning surfaced to the user.

​
Audit all destructive Linear actions

Risk: you want a record of every deletion an agent makes in Linear.
  • MCP Server = Linear, Action type = destructive
  • Then Audit
Try it: filter the Linear tool list by destructive, then ask your agent to use one of those tools — the call runs and is audited.
A named server covers its canonical group, so the rule holds whatever each user called the server in their own config. Run unbound policy tool mcp-servers to see the known servers and the tools each one exposes, so you match a tool name that exists. Server names are matched case-insensitively, and a name Unbound does not recognise is refused rather than silently accepted.

​
Creating these from the CLI

Every example above can be authored with the unbound CLI. Both creation commands require you to pick a lane: --prompt for AI-assisted creation, or --no-ai to pass raw classification flags yourself.
--custom-message is required whenever --action is BLOCK or WARN — it’s the text the agent itself reads back when the policy fires. When an agent is driving the CLI, use --prompt: --no-ai is refused inside a Claude Code session, and the error names the environment variable an interactive human can set to override it.unbound policy tool families lists every command family and the fields it accepts, and unbound policy tool mcp-servers lists the known MCP servers and the tools each one exposes. --command-family wants a family such as cloud_provision or delete_file — not one of the dashboard’s group headings like Filesystem or Cloud, which are not families.

​
Where to start

The set most teams enable on day one ships as a pack — 49 policies in seven categories, listed rule by rule in Recommended Starting Policies. The examples on this page are what you add on top, once your own traffic tells you where the gaps are.
Don’t know the family or pattern? Click Ask AI on the policy list and describe what you want in plain English — e.g. “Block any database command that drops or truncates” — and Unbound drafts the policy for you to review and edit before it’s created. Then use Preview Impact to see what it would have matched over recent activity before you enable it.