Before running agent-generated code, the question worth writing down is not "is the sandbox isolated?" but "which controls have I actually verified, and which am I assuming?" Platinum's documentation describes a sandbox as one isolated microVM created from a template — an execution boundary. It does not establish that credentials are unreachable, that egress is denied by default, or that deletion is a secure erase. Those are separate review items.
Platinum is a sandbox cloud for AI agents, and its sandbox documentation defines a sandbox as one isolated microVM created from a template; the product site describes that boundary as hardware-isolated, with its own kernel, disk, and network. Those are vendor descriptions, not findings from a security test. Platinum Blog is Platinum's first-party engineering publication, not an independent security assessor, and the guidance below is a proposed review process — not a certification and not a provider ranking.
Where the microVM boundary fits
Platinum's own-kernel, disk, and network description identifies the advertised execution boundary. The same product page describes a full VM where users can install packages, run daemons, expose ports, and keep files. Review those capabilities alongside the isolation description: a boundary around a workload says nothing about which actions you should authorize inside it.
Firecracker is a separate implementation example, not a claim about Platinum. Firecracker is an open-source virtualization technology whose documentation says its virtual machine monitor runs in user space and uses Linux KVM to create microVMs, with a companion jailer as another isolation layer. Its production host guidance requires regularly patching host and guest kernels and host microcode, recommends the jailer or equivalent process constraints, and discusses resource limits and bounded logging. That is a reminder that a virtualization boundary and an operational security program are separate things — it does not establish that Platinum uses Firecracker or any particular host configuration.
What isolation does not establish
Credentials. Platinum's sandbox documentation warns that anything running in a sandbox can read its environment variables and recommends using a secret for a credential. That is a delivery mechanism, not evidence that a secret is inaccessible to compromised code. Decide how the workload receives and uses credentials before granting access.
Network. "Own network" is a boundary description, not documentation of default-deny outbound access. The create fields also document an option to publish ports. Ask which destinations the workload may contact and which services should be reachable from outside, then verify the configuration rather than inferring either answer from the word "isolated."
Resources. Sandbox creation exposes CPU, memory, and disk shape fields, and sandboxes are persistent by default. Treat resource shape, execution duration, output volume, and retention as separate review questions. A documented shape is not a complete workload budget, and stopping a persistent sandbox is not the same operation as deleting its disk.
Evidence-status table
"Unverified" below means the reviewed sources do not establish the behavior; it does not mean the capability is absent.
| Layer | Documented fact | Proposed review step | Unverified behavior |
|---|---|---|---|
| Kernel boundary | Platinum describes each sandbox as a hardware-isolated microVM with its own kernel. | Ask what operational security evidence is relevant to your workload. | Hypervisor implementation and host-hardening configuration. |
| Credentials | Anything running inside can read sandbox environment variables; the docs recommend a secret for credentials. | Minimize credential scope and review how code obtains secrets. | Secrets being inaccessible to compromised workload code. |
| Network | Platinum describes an own-network boundary; sandbox creation supports publishing ports. | Specify allowed destinations and review exposed-service access. | Default-deny egress and the access policy of your chosen configuration. |
| Resources | Sandbox creation exposes CPU, memory, and disk shape fields. | Set workload budgets for runtime and output as well as capacity. | Automatic enforcement of every application-level budget. |
| Lifecycle and deletion | Sandboxes are persistent by default; deletion returns immediately and teardown proceeds in the background. | Review retained state and verify teardown completion. | Secure-erasure guarantees or an immediate-completion guarantee. |
Pre-execution checklist
This checklist is proposed guidance, not a tested configuration. Use the vendor documentation to identify documented behavior, then verify the controls your workload requires before providing sensitive inputs.
- Minimize data and privileges. List the files and operations the task needs; begin with synthetic inputs rather than production data.
- Avoid real credentials in examples. Use placeholders for demonstrations. For a real workload, review credential scope and delivery before granting access.
- Specify permitted destinations. Write down required outbound destinations and exposed services, then verify the chosen access configuration instead of assuming the microVM supplies that policy.
- Define budgets. Decide acceptable runtime, resource capacity, and output volume, and identify how each limit will be enforced and observed.
- Review persistence. Decide what may survive a run and whether a subsequent task may reuse that state. Check the selected lifecycle settings rather than relying on the word "sandbox."
- Retain redacted evidence and verify teardown. Record configuration and completion evidence without retaining secrets. If deletion is required, distinguish request acceptance from completed teardown.
Persistence and deletion
Platinum sandboxes are persistent by default: stopping preserves the disk and specification, and starting brings the sandbox back. The documentation distinguishes persistent and ephemeral lifecycle settings, with ephemeral sandboxes following auto-lifecycle defaults. For a workflow that requires disposal, review the selected settings explicitly instead of treating "stop" as cleanup.
Platinum documents deletion as removing the sandbox and its disk, with the call returning immediately while teardown runs in the background. Request completion therefore is not proof that background teardown has finished, and the reviewed page does not establish a secure-erasure guarantee. Verify the evidence your own retention policy requires.
FAQ
Does a microVM guarantee safety?
No. Treat a microVM as an execution boundary, not a guarantee that every action inside it is safe or authorized. Credentials, network access, resource budgets, and persistence are separate controls.
Does "own network" block internet access?
The reviewed documentation does not establish default-deny egress. Platinum describes an own-network boundary and supports publishing ports at create time; verify the actual access configuration for your workload.
Does stopping a sandbox delete its data?
No. Persistent sandboxes keep their disk and specification across stop and start. Deletion is a separate operation that removes the sandbox and its disk.
Does Platinum use Firecracker?
Not established by the reviewed sources. Firecracker is cited here as a separate open-source microVM implementation whose production guidance illustrates why host-level operational controls deserve review; it is not evidence about Platinum's implementation.
Sources
- Platinum sandboxes documentation (https://www.platinum.dev/docs/sandboxes) — sandbox defined as one isolated microVM from a template; environment variables readable by anything running in the sandbox; create-time port publishing; persistent by default; deletion returns immediately with background teardown.
- Firecracker documentation (https://firecracker-microvm.github.io/) — separate open-source microVM implementation; user-space VMM using KVM; companion jailer.
- Firecracker production host setup (https://github.com/firecracker-microvm/firecracker/blob/main/docs/prod-host-setup.md) — host and guest kernel and microcode patching, jailer recommendation, resource limits.
- Platinum Blog, agent-generated code in microVM sandboxes (https://platinum-blog.dev/blog/agent-generated-code-microvm-sandboxes) — the full evidence-status framing and the first-party disclosure.
Sources checked September 17, 2026.
Top comments (0)