Security Model

Provider keys pass through Devboxes into an agent container. These boundaries show what you trust.

Anyone in your organization who can dispatch a run can execute arbitrary code in a container that receives the provider credential for the selected model. Treat organization membership, the Docker host, and those credentials as one trust boundary.

The credential broker

When a local runner executes tasks, provider keys are served to containers by a host-local HTTP server — the credential broker.

It binds 0.0.0.0 on a random port in the 34000–34999 range. Native Linux containers reach the host through the bridge gateway (host.docker.internal), not loopback.
Every request must carry the per-task bearer token that only the active task's container holds. The comparison is timing-safe (both sides are hashed to fixed-length digests first).
The broker only ever serves the provider of the requesting task. A task can never fetch another provider's key, and a finished or reassigned task's token stops working immediately.

Other machines can reach the port but not pass the token gate. Isolate the host if needed.

Keys never persist inside containers

The provider auth file is written to a memory-backed tmpfs (Docker Tmpfs mount / Kubernetes emptyDir with medium: Memory) with mode 0600, and symlinked targets are rejected.
Crash-recovery container commits exclude tmpfs and bind mounts, so committed state images can never contain key material.
Keys are never placed in container environment variables. The per-task backend token arrives as a read-only mounted file, not env.

On-disk hygiene on a runner

The device credential store — connected subscriptions and entered API keys — is age ciphertext on disk. The dashboard returns its passphrase only to the authenticated runner, which holds it in memory. Deleting the machine revokes its API key and removes the server-held passphrase. After the running process exits, the old ciphertext stays unreadable; credentials setup creates a new store.
The shared config and device credential store are protected with mode 0600 and written atomically, including when the CLI updates them.
Per-task secret files use mode 0600 and remain scoped to their assigned task.
Per-task secret directories are removed when a task ends, is stopped, is reassigned, or is cleaned up after a runner restart.

Organization-side protections

Synced credentials are encrypted with AES-256-GCM and retain the key identity needed for controlled key rotation.
Credential management requires an owner or admin role, re-checked on every request.
Bans revoke sessions at the source; short-lived JWTs (15 minutes) mean a banned member's outstanding tokens expire within 15 minutes.
Per-task run tokens are signed and bound to the organization, run, task, machine, and attempt. A requeue or reassignment invalidates every previously issued token.

Deleting a provider credential prevents future delivery. It cannot retract a credential already delivered to a running process. Stop the run or revoke the credential at the provider when that process must lose access immediately.

Machine deletion revokes future decryption through Devboxes. It does not erase plaintext or a passphrase already held by the running machine. Stop devboxes listen and contain the host before deletion when local compromise is suspected.

Where your data lives

The hosted service runs on dedicated servers in Germany — not in the EU region of a US cloud. Session data (code, events, outputs) is encrypted at rest and used only to run the service for you.
Your code is never used to train models — ours or anyone else's.
Error monitoring uses a self-hosted Sentry instance on German infrastructure; error data is not sent to Sentry, the company, or any other third party.
Data export and account deletion are built into the dashboard, and they stay available even if you decline a later terms update.

The full picture — retention, subprocessors, your GDPR rights — is the privacy policy; privacy questions go to privacy@devboxes.ai, and suspected vulnerabilities go privately to security@devboxes.ai.

Next: Troubleshooting — what to check when something sticks.