3. Runtime, Sandbox & Autonomy

How to contain what AI agents can do at runtime — sandbox isolation, network egress, browser access, filesystem scope, approvals, and scheduled task governance.

Last reviewed: August 18, 2026

What an AI agent can do at runtime is as important as what data it can see. Sandbox isolation, network egress controls, browser access policies, and approval gates determine whether an agent's actions are contained or catastrophic.

Articles in this section

1. 3.1 What Even is an AI Sandbox?
2. 3.2 Approval policies and least-privilege autonomy
3. 3.3 Network egress control
4. 3.4 Internet access and browser automation
5. 3.5 Computer Use / desktop control risks
6. 3.6 Scheduled and background tasks
7. 3.7 Remote access, dispatch and SSH
8. 3.8 File and filesystem access controls
9. 3.9 Central hosted-agent runtime hardening

Frequently asked questions

What is the minimum safe runtime boundary for an agent? Use the narrowest filesystem, network, credential, tool, duration, and action scope that supports the approved task. Separate the orchestrator from tool execution where feasible, require approval beyond the baseline, and test termination before production.

Why do local and hosted execution need separate reviews? They have different isolation, credential, data-retention, network, evidence, and incident-containment paths. A product setting may enable both without applying the same controls to both runtimes.

Related handbook guidance

• AI Security Handbook
• 1.7 Human-in-the-loop and approval policies
• 5.1 Prompt injection: the connective risk
• 6.2 OpenTelemetry for AI runtime visibility