Security#

How TaskCloud isolates sandboxes, protects access, and handles your data. Report vulnerabilities to security@task.cloud.

We do not hold SOC 2 or other certifications today. SOC 2 is planned for year 2. This page describes how the platform is built, not an audited attestation.

Isolation model#

Every sandbox is a separate Firecracker microVM with its own Linux kernel. The security boundary is the VM, not a container.

  • Firecracker jailer: each VMM process runs chrooted, unprivileged, with a seccomp filter.
  • cgroups: CPU, memory and I/O are limited per VM.
  • Network namespace per VM: each sandbox has its own tap device and namespace. Sandboxes cannot reach each other, the host, or our internal APIs.
  • Forks get their own IP, network namespace and copy-on-write disk. A change in a fork never affects the source.
  • Inside the sandbox you have root (user has passwordless sudo). Treat everything inside one sandbox as one trust domain. Give each end user their own sandbox.

API keys and scopes#

Authenticate with Authorization: Bearer taskcloud_sk_.... Keys are shown once, stored hashed, expire after 90 days by default (max 365 days or never), and can be rotated with a grace period (POST /api-keys/{id}/rotate).

Scope Allows
sandboxes:read / sandboxes:write Read / create, update, pause, resume, fork, delete sandboxes; manage ports
exec Commands and PTY sessions
files:read / files:write File access
ssh SSH access and account SSH keys
desktop Desktop stream URLs, screenshots, input
snapshots:read / snapshots:write Snapshots
templates:read / templates:write Templates
webhooks:manage Webhook endpoints
usage:read Usage and limits
account:read / account:manage Account and spend limit
api_keys:manage Create, rotate, revoke keys

Presets: read-only, full-sandbox, ci, admin. A key can never create a key with more scopes than it has. A missing scope returns 403 insufficient_scope with details.required_scopes.

Least privilege for platforms#

If your product hands sandboxes to end users or to an agent, never ship an admin key. Create a key restricted to that user's sandboxes:

curl -sS -X POST https://api.task.cloud/v1/api-keys \
  -H "Authorization: Bearer $TASKCLOUD_API_KEY" -H "Content-Type: application/json" \
  -d '{"name":"user-42","preset":"full-sandbox","restrict":{"labels":{"user":"42"}},"expires_in_days":30}'

Sandboxes created with that key automatically get the label user=42, and the key cannot see any other sandbox.

Access to sandbox endpoints#

Surface Protection
Domain separation Sandbox URLs (ports, desktop, SSH) use taskhost.cloud, a separate domain from task.cloud (website and API), submitted to the Public Suffix List. A sandbox app is never same-site with the API and cannot set cookies for task.cloud.
Port URLs https://<short_id>-<port>.taskhost.cloud private (default): requires an access token (X-Sandbox-Token header or sandbox_token query) or an API key. public: open to anyone with the URL.
Desktop stream Signed URL with TTL (default 10 minutes), optional read_only and single_use, revocable. The VNC port is never exposed without a token.
PTY WebSocket Signed URL valid 60 s until first connect.
Signed file URLs Single file, 60–3,600 s.
SSH Gateway ssh.taskhost.cloud, public-key auth (account keys or per-request keys with TTL) or a one-time password.

Give browsers short-lived access tokens (POST /sandboxes/{id}/access-tokens) instead of API keys.

Network#

  • Inbound: blocked except through our edge (exposed ports, desktop, SSH gateway). All edge traffic uses TLS.
  • Outbound: open by default. A per-sandbox egress allowlist is Coming soon.
  • Mining, spam, scanning and other abuse are prohibited and detected automatically; offending sandboxes are paused and the account may be suspended.

Data#

  • Location: EU only. Sandboxes, disks and snapshots run and are stored on dedicated servers in the EU (machines we operate ourselves and machines rented from an EU hosting provider).
  • Encryption: TLS in transit. Snapshots and disks are stored on our dedicated servers; encryption at rest details will be published before general availability.
  • Snapshots contain memory. A pause snapshot or named snapshot includes everything in RAM: environment variables, tokens, decrypted secrets. Keep that in mind before turning a snapshot into a template you share or fork for other users.
  • env and registry_auth values are write-only and never returned by the API.
  • Deletion: DELETE /sandboxes/{id} removes the disk and the pause snapshot. Named snapshots and templates are deleted separately. Snapshots kept in object storage are encrypted with a per-organization key; when an organization is deleted, its data is purged after 30 days and that key is destroyed.

Console accounts#

  • Sign-in: single-use e-mail links (15 minutes) or GitHub. Optional two-factor authentication with an authenticator app (TOTP) and single-use recovery codes; organizations can require it for members. See Teams and roles.
  • Sessions: HttpOnly, Secure, SameSite cookies; every state-changing request needs a CSRF token and the console's origin. Sessions slide for 30 days and end at most 90 days after sign-in.
  • Client IP: rate limits and the IP addresses in sessions and audit records use the real client address; X-Forwarded-For is trusted only from our own proxies.
  • API keys of people never outlive the person's membership and never exceed their current role.
  • Your data: export it or delete your account in Settings → Danger zone (details in Teams and roles).
  • E-mails from us never contain images or remote content and never ask for a code or password.

Webhooks#

Every webhook is signed with HMAC-SHA256 and carries a timestamp. Verify the signature and reject events older than 300 s. See Webhooks.

Agents and computer use#

  • Content an agent reads (web pages, files, screenshots) can contain prompt injection. Keep credentials the agent does not need out of the sandbox.
  • Use read_only desktop links for people who only watch.
  • Use restricted keys for MCP servers and agent tools (see MCP).

Not available yet#

SSO, passkeys, customer-facing audit logs, customer-managed keys, private networking, and self-hosting are on the roadmap.