Security
Security
Saphan Studio — security model, mechanisms, sandboxing, and documented limits
The orientation below and the page list are this site's navigation.
For a security officer or a reviewer deciding whether this product's boundary is one they can sign off on.
After reading it you can say what confines a run, what the record proves about it, which mechanism is enforced on which platform, and what the product declines to protect against.
Before you start: nothing installed. If you are deciding quickly whether this is worth your time, read what it does not protect against first — what a security document declines to claim tells you more than what it claims.
Read in this order. The sidebar order is the reading order, and it ends with the limits.
The pages of this section
- Who this document is for — Two readers.
- In one paragraph — Saphan Studio is a control plane that dispatches AI coding agents to a fleet of machines you own.
- What the risk actually is — If you have run continuous integration, you know most of the shape: a control plane sends work to machines, and those machines run code.
- Design principles — Product invariants.
- Identity and PKI — The accepted algorithm set is closed, and the algorithm name is part of the signed material — so a signature produced under one algorithm cannot be reinterpreted under another.
- Machines: enrollment and authentication — A machine cannot enrol itself, and there is no registration token that would let anything holding it become a runner.
- Capability: what a machine is trusted to be able to do — Fleet configuration accumulates claims — "this machine has the toolchain", "this machine can run that backend".
- Seats: separating agents that share a machine — A seat is a named executor identity assigned to one machine and one execution slot, for one agent backend, with its own configuration home.
- Runners: what happens during a run — Capacity on a machine slot is a partial unique index over the machine, the slot and a session ordinal, for live, unfinished runs.
- Secrets — No subsystem stores or transmits a secret value.
- The record: what you can prove afterwards — Registries of actors, delegations, machines, seats and capabilities are one Ed25519-signed append-only log.
- Advanced: the egress door inside the confinement boundary — This section is for a reviewer auditing the confinement itself.
- Administrator's runbook — Worked commands for every step are on the worked-examples page.
- Worked examples — Real commands, real defaults, and the engine's own refusal classes quoted verbatim.
- Reporting a vulnerability — Report privately to the maintainers rather than in a public issue.
- Glossary — Actor — a named identity, human or automated, in the signed registry.
- Documented limits — Everything below is a limitation of the current release.