What this does not prove

This is the page the rest of the section should be judged against. A control you believe in and do not have is worse than one you know you lack, so everything below is stated as a limit rather than softened into a roadmap.

Read it before you write up a finding in either direction. Several of these limits are narrower than they first sound, and two of them are wider.

Limits of the record itself

A gate decision establishes which person made it only above the person epoch. Until the owner declares the epoch, and for every row at or below its boundary, a gate row is signed by the workspace key: it establishes the name recorded and that the row verifies, and does not establish which holder of that key wrote it. If your control objective is attribution to an individual, establish first which side of the epoch the row is on (saphan gates prints it). Above it, an owner-class decision is signed by the person's own key and the assertion is kept. Below it, what settles attribution is your own custody of the workspace key, which is a control of yours and not of ours. If a control of yours depends on the sentence every decision was signed by the person who made it, it is not true of rows from before the epoch, and it is true of later ones only for owner-class gates.

A coordination document is checked as of a checkpoint, not for ever. The work order, the status report, the review order, the verdict and the review notes are each signed by their author — the person for the order, the executing seat for the status, the reviewer's seat for the verdict — and a third party with your root public key can check them offline. The answer is "verified as of checkpoint X": a revocation recorded after X is not covered, and a newer checkpoint covers it. The bundle's own list of documents and its change id are not signed, so the check does not show that no required document was left out. The collected limits are on the limits of the signed record.

The refusal ledger is not a complete log of every refusal. It holds refusals of work the product started to carry out. A refusal raised before a run exists — a policy document that is absent or unreadable at the moment of dispatch, for example — ends on the operator's terminal and writes no row at all. If a control of yours depends on the sentence every refusal is evidence, narrow it to every refusal of a started run is evidence, which is true.

Run records are not signed. They pin content and identity. That is provenance, and it is a weaker claim than a signature — an auditor should not cite a run record for anything a signature has to carry. The governance log and gate rows are where to look for that, and what the record guarantees keeps the four kinds apart for exactly this reason.

Content integrity has no freshness. A matching digest establishes that bytes match a value, not that they are the current bytes. A genuine older artefact with a genuine matching digest passes. Rollback and indefinite-freeze conditions are not currently detected, and build information that would reveal an artefact built from a modified source tree is not currently read.

One integrity check is a receipt rather than a check. On one of the two paths by which content is transferred, the receiving machine computes a digest and it is recorded, but not compared against a locally computed one. On that path the record tells you what landed — not that what landed is what was sent. The path that carries agent binaries does compare, and re-verifies identity after installation.

Retention is not a control this section provides. The record lives in a store you operate, under your retention and backup policy. If your management system requires a stated retention period for change evidence, that period is yours to set and to evidence.

Limits of authority and of revocation

A key can be revoked; a verdict covers revocations only up to its checkpoint. A person's, a seat's or a delegated key can be withdrawn (saphan identity revoke), and a signature is judged against revocations as of the moment it was made. What the offline check says is "as of checkpoint X": a revocation after X is not covered by it, and a newer checkpoint covers it. A delegation also stops applying when its window closes or when the holding actor is retired — which takes effect immediately — and nothing caps how far away a delegation's expiry may be, so keep delegation windows short.

There is no root rotation. It is refused by design. Losing the root material means you can never sign a new delegation or admit a new machine under the existing chain, and re-founding the fleet's trust is the only recovery.

There is no signature threshold. Each act is signed by a single key. There is no quorum and no multi-party requirement for any act, including ratifying the standing instructions agents work under. Machine certificates are carried in a verification bundle and are not judged by the offline check. If your control framework requires dual control over the authority that governs a process, this product does not provide it and you will need it elsewhere.

A machine can be retired, not paused. saphan machine retire takes a machine out of the fleet as an owner act, and a retired machine can only come back as a new admission. There is no temporary disable or drain state between in service and retired.

Two dispatches against the same piece of work are refused, with one recorded override. A stream is claimed for one actor in the record (saphan claim), and a run is refused while another actor holds the claim or while a live run is recorded on the stream; a seat runs one session at a time. ⚠ An owner can override the per-stream, per-role lock for one run (saphan run --force-dyad); the refusal it overrode is written onto that run's record.

Limits of enforcement

A compromised control plane is currently unopposed. Every enforcement decision is made by the control plane, and nothing on a runner independently inspects a dispatch and can refuse it. The instruction chain is verified — on the control plane. Two consequences follow, and both are things to check on a live deployment rather than to read here. Every order still needs a person's passkey approval to be placed, but enforcement of the instruction signature chain back to your root (trust.enforce) defaults to off and must be switched on deliberately; while it is off, an unsigned instruction is admitted and the fact is recorded, so the volume of unsigned traffic is knowable before you tighten it. And there is no runner-side admission check that could refuse a dispatch even from a compromised plane.

Outbound network access is closed by default, but a run can be opened. Every run is judged by an egress policy unless it was dispatched with --egress-open "<reason>", which is recorded on the run with its reason and actor. An auditor should establish which runs in scope were opened by reading their policy source (open:<reason>, <actor>) from the run records in the installation's database — no command displays it in this release — not by reading this page. Opening is recorded, not restricted to a role.

Two further facts belong with it, because they are what an auditor will ask next:

• The per-destination trail is incomplete. The policy that governed a run is identified on the run's own row, so which list governed this run is always answerable. Per-connection decisions are written for runs on the dispatching machine, but this release has no command or page to read them back, and runs on a machine reached over ssh do not record them at all. See the audit record.
• Confinement of the filesystem does not prevent data leaving. This is a property of the whole category rather than of this product: agent vendors document the same limitation about their own tools, and a session with networking substantially disabled can still reach the endpoint it exists to talk to.

⇒ Egress control is one layer and a run can be opened: keep egress control at your own network boundary as well, and keep nothing on a machine beyond that machine's own scope. That is the first item on the hardening list in checks you can run yourself, and it is there because it is the highest-value control available to you.

Confinement can be switched off. An installation-level setting hands confinement to the agent backend instead. When it is set, the run record states in as many words that no claim is made that the agent was confined. That is honest, and it is one line of configuration — so an auditor should read the setting on the deployment in scope rather than assume it.

Some backends are not confined by the product on some platforms. Where an agent tool brings its own operating-system sandbox and the two do not nest, the product does not confine it, and the run record says that no engine boundary is claimed — on macOS that is the case for three of the supported agent backends. Runs there rely on the vendor's boundary rather than on this one. Which backend is confined where is one table: the sandbox matrix.

Remote confinement is real, and narrower than local. On remote machines, operations on file metadata sit outside the boundary at every level. The enforcement wording on the record is composed from the machine's signed capability entry and the policy in force, and while the operating system's own confirmation is captured in the run's output, no command currently asserts it — so on that lane the record's enforcement claim is composed rather than confirmed. A remote machine that was never measured, or that measures below the enforcement floor, refuses the work rather than running it unconfined.

One residual risk inside confinement is accepted, deliberately and on the record. A confined run can write to the shared version-control object store, because neither sandbox policy language can express append only. A careless run could corrupt a shared object. The alternative — a full repository copy per run — was rejected, and the decision is recorded with its date, the rejected alternative, and an explicit trigger to revisit it if an untrusted executor is ever admitted. For an auditor this is worth noting as what it is: a documented risk acceptance with a named review trigger, which is the artefact a management system asks for.

A deployment fact that puts credentials in somebody else's log

If the management surface is served behind your own reverse proxy terminating TLS, the one-time links that invite a colleague or reset a password are secrets that appear in a request path — and a fronting server records full request paths in its access log by default. Inside the product those links are handled as secrets, but none of that reaches the log of a server in front of it. The link then sits in a file with a different retention policy from the product's own, possibly on a different machine.

This is outside the product's control and it is not a defect it can fix. It is a deployment fact to know before choosing that mode. What to do about it, in order: strip or redact the query string for that path in the fronting server's own access-log format; failing that, treat that access log as holding credentials and give it the retention and the permissions of one. Where the surface terminates TLS itself, there is no fronting server and this does not apply.

Not in the threat model

Four things, stated plainly so that nobody reads a control where none was built.

• An operator already root on a runner.
• An actively hostile executor, as distinct from a careless one.
• Physical access to a machine.
• Prompt injection itself. Nothing here prevents an agent from being persuaded. What the controls do is bound what a persuaded agent can reach, and guarantee that what it did is recorded. If your risk assessment needs an agent that cannot be talked into anything, that is not what this is.

And the boundary this section opened with

The product is not certified and cannot make you compliant. What it produces is the evidence your own management system requires, as a by-product of how the work happens. Conformity remains your auditor's verdict, and every claim above is written so that the verdict can be reached on evidence rather than on our description of it.