Decentralised News · Batch 2, Article 37
The fastest place to run agent code is useful only when its boundary matches the job.
By Heath Muchena · 8 October 2026 · DN-SF v1.0 · 2027 planning edition
What Matters
An agent sandbox limits code execution, but its usefulness depends on network access, mounted files, credentials and lifecycle controls. Fast startup does not prove strong containment. DN proposes evaluating mandatory boundaries first, then comparing compatibility, readiness time and cost per accepted task. This edition includes a Sandbox Fit Selector and test register, with no invented vendor rankings or live breakout claims.
DN Evidence Block
Last verified: 8 October 2026. Review period: official architecture documentation reviewed for this edition. Sample: gVisor security model and Firecracker design documentation; zero DN live sandbox runs or breakout tests. Author: Heath Muchena. Independent reviewer: none recorded.
Decisive facts: the sources describe different isolation architectures and their assumptions. Neither document certifies an arbitrary hosted agent service or a reader’s installation. DN-SF is a proposed evaluation method, and its selector records reader-supplied evidence.
DN Alpha Thesis: containment has several doors
An agent can generate code, install packages and manipulate files inside a restricted environment. That is a useful boundary. The same agent may also hold a customer database token, call an external service or write to a shared drive. Those permissions can carry consequences beyond the sandbox even when its compute isolation works as designed.
DN’s thesis is that buyers need a map of the doors, not a reassuring product label. Which files can the workload read? Which destinations can it reach? Which credentials are available? What survives termination? Every answer changes the practical boundary.
The proposed index therefore uses requirements as gates. A workload that requires blocked outbound access cannot trade that requirement for a faster startup score. After the mandatory controls pass, teams can compare task compatibility, latency and ownership cost.
What different architectures establish
| Architecture | Boundary to inspect | Buyer question |
|---|---|---|
| Conventional container | Shared host kernel, namespaces, capabilities and configured restrictions | Does the threat model permit this boundary for the workload? |
| Application-kernel sandbox | Interposed system interface, host interactions and supported operations | Do the required libraries and tools work under its restrictions? |
| MicroVM | Guest environment, virtualization boundary and host control plane | How are network, images, mounts and lifecycle managed? |
| Managed service | Underlying runtime plus service APIs, identities and policies | Which guarantees apply to this plan and configuration? |
gVisor describes an application-kernel approach intended to reduce exposure to the host kernel. Its security model sets out assumptions and limitations. Firecracker describes lightweight virtual machines built around a deliberately limited device model. These are architectural distinctions, not measured DN rankings.
A stronger compute boundary can still be paired with overly broad credentials. A restricted runtime can also reject software the agent needs. Test both the boundary and the actual workload rather than assuming that one architecture name resolves every decision.
The six dimensions of a useful sandbox
| Dimension | Evidence required | Failure that matters |
|---|---|---|
| Isolation | Threat model, exact runtime and host configuration | Workload can reach resources outside its permitted boundary |
| Network and secrets | Destination policy, scoped credentials and revocation behavior | Disallowed destination or credential becomes reachable |
| Workload support | Task fixture, dependencies, browser or GPU needs | Required task cannot complete under the controls |
| Lifecycle and persistence | Timeout, teardown, restore and storage policy | Unexpected state or access survives disposal |
| Observability | Attributable events with appropriate retention and redaction | Incident cannot be reconstructed without exposing secrets |
| Performance and cost | End-to-end latency and complete accepted-task ledger | Queueing or repair erases apparent startup savings |
Sandbox Fit Selector
Select requirements for one candidate and mark the supporting evidence. All entries begin unverified. This is a requirements coverage tool, not a vendor recommendation or penetration test. Repeat it for each candidate using the same requirements.
Evidence not yet assessed
Why startup benchmarks can mislead
A sandbox can be created quickly while the task still waits for a package install, image download, browser launch or network connection. Define “ready” as the point at which the chosen workload can begin useful work. Report request-to-ready time and request-to-accepted-outcome time separately.
Cold starts and prewarmed capacity are different operating conditions. Record image cache, dependency cache, region, resource size and concurrency. If a service reserves idle capacity to achieve low latency, include that cost in the comparison.
Measure failures and queue time alongside successful runs. Reporting only the fastest successful launches can conceal timeouts and capacity limits. Publish sample size, median and tail latency for matched conditions, and identify the percentile calculation used.
DN’s proposed lifecycle test register
The following fixtures are proposed evaluation cases. No observed service scores are published.
| Fixture | Expected evidence | System boundary |
|---|---|---|
| Fresh task launch | Readiness and accepted completion with declared dependencies | Provisioning through final output |
| Denied outbound request | Policy blocks a controlled test destination | Sandbox plus network enforcement |
| Scoped file access | Allowed files work; synthetic forbidden files remain unavailable | Mounts and storage permissions |
| Resource exhaustion | Limits enforced; unrelated workloads remain available | Sandbox and host allocation |
| Timeout and disposal | Processes, access and persistence match declared policy | Runtime, tokens and storage |
| Resume or restore | Correct task state without unintended shared state | Snapshots, storage and identities |
Run controlled fixtures only in environments you are authorized to test. Use synthetic files, disposable credentials and owned destinations. These routine policy checks do not establish resistance to every exploit or side channel. Specialist isolation review remains a different evidence category.
The external-action problem
Terminating compute does not necessarily reverse a message, payment or database update already submitted elsewhere. Treat those actions as a separate authority boundary. Record action identifiers, enforce scope outside the model and reconcile outstanding operations after interruption.
Snapshots also deserve scrutiny. They can preserve configuration or sensitive state that a team expected to disappear. Document what is captured, who can restore it and when it expires. A successful restart is not proof of appropriate data retention.
For agentic trading, the sandbox should not be mistaken for an exchange permission system. Order limits, credential scope and withdrawal restrictions must be enforced at the relevant integration boundary. This edition does not assess any venue or wallet.
Choose by workload, then measure complete cost
| Workload | Best next evaluation | Avoid choosing on |
|---|---|---|
| Disposable code execution | Isolation, dependencies, limits and disposal | Launch speed alone |
| Browser automation | Browser support, network policy and credential scope | Generic container compatibility |
| Long-running analysis | Timeouts, storage, recovery and resource allocation | A short demo task |
| Sensitive data processing | Entire data path, permissions, logs and deletion | A “secure sandbox” label |
Total cost should include compute, idle allocation, storage, network, control-plane charges, retries and human maintenance. Divide that ledger by accepted tasks over the same period. Include failed work in cost. Disclose shared overhead allocation and avoid counting charges twice.
Request exact plan limits, supported regions, retention terms and access conditions before committing. This methodology edition includes no paid placements, affiliate links or unverified “best sandbox” rankings.
Methodology, limitations and falsification
DN-SF v1.0: the selector covers six proposed requirements. Each is required by default, with evidence states of unverified, verified or failed. Coverage equals verified required requirements divided by all required requirements. Removing a requirement changes scope and must be justified in the evaluation record.
Decision rule: any failed required item blocks fit. Unknown required evidence leaves fit unresolved. Full verified coverage means only that the reader reported evidence for all selected requirements; it does not prove containment or authorize production deployment.
Limits: no live breakout testing, independent audit, provider comparison or measured performance dataset was produced. The tool cannot verify uploaded evidence, configuration drift or exploit resistance. Documentation describes design intent and assumptions.
Falsification: a boundary claim fails if a controlled authorized test reaches a resource it should not, or if lifecycle behavior contradicts the declared policy. A performance claim fails if matched full-workflow measurements exceed the asserted threshold. Preserve failing evidence and retest after remediation.
Maintenance: version the runtime, image, policies and fixture set. Reassess after changes to mounts, credentials, network access or persistence, even when the service brand remains unchanged.
What to do next
Write down one workload’s mandatory boundaries, complete the selector and run a bounded compatibility and lifecycle pilot. Collect performance data only under the controls you intend to deploy. For the compute economics, see DN’s Local vs Cloud Agents guide.
Frequently asked questions
What is an agent sandbox?
An execution environment that limits what agent-run code can access. Its actual boundary depends on the runtime, host configuration, network policy, mounts, credentials and connected tools.
Is a container the same as a microVM?
No. Conventional containers generally share a host kernel, while microVMs use hardware virtualization. Additional runtimes can introduce other boundaries. Architecture alone does not establish a deployment security ranking.
Can a sandbox prevent prompt injection?
It can limit consequences of code execution, but it does not establish that model instructions or tool decisions are trustworthy. Authorization and data policies need their own enforcement.
Does stopping the sandbox cancel external actions?
Not necessarily. A remote request may already have reached another service. Check action state, revoke credentials where appropriate and reconcile external side effects.
Is faster startup always better?
No. Compare readiness for the actual task, successful completion and full cost after required controls pass. Prewarmed and cold-start measurements must be disclosed separately.
What does the Sandbox Fit Selector score mean?
It reports the share of your selected requirements marked verified for one candidate. Unknown evidence remains visible, failed requirements block fit, and the output is not a security certification.
Does this article publish tested vendor rankings?
No. This edition provides a proposed evaluation register and a reader-input selector. DN has performed no live sandbox comparisons or breakout tests.
What evidence should a buyer request?
A current threat model, exact boundary and configuration, policy documentation, workload compatibility results, lifecycle behavior, logs and measured performance under realistic load.
Change log and corrections
8 October 2026 · v1.0: initial requirements method, six-fixture register and Sandbox Fit Selector. No observed provider performance published.
Use the contact route on Decentralised News for corrections. Identify DN-SF v1.0 and provide the disputed statement and supporting source without secrets or confidential traces.
