Security — built for agents you cannot fully trust.
The useful security question about an agent fleet is not “is the model safe” — it is: what is reachable from where the agent runs, and who can prove what happened afterwards. Saphan Studio is built around that question.
The posture
The threat model, honestly
Agent fleets differ from CI in three ways: the instructions are not known in advance, the agent is persuadable by any text it reads, and it is helpfully persistent about routing around obstacles. So an agent must be treated as untrusted even when it is not malicious — no vendor can promise you an unpersuadable model, because prompt injection is a property of how these systems work, not a bug awaiting a patch.
Identity without a join token
A machine joins the fleet by an explicit owner act — there is no registration endpoint and no join token to leak. Keys are minted on the machine and never leave it. The control plane connects outward only: a runner holds no credential to it and opens no inbound port — the services you host live on your own infrastructure, where your operations team already watches.
Confined, or refused
Every run is confined at the operating-system level, with writes denied by default — and the record names what actually enforced the confinement, not what was requested, so the claim is one your own team can reproduce. A machine that cannot prove it can confine a run does not get the run: refusal, never quiet degradation.
Egress: a named policy, or the backend’s baseline — never an open network by default closed by default
A run reaches the network only through its own door, and the door admits a connection only when that policy allows the host on that port — “this host, any port” cannot even be written, because a machine you trust on one port is not a machine you trust on every port. Inside a policy, deny-all is the floor: there is no “log and allow” mode and no default-permit tier, and a machine that cannot enforce the network cut refuses the run rather than starting it open.
A run that declares no policy is not an open run. It gets its backend’s shipped baseline — the hosts its agent needs to reach its own model, plus the package registries for its permission class — and every other destination is refused. Opening the network is one explicit act with a reason, recorded with who did it. Three kinds of run carry no baseline, and their records say so: a run opened that way, a run of a deterministic tool that has no model connection, and a container run whose class already grants no network. Deriving a run’s policy from its machine or seat is not shipped; it is not presented as delivered.
The egress control cannot read request contents
The egress door terminates no TLS and parses no HTTP. It has no interception certificate or private key and therefore cannot place request bodies or URL paths in any record — the data never exists in a form that could be logged. Controlling the connection and controlling the content of a request are different capabilities; Saphan does the first.
What the record holds. On the run’s row: the digest of the policy that governed it. Per connection, for runs on the control plane’s own machine: the host and port asked for, the verdict, the reason class, the time and the identity of the policy that decided. For runs dispatched over SSH the per-connection record does not yet travel home; the digest does.
Secret values stay out of the record and dispatch envelope
Configuration, dispatch, audit and cost types carry secret names and references, never values, so ordinary logging cannot disclose them. Remote execution disables environment forwarding. The credential-owning process may use a secret where authentication requires it; the value is not copied into the operational record, evidence, cost data or remote execution envelope.
Git stays yours
Git remains the system of record for your code, and the engine never writes to it. It observes commits, branches, and merges through a read-only boundary — enforced identically in production and under test. Merging is, and stays, a human act in your own tooling.
Documented limits
A security document that lists no limits is marketing. Ours carries a limits section — what the system does not protect against, stated plainly, kept current as the system moves.
We share it in due diligence, and we would rather you read it before you buy than discover it after.
More of Saphan Studio
Controls — what is in place, control by control →Governance — decisions on the record →Enterprise — the auditor’s view →Built on Saphan Protocol →
Design partner inquiries
Contact us — [email protected]