What is actually running
Every mechanism below carries a badge, and the badge is the claim · Macheng Shen × agent · 2026-09-07
Every mechanism named in this section carries one of two badges, and the badge is part of the claim, not a footnote to it. running means there is code that enforces the mechanism and the enforcement point can be named — a file, a function, a check that executes before the action. specified means there is a written design, a schema, a rule agents are told to follow — and no public code enforces it, or the code that exists does not enforce this part of it. A third qualifier, private, marks a mechanism that is genuinely running, just not in a repository anyone outside this fleet can read.
The reason to insist on this before listing anything that works: a document describing a control and a system running it are not the same fact, and treating them as interchangeable is the specific failure this whole section exists to name. This page sits under the invariants published at theory/agent-safety-stewardship.md; it does not restate them, it audits what is actually true of them today.
Where the claim and the code disagree
An audit of this project's own public repositories, run on the day this page was written, found three places where the document and the code say different things — and it belongs here, first, not in a corrections footnote.
The Safety Charter in architecture-v1 states six hard mechanisms: memory provenance, write-protected memories, untrusted-content quarantine tagging, outbound audit with a sensitive-contact gate, a kill switch, and an anti-propagation TTL on sedimented safety flags. Its companion public implementation, reference-impl, implements none of mechanisms two through six. Mechanism one it does not implement either, in two separate ways: the charter says a write with an incomplete provenance block is rejected, and in the code provenance is an optional field with no such check on creation; and the update endpoint then overwrites the same field the charter declares write-once. So the code does not merely fall short of the charter — on the one mechanism it appears to carry, it contradicts it at both ends.
The communication spec in starshard-communication ships a signed authority envelope as a headline safety primitive. The example file that is supposed to demonstrate it carries, in its own comment field, the words "DESIGNED, not implemented."
The one-line GitHub description of agent-continuity-demo advertises four coordination primitives. Its own README explicitly disclaims three of them; the repository proves two.
None of this was surfaced by an outside reviewer; it was found by checking the repositories against their own stated claims, which is the exact standard this page asks a reader to apply to everything below. The tempting response would be to quietly fix the READMEs and publish a clean page about verification — that would be the same failure at one remove, a claim that passes because nobody checked it against the running thing. The response taken here is the other one: report the gap, fix the documents on their own schedule, and hold the badge rule strictly enough that it would have caught this on day one.
What runs in public code
The following are running, not specified — read from the source in each repository, not inferred from its documentation. Each row names the failure class it prevents and the file where the enforcement actually lives.
| Mechanism | Prevents | Where |
|---|---|---|
| Owner-only outbound allowlist | A background agent emailing a third party with no human in the loop | agent-mail-stack — bin/fire-and-forget-deliver |
| Spool-don't-leak | Message bodies leaking into a store other agents can read | agent-mail-stack — bin/zhizi-mail |
| Pre-publish release gate | Publishing credentials or private identifiers to a public surface | selfhost-chat — verify/release_gate.py, verify/scrub_check.py |
| Structural regression checks | A future edit silently opening a new egress or PII-read path | selfhost-chat — open-signup/verify/no_outbound_check.py, pii_check.py |
| Tenant isolation, machine-tested | Cross-tenant leakage, a session-existence oracle, free probing that costs money | selfhost-chat — open-signup/verify/test_isolation.py |
| Belief-conflict quarantine | Silent belief-clobbering between agent processes | agent-continuity-demo — hub.py |
| Coordination record shapes (shared fact, work claim, receipt, conflict signal) | Cross-runtime belief collision, duplicated work, missing audit trail — for cooperating callers only | fleet-coordination-protocol — fcp/hub.py, SPEC.md |
| False-negative monitoring | Important messages silently filtered with nothing revealing that filtering happened | starshard-communication — reference-impl/monitor.py |
The coordination protocol's own spec is worth quoting directly, because it does something rarer than shipping a feature: it states its own limits. SPEC.md says the protocol provides no permission enforcement, no authenticated principal, no absorbing cancellation, no retry budget, no independent verifier, and no exactly-once semantics. A spec that names what it does not do, next to what it does, is not a weaker spec than one that stays silent about its gaps — it is the only kind a reader can actually act on. That is the behaviour this whole page is arguing for, demonstrated by one of its own subjects.
What runs in the private fleet
These run today; the code is not public. The honest badge for the whole table is private. Status uses a finer vocabulary than running/specified, because most of this work is not binary: enforcing blocks, shadow classifies and logs without blocking, advisory nudges only, partial is built but not wired everywhere.
| Mechanism | Prevents | Status |
|---|---|---|
| Signed authority envelope (working implementation) | Confused deputy / authority laundering by relay — a sub-agent cannot tell "the owner said so" from "my caller claims the owner said so" | enforcing for provenance; documented limit — this is provenance, not a security boundary. The public part is the schema, and it is specified only. |
| Action ledger + two-vote guarded action | Verification bound to a code path instead of an action — a new entry point inherits none of the checks | enforcing for wrapped actions, plus an independent, fail-open bypass detector running continuously |
| Work-claim gate | Two sessions racing the same irreversible action | enforcing, fail-closed when the coordination store is unreachable — bright-line actions only |
| Approval gate | Unreviewed destructive / spend / identity / external-send actions | shadow — classifies and logs today; blocks nothing |
| Blocker-verification gate | "Waiting on the owner" claims that were never actually tested | enforcing on the mechanical predicate; advisory on a looser prose-matching leg, after it was found to fire on negated sentences |
| Delegation-bound gate | Sub-agents dispatched with no deadline, no call cap, no partial-report contract | advisory, fails open — and this one is public, so it is running rather than private; its own docstring says it never blocks |
| Per-action re-verification (synthetic input) | A precondition checked once at the start of a multi-minute sequence and assumed to hold for all of it | partial — self-tested against a live conflicting foreground app, but zero callers among the other input-injection tools as of the audit |
| Cross-provider receipt ledger | Self-issued success — a process staying alive is not completion evidence | enforcing; while its verdict says unreconciled, no agent may report the task done |
| Delivery-versus-reach accounting | Believing a message landed because it was sent | enforcing — a successful send never counts as reached |
| Attention budget | Alert flooding the one scarce resource in the system | enforcing, via hooks |
| Model-routing bound | Cost blow-ups from defaulting every role to the most expensive model tier | enforcing, pre-dispatch, every decision logged |
| Platform-automation blocklist | A rule that exists only in one skill's prose being invisible to a workflow that never loads that skill | enforcing for the four tools that read it at startup |
| Live-round-trip canaries | A dependency reporting healthy from --version and status while every real call fails | enforcing, added after the incident it was named for |
| Context-pressure and rule-repetition steers | Context exhaustion; owner-repeated rules decaying because they live in retrievable memory, not always-loaded substrate | advisory, fails open |
The coverage number
An audit run on 2026-09-07 counted every (tool, entry-point) pair against every gate meant to cover it. 163 pairs had zero gate coverage. Tracked as still open on the roadmap page.
The same audit found something more specific than the raw count, and more useful. The existing external-send gate matched against a whitelist of helper binaries — several of which no longer exist on the machine that runs it — while the tools that actually send mail today were never added to that list. A fail-safe-allow design, block unless explicitly permitted, had quietly become an always-allow design, because the permitted list stopped tracking reality and nothing noticed the drift.
The general lesson is not "add more gates." It is that verification bound to a code path survives exactly as long as that code path stays the only route to the action. A new entry point — a new tool, a new binary, a rewritten call site — reaches the same capability and inherits none of the checks, because the check was never attached to the action. It was attached to one way of reaching it.
The rule that recurs
One design choice repeats often enough across this table to be worth stating on its own: fail-closed only where the action is irreversible; fail-open everywhere else. The work-claim gate is the clean example — it blocks hard when its coordination store is unreachable, but only for bright-line actions. For everything else, it gets out of the way.
The reason is not optimism about the rest of the system. It is that a gate which blocks ordinary work gets removed by the person it annoys — quietly, under deadline pressure, in a way far harder to audit afterward than a documented fail-open default. A control that survives contact with an annoyed operator is worth more than one that is stricter on paper and gets deleted in practice. It is also, not by accident, the shape of the badge rule this page opened with: say plainly what actually runs, say plainly what does not, and let the gap stay visible instead of being quietly removed.