> ## 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. # Threat Model > The day-one policy pack mapped to the threats it actually defends against — the one-pager you can show your security team **Playbook:** [Onboarding](/playbook/introduction) · [Recommended Starting Policies](/playbook/recommended-starting-policies) · **Threat Model** · [Tool Policy Examples](/playbook/policy-examples) The [Recommended Starting Policies](/playbook/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](/playbook/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** `UPDATE`s; agents legitimately patch settings rows. ## Where this maps in the product * The 38 rules in [Recommended Starting Policies](/playbook/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](/playbook/policy-examples) — same threat layers, different surface. * For platform background and where things live in the UI, see the [Onboarding Playbook](/playbook/introduction). ## 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](/playbook/recommended-starting-policies) and apply the pack — the page has the **When → If → Then** rule for every layer.