Threat Model

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.

Layer	Threat we’re defending against	What’s enforced	What’s audited
L1 — Production damage	An 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 operations	All of Cloud Destroy, Cloud Provision, Database Admin, Database Write — even non-production targets, so you build a baseline.
L2 — Data exfiltration	Secrets, env vars, or production data leave the host through an agent action.	Secret deletion	Whole-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 privilege	The 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 root	All of Cloud IAM, Privilege Escalation, Access Password.
L4 — Lateral access and remote execution	The 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 switch	All of Remote Access and Remote Execution, plus Container exec audited for forensics.
L5 — Configuration drift and persistence	The 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`/`master`	All of Delete File, plus Container image push (supply-chain leg).
L6 — Destructive data operations	The agent issues `DROP`, `TRUNCATE`, or unscoped `DELETE` against any database — production or not.	Database `DROP` · Database `TRUNCATE` · Database `DELETE` · Container stop / kill / removal	Database `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.

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.

Getting Started

CLI

Policies

Analytics

API Reference

Integrations

MDM Integrations

Connections

Support & Troubleshooting

Layers and coverage

Why each tier exists

Threat-by-threat reading guide

Where this maps in the product

​Layers and coverage

​Why each tier exists

​Threat-by-threat reading guide

​Where this maps in the product

​Sharing this with your team

Layers and coverage

Why each tier exists

Threat-by-threat reading guide

Where this maps in the product

Sharing this with your team