Skip to main content
Playbook: Onboarding · Recommended Starting Policies · Threat Model · Tool Policy Examples
The Recommended Starting Policies pack covers the actions AI coding agents can take that a security team would otherwise have to discover the hard way. This page is the threat-modelling view of that same pack — the layers it covers, the rules in each layer, and the rationale for each action tier. It’s the one-pager to bring to your security review.

​
Layers and coverage

Six layers, mapped to the rules in the recommended pack. Every layer has at least one Block (or Warn, where the agent supports it) for catastrophic actions and at least one family-wide Audit rule for visibility.
LayerThreat we’re defending againstWhat’s enforcedWhat’s audited
L1 — Production damageAn agent issues a single command that takes down or wipes a live environment.Production cloud destruction · Deployment to production · kubectl apply to production · Production database admin · Production database writes · Production container operationsAll of Cloud Destroy, Cloud Provision, Database Admin, Database Write — even non-production targets, so you build a baseline.
L2 — Data exfiltrationSecrets, env vars, or production data leave the host through an agent action.Secret deletionWhole-environment dump · Data upload to external endpoints · Secret retrieval · Secret create/update · Vault access · all of Environment Exposure · all of Data Transfer · all of Access Password.
L3 — Identity and privilegeThe agent grants itself or another principal more authority than the task warrants.IAM policy attachment · Kubernetes RBAC / service-account creation · IAM access-key creation · Escalate to root · SSH as rootAll of Cloud IAM, Privilege Escalation, Access Password.
L4 — Lateral access and remote executionThe agent reaches a system it shouldn’t be on, or runs code on a host other than the developer’s.SSH to production hosts · Remote script execution on production · kubectl context switch to production · Cloud project or account switchAll of Remote Access and Remote Execution, plus Container exec audited for forensics.
L5 — Configuration drift and persistenceThe agent modifies host or repo state in ways that survive the session — config files, cron, system files, or a push straight to a shared branch.Delete files in system paths · Modify system files · Direct push to main/masterAll of Delete File, plus Container image push (supply-chain leg).
L6 — Destructive data operationsThe agent issues DROP, TRUNCATE, or unscoped DELETE against any database — production or not.Database DROP · Database TRUNCATE · Database DELETE · Container stop / kill / removalDatabase UPDATE · all of Database Write, Database Admin, Process Management.
The classifier maps recognised commands into these layers, and each high-risk family also carries a family-wide Audit rule as a backstop. The Recommended Starting Policies page has the exact When → If → Then for every rule named above, plus a prompt you can paste into your agent to watch it fire.

​
Why each tier exists

The pack ships with three action tiers, not because we like options, but because the underlying threats split cleanly into three buckets. Block — the action is irreversible or production-scoped, and there is no realistic recovery if the agent gets it wrong. A dropped table, a deleted CloudFormation stack, a direct push to main — none of these are undone by a polite “are you sure?” prompt to the developer five minutes later. Block stops the command at the hook, before the syscall, with a message the agent reads back. Warn — the action is risky but legitimate sometimes, and the agent is one of the tools that supports an inline confirmation prompt (Claude Code and Copilot today). Warn is a UX nicety, not a security boundary: on agents that don’t support it, use Block for the same outcome (the command is stopped) or use Require Slack Approval to keep a human in the loop with no developer-side prompt at all. Audit — the action is routine but worth a paper trail. The point of Audit isn’t to prevent — it’s to give your security team the data to decide what to lock down next. The family-wide Audit rules (one per high-risk family) are the biggest driver of analytics volume in the pack; that’s by design. Once you’ve watched a few days of traffic in Analytics → Tool Use → Terminal Run, you’ll know which Audits to promote to Block and which to narrow.

​
Threat-by-threat reading guide

If your security review goes layer-by-layer, the rule of thumb for each:
  • L1 (Production damage): every rule that names *prod* should ship as Block. Anything broader — terraform apply, EC2 launch, helm upgrade — stays Audit until you’ve seen who’s running them.
  • L2 (Data exfiltration): the pack Audits every dump and external upload (env, printenv, curl posts, secret retrievals) so you see who’s doing what. Block secret deletion outright — that one is irreversible. Promote the env-dump and upload Audits to Block once you’ve baselined the noise and decided which destinations are sanctioned.
  • L3 (Identity and privilege): Block anything that grants admin or escalates to root (AdministratorAccess attach, cluster-admin binding, sudo su -, ssh root@). Audit key-creation operations; agents rotate keys legitimately during onboarding.
  • L4 (Lateral access): Block any SSH or remote exec where the host name contains prod. Audit cloud-context switches; they’re cheap to log and high-signal when reviewed.
  • L5 (Configuration drift): Block writes under /etc/, /usr/, /var/, /opt/, plus direct pushes to main/master. Audit container image pushes for the supply-chain trail.
  • L6 (Destructive data ops): Block DROP, TRUNCATE, unscoped DELETE. Audit UPDATEs; agents legitimately patch settings rows.

​
Where this maps in the product

  • The 38 rules in Recommended Starting Policies implement everything above, each with the exact Command Family · Match (If) values that Unbound’s classifier extracts and a prompt you can paste into Claude Code, Cursor, or Copilot to watch the policy fire end-to-end.
  • For policies on MCP tool calls (GitHub, Slack, Notion, Linear, filesystem MCP), see Tool Policy Examples — same threat layers, different surface.
  • For platform background and where things live in the UI, see the Onboarding Playbook.

​
Sharing this with your team

This page is the answer to “show me how Unbound covers our threats.” It’s stable enough to drop into a security deck verbatim — share the URL, screenshot the table, or paste the layer rows into your own threat-model template. Once you’ve reviewed the layers and decided which to enforce first, head back to Recommended Starting Policies and apply the pack — the page has the When → If → Then rule for every layer.