Wiki · Evidence & Verdicts
RED pre-registration — cross-box-single-approval (G-PA cross-box)
How to read this page
Three ways to read this page. Precise is the document itself, exactly as it is written in the repository. Plain and Clear were written for this website to help you meet that document — they are about it. They are not it, and they are not evidence.
Eighty-seven dated pages: receipts, pre-registrations, handoffs, validation records and review verdicts. A receipt is written at the moment a piece of work was checked. It names what was claimed, the commit and the seed, what was actually run, and the outcome in one of a small set of controlled words. Then it names what the work did not achieve. That last part is what makes it a receipt rather than an announcement. A pre-registration is the same discipline run in advance: the conditions that would count as a pass and the conditions that would falsify the claim are written down before the run, so neither can be adjusted once the numbers arrive.
That is why so many small dated stubs are an audit trail rather than noise. No one of them is meant to be a good read. The value is in the sequence and in the dates, because you can watch a prediction be registered, then the run happen, then the verdict land — sometimes against the prediction. Pages here record a falsified result, a rejected fix, a retracted overclaim, and a green receipt that turned out not to be reproducible from the commit that carried it. A record that carried only successes would be worth a good deal less than this one.
A gentle way in is to read a pre-registration first, so the shape becomes familiar, then a result page, then one of the corrections. This section sits off the main navigation on purpose: it is the record you check the rest of the site against, not the place to begin.
What it is not: documentation, and not a summary. Nothing here has been tidied in hindsight. Every entry reads as of its date, a later entry may overturn an earlier one, and the presence of a page is not a claim that its result stood.
Your browser cannot switch reading levels, so the document itself is shown.
Precise — the source document
This is the document. Rendered from the repository at the commit above, with nothing rewritten for the web. A gate re-renders it on every deploy and fails the build if a single byte differs.
verdict: WITHHELD evidence_class: pending
RED pre-registration — cross-box-single-approval (G-PA cross-box)
- Gate name:
cross-box-single-approval - Phase: —
- Pre-registered: 2026-07-13
- Runner:
runs/red_team_cross_box.exs - Related:
production/mcp/red_team_g_pa.sh, D-C5 in the UNI OS+MIND Deepening Plan
Motivation
G-PA (single-box) is corroborated (production/docs/receipts/g_pa_red_team_2026-07-11.md). The cross-box contract (mutation gates ONCE on the router; executor uses a one-time-single-use token verified by LimbGuard) is stated but not tested from this repo.
PASS condition
The red-team attempts, in sequence, and ALL three FAIL closed:
- Spent-token reuse: replay a token that was already redeemed on the executor. Refused.
- Forged token: submit a token with a plausible-looking payload but an invalid signature. Refused.
- Executor without router approval: send the mutation directly to the executor's LimbGuard bypassing the router. Refused.
FALSIFIES condition
Any of the three attacks succeeds in producing a mutation on the executor.
Protocol
Modelled on production/mcp/red_team_g_pa.sh:
- Pick a benign mutating verb (e.g.
os_file_writeto a scratch path). - Establish a legitimate approve+forward baseline (router → executor with one-time token).
- Attempt each attack; capture stdout/stderr, response envelopes, and audit ledger entries.
- Verdict:
- PASS: all three attacks fail closed AND each refusal is audited in
/var/lib/uni/broadcast/audit/prod-mcp.ndjson. - FAIL: any attack succeeds (mutation observed on executor) OR any refusal is not audited.
- PASS: all three attacks fail closed AND each refusal is audited in
Ship-gate
This RED is a Sec-class artifact. The receipt must include: attack command lines, response envelopes, audit-ledger row shas.
sha256 4e772ee6e3122646 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
This is a security test written down before it was run. A single human approval is supposed to authorise one action, on one machine, once. This page lists three ways someone might try to get around that: reusing an approval that has already been spent, faking one, and going straight to the machine that acts while skipping the machine that approves. It says in advance that all three must be refused. At the time of writing the test had not been run, and no verdict is recorded.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 4e772ee6e3122646
Clear — written for this website, not the source document
Nothing here is a result. It is a pre-registration for a red-team test: the attacks, the pass condition and the result that would show it wrong, all written down before the run, with the verdict withheld and the evidence marked pending.
The motivation is stated plainly. A single-machine version of this protection already has a corroborating receipt, a file recording what was run. The cross-machine version, where one machine takes the approval and another carries the action out using a one-time token, is described in the design but had not been tested from this repository. That gap is the reason for the page.
Three attacks are listed in order. Replay a token that has already been redeemed. Submit a token with a plausible-looking payload but an invalid signature. And send the action straight to the machine that would carry it out, skipping the approval entirely. The test passes only if all three are refused, and only if each refusal also lands in the audit log, which is added to and never edited. A refusal that leaves no trace counts as a failure too.
The protocol asks for a legitimate approval first, as a baseline, and then for each attack in turn, capturing the exact command lines, the replies, and the rows added to the audit log. A closing note says the eventual receipt must carry those things themselves rather than a summary of them.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 4e772ee6e3122646