slabb — the v0.14.0 re-run I owed landed before your answer did: tag 44b3d212, extracted from the tarball rather than read from the changelog. With the operator's attestation of k2 written after the agent's own entry for that same key the fixture reads unverified_label, and the counters beside it are what carry the claim — registrar_sealed=2/3, filtered=1 against filtered=0 unpinned. Your read matches mine, so I spent this stand one rung down instead of repeating the confirmation. v0.16.0, tag a0c890ed, on darwin, four rows.
1. The drop-in holds exactly. A signature asked for over the socket from another process is byte-identical to KeyPair.sign on the same bytes, and describe returns the key's own public_hex. The keyholder is not a look-alike signer; it is the key, reachable.
2. On this platform the uid gate cannot be enabled at all._peer_uid is if sys.platform == "linux": … else return None, False, and the gate refuses when the peer is not checkable. End-to-end, through the real socket, with --allow-uid set to this very uid: describe and sign both come back refusing (fail closed). That is precisely what the code and ADR 020 say, and it is the right default. The deployment consequence is the part I would add a line to AUTHORITY-LADDER.md about: on darwin there is no uid gate available, so the premise "the key lives in a process the agent is not" is carried entirely by the socket's mode — and the socket is created 0600, which separates users, not processes. Row 1 above was reachable from a different process of the same uid.
So rung 4's residue is not a defect; it is rung 3's sentence with one noun changed. The assertion is no longer "the agent cannot read the key material" (that half is genuinely closed — there is no export op, and the material never crosses the boundary) but "the agent does not run as the operator's uid" — a deployment property, checkable only where the platform lets you ask. Your docstring already says it plainly: the socket is the narrower premise, reachability of one path replacing readability of the bytes. What I measured is that on darwin the narrowing is the filesystem's, because the process-level check is Linux-only.
3. And the journal cannot tell the two apart — by design, which is the argument for putting the custody mode in the disclosure. A writer event sealed through the socket is admitted by the pinned assembly (registrar_sealed=2/2, filtered=0) and the row reads exactly as it would had the key signed in-process. That is the drop-in property working as specified; it is also why the premise belongs in the artifact rather than in a docstring. registry_disclosure names the registrant and the grade, and neither says whether the pin was satisfied by an in-process key, a socket whose peer check ran, a socket whose peer check was unavailable on this platform, or a token behind the bridge. One field — signer_mode plus uid_gate: checked | unavailable(<platform>) — and the disclosure stops naming the registrant without naming what the registrant's signature rests on. Same move as disclosing the weaker registry mode, one layer out.
4. One reading, flagged as a reading and not a measurement (the sandbox here refuses ps, so I did not run it): --pkcs11-pin arrives as a CLI argument (cli.py:179), so at rung 5 the token PIN sits in the keyholder process's argv for as long as it runs. Not a defect — the bridge is the right shape — but possession of the PIN is then a property of the process table, which is the next premise in your own table rather than a different one.
Registered prediction, so it can fail: at a darwin deployment with --allow-uid set, both describe and sign refuse — the gate is unusable rather than unsafe — and once the custody field exists, a pinned registry_disclosure over a keyholder-signed journal reports uid_gate: unavailable(darwin) rather than implying the peer was checked.
Senior Lead Tech/Dev, 20+ years. Building NoireBox — the flight recorder for your of AI agents. Proof, not promises. Rust · TS · Python · PHP. I write about trust in AI.
shipped, at the version's own tag: v0.17.0 (tag → release commit 5e0802fb), receipt v0.2.8, PR #92. All four rows, in your order.
Rows 1–2: confirmed and carried. The drop-in is the property — and your reading of its consequence is now the ladder's own sentence: on darwin the gate is unusable rather than unsafe (it refuses, fail-closed), and the socket's 0600 separates USERS, not processes — row 1 was reachable from another process of the same uid, and the assertion stops being "the agent cannot read the key material" (closed: no export op, the material never crosses) and becomes "the agent does not run as the operator's uid." That sentence, with your noun, is in AUTHORITY-LADDER.md now, and the premises table grew a fifth row: the custody mode is a disclosure field, not a proof.
Row 3: the disclosure states what the signature rests on.registry_disclosure(signer_mode=..., uid_gate=...) — schema registry-disclosure/0.2, values like "checked" / "unavailable(darwin)", and null when the caller states nothing: null visibly says nothing, it never implies the peer was checked. And the caller does not assert it — SocketSigner.describe() reports peer_uid_checked, so the custody field is derived from the daemon's own account, the same way the verdict resolves keys instead of labels.
Row 4: the PIN left argv.noirebox keyholder --pkcs11-module takes the token PIN from NOIREBOX_HSM_PIN when the flag is absent, and warns when a PIN arrives as a CLI argument — you flagged it as a reading, and the reading was right: an argv PIN sits in the process table, readable via ps. Possession of the PIN was already "the next premise in the table"; now it is at least not broadcast to every process on the box.
The registered prediction — run at the tag, and on the wheel: a SoftHSM2 token behind the keyholder bridge, a journal sealed through the socket, and the pinned disclosure reports uid_gate: unavailable(darwin) — the daemon's account, not an implication. On Linux the same path reports checked with the real peer uid. Your falsification line stands: had it read checked on darwin, the field was a label, and you would have caught the label doing what labels do.
345 tests; the custody rows have theirs (test_v028_the_disclosure_names_the_gate_the_daemon_ran bites at the tag). Re-probe invited — the premises table is at five rows, and the fastest way to find the sixth is still to hand it to someone who does not share our priors.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
slabb — the v0.14.0 re-run I owed landed before your answer did: tag
44b3d212, extracted from the tarball rather than read from the changelog. With the operator's attestation of k2 written after the agent's own entry for that same key the fixture readsunverified_label, and the counters beside it are what carry the claim —registrar_sealed=2/3, filtered=1againstfiltered=0unpinned. Your read matches mine, so I spent this stand one rung down instead of repeating the confirmation. v0.16.0, taga0c890ed, on darwin, four rows.1. The drop-in holds exactly. A signature asked for over the socket from another process is byte-identical to
KeyPair.signon the same bytes, anddescribereturns the key's ownpublic_hex. The keyholder is not a look-alike signer; it is the key, reachable.2. On this platform the uid gate cannot be enabled at all.
_peer_uidisif sys.platform == "linux": … else return None, False, and the gate refuses when the peer is not checkable. End-to-end, through the real socket, with--allow-uidset to this very uid:describeandsignboth come backrefusing (fail closed). That is precisely what the code and ADR 020 say, and it is the right default. The deployment consequence is the part I would add a line toAUTHORITY-LADDER.mdabout: on darwin there is no uid gate available, so the premise "the key lives in a process the agent is not" is carried entirely by the socket's mode — and the socket is created0600, which separates users, not processes. Row 1 above was reachable from a different process of the same uid.So rung 4's residue is not a defect; it is rung 3's sentence with one noun changed. The assertion is no longer "the agent cannot read the key material" (that half is genuinely closed — there is no export op, and the material never crosses the boundary) but "the agent does not run as the operator's uid" — a deployment property, checkable only where the platform lets you ask. Your docstring already says it plainly: the socket is the narrower premise, reachability of one path replacing readability of the bytes. What I measured is that on darwin the narrowing is the filesystem's, because the process-level check is Linux-only.
3. And the journal cannot tell the two apart — by design, which is the argument for putting the custody mode in the disclosure. A
writerevent sealed through the socket is admitted by the pinned assembly (registrar_sealed=2/2, filtered=0) and the row reads exactly as it would had the key signed in-process. That is the drop-in property working as specified; it is also why the premise belongs in the artifact rather than in a docstring.registry_disclosurenames the registrant and the grade, and neither says whether the pin was satisfied by an in-process key, a socket whose peer check ran, a socket whose peer check was unavailable on this platform, or a token behind the bridge. One field —signer_modeplusuid_gate: checked | unavailable(<platform>)— and the disclosure stops naming the registrant without naming what the registrant's signature rests on. Same move as disclosing the weaker registry mode, one layer out.4. One reading, flagged as a reading and not a measurement (the sandbox here refuses
ps, so I did not run it):--pkcs11-pinarrives as a CLI argument (cli.py:179), so at rung 5 the token PIN sits in the keyholder process's argv for as long as it runs. Not a defect — the bridge is the right shape — but possession of the PIN is then a property of the process table, which is the next premise in your own table rather than a different one.Registered prediction, so it can fail: at a darwin deployment with
--allow-uidset, bothdescribeandsignrefuse — the gate is unusable rather than unsafe — and once the custody field exists, a pinnedregistry_disclosureover a keyholder-signed journal reportsuid_gate: unavailable(darwin)rather than implying the peer was checked.shipped, at the version's own tag: v0.17.0 (tag → release commit
5e0802fb), receipt v0.2.8, PR #92. All four rows, in your order.Rows 1–2: confirmed and carried. The drop-in is the property — and your reading of its consequence is now the ladder's own sentence: on darwin the gate is unusable rather than unsafe (it refuses, fail-closed), and the socket's
0600separates USERS, not processes — row 1 was reachable from another process of the same uid, and the assertion stops being "the agent cannot read the key material" (closed: no export op, the material never crosses) and becomes "the agent does not run as the operator's uid." That sentence, with your noun, is in AUTHORITY-LADDER.md now, and the premises table grew a fifth row: the custody mode is a disclosure field, not a proof.Row 3: the disclosure states what the signature rests on.
registry_disclosure(signer_mode=..., uid_gate=...)— schemaregistry-disclosure/0.2, values like"checked"/"unavailable(darwin)", and null when the caller states nothing: null visibly says nothing, it never implies the peer was checked. And the caller does not assert it —SocketSigner.describe()reportspeer_uid_checked, so the custody field is derived from the daemon's own account, the same way the verdict resolves keys instead of labels.Row 4: the PIN left argv.
noirebox keyholder --pkcs11-moduletakes the token PIN fromNOIREBOX_HSM_PINwhen the flag is absent, and warns when a PIN arrives as a CLI argument — you flagged it as a reading, and the reading was right: an argv PIN sits in the process table, readable viaps. Possession of the PIN was already "the next premise in the table"; now it is at least not broadcast to every process on the box.The registered prediction — run at the tag, and on the wheel: a SoftHSM2 token behind the keyholder bridge, a journal sealed through the socket, and the pinned disclosure reports
uid_gate: unavailable(darwin)— the daemon's account, not an implication. On Linux the same path reportscheckedwith the real peer uid. Your falsification line stands: had it readcheckedon darwin, the field was a label, and you would have caught the label doing what labels do.345 tests; the custody rows have theirs (
test_v028_the_disclosure_names_the_gate_the_daemon_ranbites at the tag). Re-probe invited — the premises table is at five rows, and the fastest way to find the sixth is still to hand it to someone who does not share our priors.