Tool Policy Examples

Documentation Index

Fetch the complete documentation index at: https://docs.getunbound.ai/llms.txt

Use this file to discover all available pages before exploring further.

Each example below is a real, high-impact scenario. For every one you get the policy to create (When → If → Then) and a prompt you can paste into your AI agent to see the policy fire. Every command here is classified the way shown — the family and field values are what Unbound’s classifier actually extracts. MCP examples target either a specific tool by name or a whole action type (read / write / destructive).

​

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.

​

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 (the classifier reads production from the target and tags the environment). 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: “Tear down the staging namespace.” → kubectl delete namespace staging is held, and an approver gets a Slack DM to Allow or Deny.

​

Audit every git push

Risk: agents push code — including force-pushes that can 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 changes to origin/main.” → git push origin main runs as usual and is logged in Analytics → Tool Use → Terminal Run. (The classifier records the operation as push for plain and force-pushes alike, so this one rule covers both.)

​

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 → Tool Use → Terminal Run. Tighten the path later (e.g. */prod/*) and switch to Block.

​

Block deleting files from a repo (GitHub)

Risk: an agent removes source files through the GitHub MCP, no terminal command involved.

• MCP Server = GitHub, Tool = delete_file
• Then Block

Try it: “Remove the old config file from the repo.” → the delete_file call is blocked.

​

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 (Claude Code & Copilot)

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: “Delete that Linear comment.” → the call is audited (this action type covers delete_comment, delete_attachment, and delete_status_update).

​

Recommended starting policies

The set most teams enable on day one. Start here, watch your logs, then expand.