Security

One VM per Sandbox

Each Sandbox runs in its own Linux VM, not a container on a shared kernel. Your code has sudo inside it, but Ortam controls the kernel, boot, network and storage, and sudo in the VM can’t change those controls or read Ortam’s credentials. A machine is reset before it serves another Sandbox, so files and credentials don’t carry over.

Sandboxes reach the internet through NAT. The host, the cloud metadata service and private networks are blocked by rules that run outside the VM.

Saved data

Each save is encrypted with its own key before it leaves the machine, and those keys are wrapped by one that never enters a VM. A save counts only once every part is stored and verified.

Logins and keys

Claude and ChatGPT logins are encrypted and renewed outside the VM. Agents get short-lived credentials, or the key for API-key accounts, in temporary storage that is never saved, and only in Sandboxes you’ve granted that account. Withdrawing a grant stops new deliveries but doesn’t take back copies or end running work.

Organization keys are stored as hashes and checked on every request, so a revoked key fails on the next one. No organization can read or change another’s Sandboxes.

Where data lives

On Hetzner in Germany and Finland. A Sandbox may run in another permitted location, but its saved data stays where it was stored.

Your part

Files your agents write, credentials included, are saved like any others, and a deleted file stays in earlier saves. Keep work that shouldn’t share credentials in separate Sandboxes.

Certifications

None yet. Ortam doesn’t hold SOC 2 or ISO 27001.

Report a vulnerability

Email security@ortam.dev; we reply within [response time]. We won’t pursue good-faith research that leaves other customers’ data alone, doesn’t disrupt the service, and gives us time to fix the problem before you publish.