What this does not prove
The limits of the record and of the controls behind it, stated as limits.
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 does not establish which person made it. It establishes the name recorded and that the row verifies under the workspace key. It does not establish which holder of that key wrote it. If your control objective is attribution to an individual, the record narrows the question and does not settle it — what settles it is your own custody of that key, which is a control of yours and not of ours.
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 the signatures are, and what the record guarantees keeps the three 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
Authority can expire but cannot be revoked. There is no revocation list and no revocation checking for delegations. A delegation stops applying when its window closes, or when the holding actor is retired — which does take effect immediately, regardless of any grant that has not expired. The practical instruction that follows is short: keep delegation windows short, because expiry is the revocation mechanism.
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. Signing authority is single-key throughout. There is no quorum and no multi-party requirement for any act, including ratifying the standing instructions agents work under. 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.
Machines cannot be quarantined. There is no per-machine disable or drain state. The nearest available effect is a capability record going stale, which removes that machine from eligibility for the affected work — an effect rather than a switch.
Two dispatches against the same piece of work are not durably prevented. Mutual exclusion today is per machine slot, up to that slot's declared session count. A durable per-stream assignment record is designed and in progress rather than shipped.
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. Enforcement of instruction signatures is a setting that 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 a runner-side admission check that could refuse a dispatch even from a compromised plane is designed and not shipped.
Outbound network access is not restricted by default, and this is the limit most likely to matter to you. The confinement boundary governs writes. It does not restrict what an agent reads beyond one named credential denial, and for a run that does not ask to be governed it does not restrict where the run connects. Such a run can read what is present on that machine and reach the network freely.
A per-run egress control does exist, and its honest description is available rather than on. A run is governed only if that dispatch asks for it; there is no fleet-wide setting that turns it on, and switching the default is a decision that has not been taken. Available and on by default are different words, and an auditor should establish which one applies to the runs in scope by looking at the runs rather than at this page.
Two further facts belong with it, because they are what an auditor will ask next:
- A governed run does not currently leave a per-destination trail. The policy that governed a run is identified on the run's own row, so you can establish which list governed this run. Per-connection decisions are not recorded today. That is a stated limit of this release rather than of the design, and until it closes, which destinations were admitted or refused for this run is not an answerable question.
- 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.
⇒ Until every dispatch in your fleet asks to be governed, treat egress control as your own responsibility at your own network boundary, 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.
One agent backend cannot be confined by the product at all. One supported backend applies its own operating-system sandbox, and nesting another inside it fails outright. Rather than disable that sandbox, the product composes it as tightly as the tool's own configuration allows and pins those settings per run. Runs on that backend rely on the vendor's boundary rather than on this one — and on some kernels that boundary's behaviour is undocumented by its own vendor, which is one reason confinement capability is measured per machine rather than assumed.
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.