Built on a hypervisor boundary.
Trust verified at every layer.

Every sandbox is a Firecracker-descended microVM. That means:

• Dedicated Linux kernel. Each VM boots into its own kernel. Guest kernel bugs cannot affect the host kernel — the hypervisor is the security boundary.
• Hardware-backed memory isolation. KVM enforces page-table separation between the guest and host. No shared memory, no side-channels exposed to the guest.
• Per-VM filesystem. A copy-on-write clone of a sealed base image. No customer data enters the base; nothing persists out of the VM on destroy.
• Per-VM network segment. Each sandbox gets its own tap device. No L2 connectivity between sandboxes — even on the same host, VMs cannot see each other's packets.

This is a stronger isolation boundary than container-based sandboxes. Every Linux container escape CVE published in the last five years would not have affected a Firecracker guest — the hypervisor is on the other side of the boundary.

Short answer: no, for almost all workloads. Longer answer: we give you a non-root mode if your compliance review insists.

A Podflare sandbox is a single-tenant, disposable VM. The customer is the only user. "Root inside" means root on your own ephemeral machine — not root on the host or the hypervisor. A prompt-injected agent gaining UID 0 inside its own VM gains nothing it couldn't already do at UID 1000 (it could always rm -rf /home/podflareeither way, and the VM is getting destroyed anyway).

The real security boundary is the hypervisor. Root inside the guest doesn't weaken it.

That said — some InfoSec reviewers have "processes-don't-run-as-root" on their checklist regardless of threat model. For those customers we offer (planned, Q2 2026) a Sandbox(privileged=False) option that runs agent code as a UID 1000 user with password-gated sudo. Ask us about it if it's the blocker.

Podflare sandboxes have full outbound internet by default. This is a deliberate choice: without egress, the first line of every customer tutorial — pip install requests — fails. We prioritize the common case.

For workloads where agent-authored code might try to exfiltrate data, mine crypto, or pull malicious packages, pass egress=False at create time:

from podflare import Sandbox

with Sandbox(egress=False) as sb:
    sb.run_code(untrusted_llm_code)  # no DNS, no outbound TCP/UDP

Implementation detail: the VM's tap device is detached from the host bridge at boot. The guest's eth0 comes up (it still has its snapshot DHCP lease) but every packet dies at the host with no L2 peer. Fork children inherit the parent's egress setting — there's no escape by cloning.

Domain-allowlist egress (e.g., "only pypi.org and api.openai.com") is planned for Enterprise via an SNI-filtering proxy with credential injection. Contact sales@podflare.ai if you need it.

• No training. We never train models on customer code or data.
• No persistence without opt-in. Sandbox memory, filesystem, and REPL state are destroyed when the sandbox ends. Only sandboxes created with persistent=True are frozen to disk; those are single-region and auto-deleted on resume or customer delete.
• API keys are hashed. We store SHA-256 of every key; the plaintext is shown exactly once at mint time and never logged or transmitted again.
• Audit events (create/exec/destroy/fork/freeze) are recorded per-org and visible in your dashboard.
• Data residency. Sandboxes run in the region you choose (us-west, eu today; us-east + others on request). Cross-region data movement happens only if you explicitly route through multiple regions.

• SOC 2 Type II — engagement started; target certification Q3 2026. Interim Type I letter available for Enterprise pilots on request.
• HIPAA BAA — available for Enterprise customers with healthcare workloads. Contact sales.
• GDPR — EU region (eu, Helsinki) keeps all sandbox data in-region. DPA available for Enterprise.
• External audit — third-party security audit scheduled for Q2 2026. Report available under NDA to prospective Enterprise customers.

We're in private alpha. These certifications are in progress, not complete. If your procurement process requires a specific document we don't yet have, reply to your sales thread and we'll tell you exactly where we are.

Email security@podflare.ai with a clear reproduction, affected endpoint, and your contact info. We acknowledge within 24 hours and aim for triage within 72 hours. Responsible disclosure is welcome — if you give us a reasonable window to fix before publication, we'll credit you in the release notes.