# AI Agent Sandbox Threat Model Checklist

**Brand:** OperatorForge AI  
**Updated:** 2026-06-11  
**Format:** free checklist + threat-model worksheet + consultant packaging notes  
**Use when:** a founder, engineering lead, automation consultant, or ops team is deciding whether AI coding agents, browser agents, MCP tools, or workflow agents need VM-level sandboxing, network controls, approval gates, or a lighter policy layer.

## Why this matters now

The 2026-06-11 scan found a fresh cluster around **AI agent sandboxing and accountable agent networks**:

- Hacker News surfaced **"Your AI Agent Is Compromised"** and **"Principles of an Accountable AI Agent Network"** on 2026-06-11.
- HN also surfaced a live discussion asking whether teams are defaulting to VM-level sandboxing before understanding the threat model.
- GitHub search showed new or updated projects around semantic agent gateways, MCP threat scanners, confirmation-driven MCP probing, and security-first AI-agent sandbox SDKs.

The monetizable gap: many teams are rushing straight to heavyweight VMs, browser isolation, or wide-open agent permissions without a plain-English map of what the agent can read, write, call, spend, leak, or break. A practical threat-model checklist gives consultants a crisp first diagnostic and gives buyers a safer way to say yes to agent automation.

## 15-minute agent sandbox threat model

| Question | Minimum answer | Evidence to keep |
|---|---|---|
| What can the agent read? | repos, files, browser pages, SaaS records, customer data classes | data-access register |
| What can it write or change? | code, configs, workflows, tickets, CRM, billing, production systems | action-boundary map |
| What can it call? | shell, browser, MCP tools, APIs, email, deploy, payment, database | tool inventory |
| What can it exfiltrate? | network destinations, logs, screenshots, prompts, attachments | egress allowlist |
| What can it spend? | tokens, API calls, SaaS actions, cloud resources, retries | cost ceiling |
| What happens if it is wrong? | rollback path, owner approval, kill switch, evidence requirement | recovery plan |

## Sandbox tier selector

| Tier | Use for | Minimum controls | Avoid when |
|---|---|---|---|
| Tier 0: Prompt-only policy | internal drafts, low-risk research, non-sensitive docs | explicit no-secrets rule, source citations, human review | any write access or private data |
| Tier 1: Workspace allowlist | docs, small code edits, local examples | path allowlist, read-only secrets, diff review, test evidence | production deploys or payment/customer data |
| Tier 2: Tool firewall | coding agents, browser agents, MCP tools with real APIs | command allow/deny list, egress allowlist, budget ceilings, run log | agents need broad discovery without review |
| Tier 3: Ephemeral sandbox/VM | untrusted repos, third-party tool bundles, generated scripts | clean VM/container, no host secrets, no persistent credentials, artifact review | trusted repetitive work where overhead kills ROI |
| Tier 4: Human-gated production | deploy, delete, refund, email blast, billing/export, customer-data mutation | two-step approval, transaction caps, audit event, rollback owner | never fully autonomous without an accountable owner |

## Checklist

### 1. Inventory the agent's blast radius

- [ ] Name each agent/tool and its owner.
- [ ] List every filesystem path, repository, SaaS workspace, and data class it can read.
- [ ] List every action that can change state: write file, run command, send message, update CRM, deploy, charge/refund, delete.
- [ ] Mark payment, customer data, credentials, production infrastructure, and external communications as high-risk by default.

### 2. Choose the lightest safe isolation tier

- [ ] Do not start with "VM for everything"; start with the threat model and choose the minimum safe tier.
- [ ] Use Tier 0 only for non-sensitive, non-actioning work.
- [ ] Use Tier 1/2 when trusted agents need productivity but must respect path, command, network, and budget limits.
- [ ] Use Tier 3 for untrusted repositories, unknown MCP servers, downloaded scripts, or experimental tool bundles.
- [ ] Use Tier 4 for irreversible or customer-visible actions.

### 3. Set read/write/tool boundaries

- [ ] Separate read permissions from write permissions.
- [ ] Keep secrets outside agent-readable paths and environment dumps.
- [ ] Require an explicit allowlist for shell commands, MCP tools, API endpoints, browser domains, and outbound network destinations.
- [ ] Deny credential discovery, token printing, bulk export, and hidden background daemons unless a human approves.

### 4. Add approval gates before high-impact actions

- [ ] Require human approval before deploy, delete, refund, charge, email blast, data export, permission change, or production config edit.
- [ ] Record the proposed action, risk tier, evidence, expected rollback, and approving owner.
- [ ] Use single-use approvals where possible; do not let one approval authorize a broad class of future actions.
- [ ] Make the kill switch accessible outside the agent chat/session.

### 5. Prove the controls work

- [ ] Run a harmless prompt-injection egress test.
- [ ] Try a blocked path, blocked command, and blocked network destination.
- [ ] Confirm logs capture agent ID, run ID, tool call, input summary, output summary, approval result, and evidence link.
- [ ] Run one rollback drill before letting the agent touch production.

### 6. Package the result for owners

- [ ] Produce a one-page sandbox decision record.
- [ ] Include the selected tier, why heavier/lighter tiers were rejected, open risks, owner approvals, and next review date.
- [ ] Keep a weekly list of blocked actions; blocked actions reveal either useful guardrails or friction to tune.

## Sandbox decision record template

```text
Agent/tool:
Owner:
Primary job:
Data classes accessible:
State-changing actions allowed:
Selected sandbox tier:
Why this tier:
Explicit denials:
Approval-required actions:
Egress destinations allowed:
Budget ceiling:
Run-log location:
Rollback/kill-switch owner:
Next review date:
```

## Consultant packaging angle

Sell this as a focused safety-and-productivity diagnostic for teams adopting AI agents:

- **$250-$500 agent sandbox triage:** inventory one agent, assign sandbox tier, define denials and approvals.
- **$750-$1,500 agent threat-model sprint:** map 3-5 agents/tools, create the decision records, run blocked-action tests, and train owners.
- **$2,000-$4,000 agent control-plane setup:** combine sandbox tiers with local firewall, authorization boundaries, spend ledger, observability, and rollback evidence.

## OperatorForge AI upsell

This checklist pairs with the OperatorForge AI Pro Pack bonuses for agent firewall, authorization boundary, observability, rollback, verification, instruction governance, skill security, and coding-agent cost controls.