Security
StateSet Sandbox runs code you did not write: agent-generated, user-supplied, untrusted by default. This page explains how we contain it, how we protect your credentials and data, and how to reach us about a security issue.
Sandbox isolation
- Each sandbox is its own Kubernetes pod. The default runtime is gVisor, a user-space kernel that stands between sandboxed code and the host kernel. Kata Containers microVM isolation is available as a per-sandbox option.
- Sandbox containers run as a non-root user with privilege escalation disabled, all Linux capabilities dropped and a seccomp profile applied.
- Network policies deny traffic by default. A sandbox accepts inbound connections only from the control plane, and the cloud metadata endpoint is blocked.
- Outbound traffic goes through an egress proxy that enforces per-organization egress policy. It fails closed: if a decision cannot be made, the connection is refused.
Encryption
- All public endpoints are served over TLS, and HTTP Strict Transport Security is sent on API responses.
- Secrets you store are encrypted with AES-256-GCM. Each record is sealed under its own key, derived with HKDF-SHA256 from a master key. Master keys can be rotated and existing records re-encrypted without downtime.
- API keys are stored only as SHA-256 hashes, so the plaintext key is shown once at creation and cannot be recovered from our database. Passwords are hashed with bcrypt.
- Outbound webhooks are signed with HMAC-SHA256 so you can verify they came from us.
- Data at rest in our cloud database and object storage is encrypted by the underlying Google Cloud services.
Access control
- Organizations have owner, admin and member roles. Individual sandboxes add owner, operator and viewer roles, so a teammate can watch a sandbox without being able to change or delete it.
- API keys can be limited to specific scopes (create, read, write) and given an expiry date. They can be revoked or regenerated at any time.
- Single sign-on is available through WorkOS, which lets you apply your identity provider’s policies (including MFA) to dashboard sign-in.
- Session cookies are HTTP-only, and cookie-authenticated requests that change state require a CSRF token.
- For the few calls a sandbox makes back to the platform it uses a token scoped to that one sandbox, invalidated when the sandbox is recycled, never your organization credentials.
Logging and monitoring
- Sandbox lifecycle actions (create, extend, fork, promote, pause, resume, terminate), secret injection and SSO changes are written to a durable audit log your organization can query. Secret values are never logged, only their names. Audit events are kept for 90 days.
- Egress decisions are recorded and kept for 30 days.
- The platform is monitored against published service-level objectives with alerting and written runbooks. Current service health is on our status page.
Secure development
- Every change runs through automated tests, CodeQL static analysis, dependency review that blocks high-severity advisories, and container image scanning that blocks high and critical vulnerabilities.
- Dependencies are kept current with automated update pull requests.
- Security boundaries such as authorization, tenant isolation and input validation are covered by tests that are checked to fail when the protection is removed.
Compliance
We do not currently hold a SOC 2 report or other third-party certification. We are building toward a SOC 2 audit and can share our security documentation with customers under NDA.
Reporting a vulnerability
Email security@stateset.com with a description, reproduction steps and the impact you observed. Please do not open a public issue.
We acknowledge reports within 48 hours and send an initial assessment within 5 business days. We credit reporters who would like to be credited.
See also our status page and privacy policy.