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 eight command families, and it goes live without breaking a single workflow: high-risk actions prompt for a quick confirmation, everything else is logged silently. You watch, you learn, then you enforce — on your terms. And it’s not theory. Every Warn policy here was confirmed firing on a real command in observe mode; the Audit rules are your recommended starting coverage and use the same classifier fields. The family and field values are exactly what Unbound’s classifier extracts.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.
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 is supported on Claude Code and Copilot only — on other tools, use Audit or Block.
Live in three steps
Apply it in observe mode
Drop in the whole pack — high-risk actions on Warn, everything else on Audit. Nothing hard-blocks, so day one is invisible to your developers and loud to your security team.
Watch your agents work
Give it a few days. Every Warn and every audited action lands in Analytics → Tool Use → Terminal Run, attributed to the user and session. Now you can see exactly what your agents do — not guess.
Warn — stop and confirm
The actions that can cost you a weekend. On Claude Code and Copilot the agent pauses and asks before it runs one; on other tools, set these to Block or Audit.| Policy | Command Family · Match (If) | Try it |
|---|---|---|
Force-push or direct push to main/master | Git Action · Operation push + Branch main|master | git push --force origin main |
| Escalate to root | Privilege Escalation · Target User root | sudo su - |
| Modify system files | Update System File · any | echo x | sudo tee -a /etc/hosts |
| Delete files in system paths | Delete File · Path /etc/*|/usr/*|/var/*|/opt/* | rm -rf /etc/example |
| SSH as root | Remote Access · User root | ssh root@host |
| SSH to production hosts | Remote Access · Host *prod* | ssh deploy@prod-web-1 |
| Remote script execution on production | Remote Execution · Target Host *prod* | ssh deploy@prod-host 'bash deploy.sh' |
| kubectl context switch to production | Cloud Config · Context *prod* | kubectl config use-context prod-cluster |
| kubectl apply to production | Cloud Provision · Provider kubectl + Environment *prod* | kubectl apply -f x.yaml --context prod |
| IAM policy attachment | Cloud IAM · Operation *attach*policy* | aws iam attach-role-policy … |
| Kubernetes RBAC changes | Cloud IAM · Service rbac.*|clusterrole.* | kubectl create clusterrolebinding … |
| Kubernetes namespace deletion | Cloud Destroy · Provider kubectl, Service namespace* | kubectl delete namespace test-ns |
| Secret deletion | Cloud Secrets · Operation delete.* | aws secretsmanager delete-secret … |
| Deployment to production | Cloud Provision · Environment *prod* | aws deploy create-deployment … prod |
Database DROP | Database Admin · Operation *DROP* | psql -c "DROP TABLE customers;" |
Database DELETE | Database Write · Operation *DELETE* | psql -c "DELETE FROM users;" |
| Production database writes | Database Write · Environment *prod* | psql "host=prod-db" -c "UPDATE …" |
| Production database admin | Database Admin · Environment *prod* | psql "host=prod-db" -c "VACUUM FULL;" |
| Container stop / kill / removal | Container Operation · Operation rm|stop|kill | docker rm -f some-container |
| Production container operations | Container Operation · Container *prod* | docker restart prod-api |
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 surface a Warn from each. If you’d rather see one prompt, scope Deployment to production to exclude kubectl (add a provider constraint) once you’ve decided which rule you want to own that path.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.| Policy | Command Family · Match (If) | Try it |
|---|---|---|
| Terraform apply | Cloud Provision · Provider terraform, Operation apply | terraform apply -auto-approve |
| Kubernetes scale | Cloud Provision · Provider kubectl, Operation scale | kubectl scale deployment web --replicas=3 |
| Helm install / upgrade | Cloud Provision · Provider helm | helm upgrade myapp ./chart |
| EC2 instance launch | Cloud Provision · Service ec2, Operation run-instances | aws ec2 run-instances … |
| Secret retrieval | Cloud Secrets · Operation get*|read | aws secretsmanager get-secret-value … |
| Vault access | Cloud Secrets · Provider vault | vault kv get secret/app/db |
| Container exec | Container Operation · Operation exec | docker exec -it app sh |
| Container image push | Container Operation · Operation push | docker push registry/app:latest |
Database UPDATE | Database Write · Operation *UPDATE* | psql -c "UPDATE settings SET …" |
| SIGKILL termination | Process Management · Signal SIGKILL|9 | kill -9 4242 |
| Sensitive env-var exposure | Environment Exposure · Variable *SECRET*|*KEY*|*TOKEN* | env | grep SECRET |
| Data upload to external endpoints | Data Transfer · Operation upload|send | aws s3 cp ./report.csv s3://bucket/ |
| Family-wide Audit rule (Match = any) |
|---|
| Cloud Destroy · Cloud Provision · Cloud IAM · Cloud Secrets |
| Database Admin · Database Write |
| Remote Access · Remote Execution · Privilege Escalation |
| Delete File · Credential Access · Environment Exposure · Data Transfer |
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, zero blind spots
This pack is built in two complementary layers, so a risky operation is never missed:- Precise, production-scoped rules key on the environment Unbound’s classifier reads straight from the command — a host like
prod-db.internal, a container namedprod-api, a namespaceproduction. When a command names its environment, it gets the tighter, production-specific treatment. - Family-wide rules sit underneath every family (e.g. Audit all cloud resource destruction, Audit all database writes) and catch everything in that family, however it’s named.