> ## 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.
# Recommended Starting Policies
> The day-one pack that puts guardrails on what your AI agents can do — validated in observe mode, live in minutes, zero workflow friction
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's classifier extracts.
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](/integrations/slack)). Not every tool honors **Warn** (the confirmation prompt) — confirm your agents support it before using it for the Enforce tier, otherwise use **Block** or **Audit**.
## Live in three steps
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.
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.
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 own data, not a vendor's defaults.
## 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.
| Policy | Command Family · Match (**If**) | Try it |
| ------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------- |
| Production cloud destruction | **Cloud Destroy** · Environment `*prod*` | `aws cloudformation delete-stack --stack-name prod-app` |
| Kubernetes namespace deletion | **Cloud Destroy** · Provider `kubectl`, Service `namespace*` | `kubectl delete namespace test-ns` |
| Deployment to production | **Cloud Provision** · Environment `*prod*` | `aws deploy create-deployment … prod` |
| 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** · Provider `kubectl`, Service `rbac.*\|clusterrole.*` | `kubectl create clusterrolebinding …` |
| Secret deletion | **Cloud Secrets** · Operation `delete.*\|remove.*` | `aws secretsmanager delete-secret …` |
| kubectl context switch to production | **Cloud Config** · Provider `kubectl`, Context `*prod*`, Operation `use-context` | `kubectl config use-context prod-cluster` |
| Cloud project or account switch | **Cloud Config** · Operation `set\|configure`, Key `project\|account` | `gcloud config set project prod-proj` |
| Database `DROP` | **Database Admin** · Operation `*DROP*` | `psql -c "DROP TABLE customers;"` |
| Database `TRUNCATE` | **Database Admin** · Operation `*TRUNCATE*` | `psql -c "TRUNCATE TABLE events;"` |
| Production database admin | **Database Admin** · Environment `*prod*` | `psql "host=prod-db" -c "VACUUM FULL;"` |
| Production database writes | **Database Write** · Environment `*prod*` | `psql "host=prod-db" -c "UPDATE …"` |
| Database `DELETE` | **Database Write** · Operation `*DELETE*` | `psql -c "DELETE FROM users;"` |
| 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` |
| SSH to production hosts | **Remote Access** · Host `*prod*\|*production*` | `ssh deploy@prod-web-1` |
| SSH as root | **Remote Access** · User `root` | `ssh root@host` |
| Remote script execution on production | **Remote Execution** · Target Host `*prod*\|*production*` | `ssh deploy@prod-host 'bash deploy.sh'` |
| Escalate to root | **Privilege Escalation** · Target User `root` | `sudo su -` |
| Delete files in system paths | **Delete File** · Path `/etc/*\|/usr/*\|/var/*\|/opt/*` | `rm -rf /etc/example` |
| Git force push | **Git Action** · Operation `push` + Force `force` | `git push --force origin main` |
| Direct push to `main`/`master` | **Git Action** · Operation `push` + Branch `main\|master` | `git push origin main` |
| Modify system files | **Update System File** · any | `echo x \| sudo tee -a /etc/hosts` |
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.
| 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`, Operation `install\|upgrade` | `helm upgrade myapp ./chart` |
| EC2 instance launch | **Cloud Provision** · Provider `aws`, Service `ec2`, Operation `run-instances` | `aws ec2 run-instances …` |
| Secret retrieval | **Cloud Secrets** · Operation `get-secret-value\|read\|get-parameter` | `aws secretsmanager get-secret-value …` |
| Secret creation or update | **Cloud Secrets** · Operation `create.*\|put.*\|update.*` | `aws secretsmanager create-secret …` |
| 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 …"` |
| API key or token generation | **Credential Access** · Type `*api*key*\|*token*\|*secret*` | `aws iam create-access-key` |
| SIGKILL termination | **Process Management** · Signal `SIGKILL\|KILL\|9` | `kill -9 4242` |
| Sensitive env-var exposure | **Environment Exposure** · Variable `*SECRET*\|*KEY*\|*PASSWORD*\|*TOKEN*\|*CREDENTIAL*` | `env \| grep SECRET` |
| Data upload to external endpoints | **Data Transfer** · Operation `upload\|send` | `aws s3 cp ./report.csv s3://bucket/` |
**Plus a family-wide safety net.** The pack also adds one **Audit** rule with **Match = any** to each high-risk family, so *everything* in that family is logged — even commands the specific rules above don't name:
| Family-wide Audit rule (**Match = any**) |
| ---------------------------------------------------------------------- |
| Cloud Destroy · Cloud Provision · Cloud IAM |
| 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 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 catch everything 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 mean **nothing in a high-risk family ever goes unseen.**
## 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.