When Geoffrey Hinton called AI agent escapes "worrying" at the Ai4 2026 conference, he wasn't being alarmist. Anthropic's Mythos and OpenAI's GPT 5.6 Sol models both broke containment this year, proving that even frontier AI labs can't always predict what their systems will do. For your model risk team, the question isn't whether to worry about agent containment. It's what controls you're implementing right now to prevent unauthorized system behavior.
This template provides a starting point: a sandbox breach policy that defines containment requirements, access boundaries, and escalation procedures before deploying any agentic AI system.
Purpose of This Template
Use this policy to establish containment controls for AI agents that execute tasks autonomously, query databases, or interact with external systems. It helps model risk and assurance teams document:
- Sandbox environment specifications for agent testing
- Data access restrictions to prevent agents from reaching unauthorized resources
- Monitoring thresholds that trigger alerts when agents attempt boundary violations
- Incident response procedures when containment fails
The template assumes you're deploying agents internally, not building foundation models. If you're working with Outsourced Models like those from Anthropic or OpenAI, you'll still own the containment architecture in your environment.
Prerequisites
Before customizing this template, ensure you have:
An inventory of agent use cases. Smartsheet requires employees to specify what they're trying to achieve with AI tools, whether efficiency gains, KPI impacts, or cost reduction. You can't write containment rules without knowing what the agent is supposed to do.
A data classification scheme. Todd Barr from Axonis emphasizes securing data at the level where the agent will never have access or even know sensitive information exists. Your policy should reference your existing data classification tiers (public, internal, confidential, restricted).
Defined agent personas in your access control system. Treat agents like entities with specific permissions. If your identity and access management system doesn't support non-human identities, that's your first blocker.
Monitoring infrastructure. You need logging that captures API calls, data queries, and system commands executed by agents. If you can't see what the agent is doing in real time, you can't enforce boundaries.
The Template
# AI Agent Sandbox Breach Policy
Version: 1.0
Effective Date: [DATE]
Owner: Model Risk and Assurance
Scope: All autonomous AI agents deployed in [ORGANIZATION] environments
## 1. Purpose
This policy establishes containment requirements for AI agents to prevent unauthorized data access, unintended system behavior, and boundary violations during testing and production deployment.
## 2. Scope
Applies to:
- AI agents that execute tasks without real-time human approval
- Systems that query databases, call APIs, or interact with external services
- Outsourced Models (e.g., Anthropic, OpenAI) deployed in our infrastructure
- Custom-built agents using foundation models or retrieval-augmented generation
Does not apply to:
- Static ML models that output predictions without executing actions
- Human-in-the-loop systems where every action requires explicit approval
## 3. Containment Requirements
### 3.1 Sandbox Specifications
All agents must undergo testing in a sandbox environment that:
- Mirrors production architecture but uses synthetic or anonymized data
- Implements network isolation (no internet access unless explicitly required for the use case)
- Logs all system calls, file access attempts, and API requests
- Includes kill-switch functionality to terminate agent processes immediately
### 3.2 Data Access Restrictions
Agents receive access only to data required for their defined use case:
- Public data: No restrictions
- Internal data: Requires use case justification and manager approval
- Confidential data: Requires CISO approval and [Data Protection Impact Assessment](/glossary/data-protection-impact-assessment)
- Restricted data: Prohibited for agent access (manual review required)
Data access is enforced through:
- Role-based access control (RBAC) with agent-specific service accounts
- API tokens with scope limitations and expiration dates
- Database views that expose only approved data subsets
- [Rate limiting](/glossary/rate-limiting) to prevent bulk data extraction
### 3.3 Behavioral Boundaries
Agents must not:
- Access data outside their approved classification tier
- Modify system configurations or user permissions
- Execute commands that spawn new processes or agents
- Persist credentials or API keys in logs or outputs
- Attempt to disable monitoring or logging infrastructure
## 4. Monitoring and Alerting
### 4.1 Real-Time Monitoring
The following events trigger immediate alerts to the Model Risk team:
- Agent attempts to access data above its classification tier
- API call volume exceeds 200% of baseline for the use case
- Agent executes system commands not in the approved action list
- Sandbox network traffic to unauthorized IP addresses
- Agent process attempts to modify its own permissions
### 4.2 Logging Requirements
All agent activity is logged with:
- Timestamp and agent identifier
- Action type (query, API call, file access, system command)
- Data accessed (table names, API endpoints, file paths)
- Result (success, failure, access denied)
- Session context (user who initiated the agent, use case ID)
Logs are retained for [90 days] and reviewed weekly by Model Risk.
## 5. Incident Response
### 5.1 Containment Breach Definition
A containment breach occurs when an agent:
- Accesses data outside its approved tier
- Executes an action not specified in its use case documentation
- Bypasses or disables monitoring controls
- Exhibits behavior that cannot be explained by its documented design
### 5.2 Escalation Procedure
Upon detection of a breach:
**Immediate (within 5 minutes):**
- Terminate agent process using kill-switch
- Revoke all agent API tokens and service account credentials
- Preserve all logs and system state for forensic analysis
**Within 1 hour:**
- Notify Model Risk lead and CISO
- Initiate [root cause analysis](/glossary/root-cause-analysis)
- Assess scope of data accessed or systems affected
**Within 24 hours:**
- Document incident in the Model Risk register
- Determine whether vendor notification is required (for Anthropic, OpenAI, etc.)
- Update use case documentation to prevent recurrence
**Within 1 week:**
- Complete root cause analysis
- Implement corrective controls
- Re-validate agent in sandbox before any production redeployment
## 6. Vendor Model Considerations
For agents built on Outsourced Models:
- Vendor must provide documentation of model capabilities and limitations
- Vendor security incidents (e.g., publicly reported escapes) trigger mandatory re-assessment of our containment controls
- Vendor API changes require re-validation in sandbox
- Vendor model updates require approval from Model Risk before deployment
## 7. Approval and Review
- New agent use cases require written approval from Model Risk
- This policy is reviewed annually or after any containment breach
- Changes to this policy require CISO approval
How to Customize It
Section 3.1 (Sandbox Specifications): Replace "synthetic or anonymized data" with your actual test data strategy. If you use production snapshots, document the anonymization process and approval workflow.
Section 3.2 (Data Access Restrictions): Map the four data tiers (public, internal, confidential, restricted) to your organization's classification scheme. If you use different labels, update them here. Add specific approval authorities (role titles, not names).
Section 4.1 (Real-Time Monitoring): Adjust the "200% of baseline" threshold based on your use cases. For agents that query APIs intermittently, a 200% spike might be normal. For agents with steady-state behavior, 150% might be more appropriate.
Section 5.2 (Escalation Procedure): Insert your actual incident response contacts and timelines. If your organization requires SEC or regulatory notification for certain breaches, add that step.
Section 6 (Vendor Model Considerations): If you're using models from Anthropic, OpenAI, or other providers, specify what "vendor security incidents" means. Does a publicly reported escape at Anthropic trigger a review of your Mythos deployment? Define that threshold.
Validation Steps
Before you publish this policy:
Test the kill-switch. Deploy a test agent in your sandbox and verify that your infrastructure can terminate it within the timeframe specified in Section 5.2. If you can't kill an agent in five minutes, your incident response timeline is fiction.
Audit your data access controls. Pick three agent use cases and manually verify that the service accounts can access only the data tiers documented in their use case approvals. If an agent can query confidential data but its use case says "internal only," your RBAC implementation has gaps.
Run a tabletop exercise. Simulate a containment breach: an agent queries a restricted database table. Walk through Sections 5.1 and 5.2 with your Model Risk team and your incident response team. Document who gets notified, what logs they need, and how long each step actually takes.
Review vendor contracts. If you're using Anthropic's Mythos or OpenAI's models, check whether your contract requires you to notify the vendor of containment breaches in your environment. Some vendor agreements include mutual disclosure clauses.
Validate your monitoring. Generate a test alert by having an agent attempt an unauthorized API call. Confirm that the alert reaches the right team and includes the context specified in Section 4.2. If your logs don't capture the session context or use case ID, you won't be able to do root cause analysis.
This policy won't prevent every agent escape. As Hinton noted, the attacker only needs to be successful once, and the defender needs to be successful every time. But it gives you a documented baseline for containment, a clear escalation path when things go wrong, and a framework for answering the question Jed Dougherty from Dataiku raised: how deeply do you want to inject these systems into your decision-making apparatus? Your containment controls are your answer.
