Security

A factual description of how Sandbox as a Service isolates workloads and protects account data. Everything below describes what the system does today. Where we do not have something, the last section says so.

Last updated: 22 August 2026

Isolation model

Every sandbox is a dedicated virtual machine with its own kernel, filesystem, memory and network stack — not a container sharing a host kernel with other customers. The isolation boundary is the hypervisor, which matters when you are executing code that a language model wrote and nobody reviewed.

• A machine is single-tenant for its whole life: one sandbox, one account.
• A machine is never reused between accounts. When a sandbox is destroyed, the machine is destroyed with it, disk included. There is no path by which one customer's machine is handed to another.
• Every sandbox is created from a prepared image at the moment you ask for one; no machine is ever handed from one customer to another. The platform can also hold pre-booted machines in reserve to cut start-up latency, and such a machine has never served a tenant; when one is claimed a reset step kills stray processes and wipes /workspace and the sandbox user's home directory, re-creating them from a clean skeleton — and if that reset does not report success, the machine is destroyed rather than used.
• Pooled machines that exceed a maximum age are recycled and replaced.

Inside the sandbox

The sandbox image is hardened before any customer code runs:

• Your commands run as the unprivileged sandbox user, never as root. That user has no sudo and no access to the control-plane SSH key; /root and /root/.ssh are mode 700.
• The cloud metadata endpoint is blocked by firewall rules scoped to the sandbox user, so code running in the sandbox cannot read provider metadata or instance user-data.
• Outbound SMTP is blocked on ports 25, 465 and 587 over both IPv4 and IPv6, as an anti-spam measure.
• Resource limits are applied to the sandbox user through limits.conf: caps on the number of processes, open file descriptors and maximum file size, so a runaway process cannot exhaust the machine.
• SSH is locked down: password authentication is disabled, root login is key-only, and the sandbox user is explicitly denied SSH access. Only the control plane can log in, with a key.
• Command output is capped at 1 MiB per stream and the result is flagged as truncated, so a noisy process cannot flood the control plane.

Inside those bounds, the machine is yours: you can install packages, write files anywhere the sandbox user can write, and make outbound network connections other than SMTP.

Tenant isolation in the control plane

Every operation on a sandbox, an API key, an execution record or a billing record is scoped to the authenticated account in the database query itself — lookups are filtered by user_id server-side. Ownership is derived from your credentials, never taken from client input, so there is no request shape in which passing another account's sandbox id returns their data: it returns a 404.

Entitlement and quota checks (balance, suspension status, concurrent sandbox limit, global capacity) run server-side before anything is provisioned. Internal host details — the underlying machine's id and address — are stored but never returned by the API, and the sandbox's hostname does not carry the machine's private address. We do not claim to hide which cloud platform a sandbox runs on: you have a root-adjacent shell on a machine, and the hardware identifiers a Linux system exposes are readable from inside it. What we do enforce, and verify before a machine is used, is that the sandbox cannot reach the platform's instance credentials, private networks, or our control plane.

API keys

Keys are 24 bytes from the system CSPRNG, prefixed aas_sk_. We store a scrypt hash (N=16384, r=8, p=1, per-key random salt) plus the first 16 characters as a lookup prefix, and verification is a constant-time comparison. The plaintext key is returned exactly once, at creation, and we cannot recover it afterwards. Keys can be revoked from the dashboard at any time and stop working immediately; you can hold up to ten active keys, and each key's last-used timestamp is recorded so you can spot ones you have forgotten about.

Sessions

Browser sessions use an opaque random session id stored server-side in Postgres, delivered in a cookie together with an HMAC-SHA256 signature that is verified in constant time. The cookie is httpOnly (so page scripts cannot read it), SameSite=Lax and Secure in production, and expires after 30 days. Signing out deletes the server-side record, not just the cookie.

Payments

All card data is handled by Stripe. Card numbers are entered on Stripe's checkout, never on our pages, and never reach our servers or our database — we store only a Stripe customer id and our own credit ledger. Stripe webhooks are signature-verified before processing, and processing is idempotent: each event id is recorded once and duplicates are ignored, so a retried webhook cannot credit an account twice. The amount credited is taken from what Stripe reports it actually collected, not from client-supplied metadata.

Transport and browser hardening

The site and API are served over HTTPS only, with Strict-Transport-Security (one year, includeSubDomains) in production. Responses carry a Content Security Policy, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, frame-ancestors 'none', a restrictive Referrer-Policy and a Permissions-Policy disabling geolocation, microphone and camera. Rate limits apply to sensitive endpoints. Every response carries a request id, which is also written to our logs and is the fastest way for support to find your specific request; Authorization headers, cookies and token-like fields are redacted before anything is logged.

Lifecycle guarantees

Sandboxes are not supposed to outlive their purpose, and we treat a leaked machine as a security problem as much as a billing one:

• Every sandbox has a timeout, and a sweeper destroys expired sandboxes every minute.
• A reconciler runs every five minutes and compares the machines that exist at the provider against the ones we track. Machines we cannot account for are destroyed; records whose machine has vanished are marked deleted; teardowns that failed are retried rather than silently marked complete.
• If provisioning fails part-way, the machine is deleted before the error is returned.
• When credit runs out, running sandboxes are torn down rather than left running unpaid.

Reporting a vulnerability

Send it to security@sandbox-as-a-service.com with enough detail to reproduce: request and response, affected endpoint, the account or sandbox ids involved. We will acknowledge your report and keep you updated. Please give us a reasonable window to fix an issue before publishing it, and while testing, stay within your own account — do not access other customers' data, do not run denial-of-service tests against the platform, and do not use a vulnerability to obtain more data than you need to demonstrate it. We do not run a paid bug bounty, but we will credit you if you want to be credited.

What we do not claim

Security pages tend to imply more than is true, so plainly:

• We hold no SOC 2 report, no ISO 27001 certification, no PCI DSS attestation of our own (card data is Stripe's scope, not ours) and no HIPAA compliance programme. Do not use this service for protected health information.
• We have not commissioned a third-party penetration test or security audit. If we do, this page will say so, with a date.
• There is no uptime SLA. The service is provided as is — see the terms.
• Sandbox contents are not backed up and not recoverable. Ephemerality is the product, not a limitation we are working around.
• We do not offer a signed data processing agreement with custom terms, dedicated single-tenant infrastructure, or a private deployment today.
• Hypervisor isolation is strong, but no isolation boundary is perfect. Treat a sandbox as a place where damage is contained, not as a place where it is impossible.

If a compliance requirement on this list is a blocker for you, tell us at info@productivity-boost.com. We would rather know what people need than publish a badge we have not earned.