Saphan

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 nothing

A run reaches the network only through its own door, and the door admits a connection only when a named policy allows that 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. Deny-all is the floor no policy can remove; a seat’s policy can narrow its machine’s, never widen it. There is no “log and allow” mode, no default-permit tier, and no flag that starts the run anyway.

Nothing on the fleet can read your traffic

The egress door terminates no TLS and parses no HTTP. There is no interception certificate to install, no private key to protect, and nothing anywhere in the control that could read request contents — a URL path cannot appear in the audit record, structurally, because the data is never present to be leaked. What is recorded is the judgment: the host asked for, the port, the verdict, the reason, and which policy decided.

Secrets never propagate

No subsystem stores or transmits a secret value — variable names and references only, enforced in the type system so that ordinary logging cannot leak. Remote execution disables environment forwarding. Audit and cost records carry names, references, and numbers; never values.

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