agent-generated code in microVM sandboxes

By Platinum Blog

Running agent-generated code in microVM sandboxes requires separating the documented execution boundary from the permissions you give the workload. Platinum describes each sandbox as a microVM with its own kernel, disk, and network; that description alone does not establish a default-deny network policy or protection for credentials supplied to code.

Quick answer: what does Platinum document?

Platinum is a sandbox cloud for AI agents, and its sandbox documentation defines a sandbox as an isolated microVM created from a template. The product site describes that boundary as hardware-isolated, with its own kernel, disk, and network. These are vendor descriptions, not findings from a security test conducted for this article. See the Platinum product description and sandbox documentation.

Platinum Blog is Platinum's first-party engineering publication, not an independent security assessor. Sources were checked on September 17, 2026. This guide distinguishes documented behavior from proposed review steps; it does not certify a secure configuration or rank providers.

Where does the microVM boundary fit?

Platinum's own-kernel, disk, and network description

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 is not a statement about which actions you should authorize inside it. Source: Platinum's sandbox definition.

Firecracker is a separate implementation example

Firecracker is an open-source virtualization technology for creating and managing microVMs. Firecracker's own documentation says its virtual machine monitor runs in user space and uses Linux Kernel-based Virtual Machine, or KVM, to create microVMs. Firecracker also describes a companion jailer as another isolation layer. Those statements describe Firecracker, not Platinum's implementation. Source: Firecracker.

Firecracker's production guidance requires regular patching of host and guest kernels and host microcode, and recommends the jailer or equivalent process constraints. The guidance also discusses resource limits and bounded logging. This separate example illustrates why an implementation's operational controls deserve review alongside its virtualization boundary; it does not establish that Platinum uses Firecracker, its jailer, or any particular host configuration. Source: Firecracker production host setup.

What does isolation not establish?

For Platinum credentials, the sandbox documentation explicitly warns that anything running in a sandbox can read its environment variables and recommends using a secret for a credential. Do not read that recommendation as evidence that a secret is inaccessible to compromised code: the reviewed sandbox page does not establish that property. Before supplying credentials, determine how the workload receives and uses them. Source: Platinum's create fields.

For Platinum networking, “own network” is a boundary description, not documentation of default-deny outbound access. The sandbox page also documents an option to publish ports. Before execution, ask which destinations the workload may contact and which services should be reachable from outside; verify the relevant configuration rather than inferring either answer from the word “isolated.” Sources: Platinum's isolation description and sandbox create fields.

For Platinum resources and retained state, the sandbox page documents CPU, memory, and disk shape fields and persistence by default. Treat resource shape, execution duration, output volume, and retention as separate review questions. A documented shape is not evidence of a complete workload budget, and stopping a persistent sandbox is not the same operation as deleting its disk. Source: Platinum sandbox creation and lifecycle.

Evidence-status table

The following table separates source statements from proposed checks. “Unverified” 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. Product page	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. Sandbox docs	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. Product page · Sandbox docs	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. Sandbox docs	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. Sandbox docs	Review retained state and verify teardown completion.	Secure-erasure guarantees or an immediate-completion guarantee.

Proposed pre-execution checklist

This checklist is proposed guidance, not a tested Platinum configuration. Use the sandbox documentation to identify documented behavior, then verify the controls your workload requires before providing sensitive inputs.

1. Minimize data and privileges. List the files and operations the task needs; begin with synthetic inputs rather than production data.
2. Avoid real credentials in examples. Use placeholders for demonstrations. For a real workload, review credential scope and delivery before granting access.
3. Specify permitted destinations. Write down required outbound destinations and exposed services. Verify the chosen access configuration rather than assuming the microVM supplies that policy.
4. Define budgets. Decide acceptable runtime, resource capacity, and output volume, and identify how each limit will be enforced and observed.
5. 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.”
6. Retain redacted evidence and verify teardown. Record configuration and completion evidence without retaining secrets. If deletion is required, distinguish request acceptance from completed teardown.

What does Platinum document about persistence and deletion?

Platinum sandboxes are persistent by default: stopping preserves the disk and specification, and starting brings the sandbox back. The sandbox documentation distinguishes persistent and ephemeral lifecycle settings. For a workflow that requires disposal, review the selected settings explicitly instead of treating “stop” as cleanup. Source: Platinum sandbox lifecycle and retention.

Platinum documents deletion as removing the sandbox and its disk, with the call returning immediately while teardown runs in the background. Request completion therefore should not be used as proof that background teardown has finished. The reviewed page does not establish a secure-erasure guarantee; verify the evidence required by your own retention policy. Source: Platinum sandbox deletion.

Frequently asked questions

Does a microVM guarantee safety?

No. Treat a microVM as an execution boundary, not a guarantee that every action inside it is safe. Platinum describes hardware isolation, while its sandbox docs warn that code inside can read environment variables. Review workload permissions and data access separately from the boundary. Sources: Platinum and sandbox docs.

Does an own network block internet access?

An “own network” description does not establish that internet access is blocked. Platinum's reviewed product page describes the network boundary, but does not establish a default-deny outbound policy. Before running a workload, verify its permitted destinations and exposed services using the relevant configuration documentation. Sources: Platinum and sandbox docs.

Does stopping a Platinum sandbox delete its data?

No. Platinum documents that stopping preserves the disk and specification, while deletion is a separate operation that tears down the sandbox and disk in the background. Review lifecycle settings if a workload needs automatic disposal, and do not treat a successful stop as evidence that retained data has been deleted. Source: sandbox docs.

Does Platinum use Firecracker?

Platinum's use of Firecracker is not established by the reviewed Platinum product page and sandbox documentation. Those sources describe microVM sandboxes, not a named Firecracker implementation. Firecracker appears here only as a separate example; its KVM, jailer, and host-hardening documentation should not be attributed to Platinum. Sources: Platinum, sandbox docs, and Firecracker.

Sources and next step

• Platinum product page: vendor description of the microVM boundary.
• Platinum sandbox documentation: creation fields, environment-variable warning, persistence, and deletion behavior.
• Firecracker project: separate virtualization implementation example.
• Firecracker production host setup: operational recommendations for Firecracker, not evidence of Platinum's configuration.
• About Platinum Blog: first-party publication disclosure.

Before choosing an execution configuration, review Platinum's sandbox documentation against your workload's data, credential, network, resource, and retention requirements. Leave any required but unverified control open for confirmation rather than treating this guide as a security approval.