Files
stack/docs
mos-dt-0andClaude Opus 5 b66d1858e1 docs(remediation): bank the credential resolution — four seats were misclassified, not one
Mos ruled (a): re-mint with read:user, fleet-wide pattern change. The finding was bigger than I framed
it. The same misreading had classified all FOUR seats in the credential reconciliation as REJECTED, and
all four tokens were valid — the server itemises the token's scopes in the 403 body, which is itself
proof the request authenticated, and repos/search returned 200 under all four. A genuinely dead token
returns 401, control-proved. Retractions delivered; all four resumed authoring.

What made this rulable before an incident rather than after one: the near-escalation on f10-coder was
caught and BANKED rather than shrugged off, and coder-mos1's 401/403 control completed it. A finding
recorded from a near-miss is what turned four wrongly-held seats into a same-day fix.

Standard seat token pattern becomes write:issue, write:repository, read:user. read:user is read-only
and about the actor itself — the marginal privilege is exactly the identity the read-back doctrine
already requires every authoring seat to verify, and least-privilege that blinds identity
self-verification fights the mission's own controls.

(a) and (b) answer different questions and both stay: read:user proves who you are, authored-artifact
read-back proves the write landed under that identity, which read:user alone cannot. Read-back remains
mandatory on authoring operations.

D-45 discipline preserved and recorded: the seat was told not to widen its own scope to make its check
pass, and the widening was the coordinator's decision made at the coordinator level. An audited party
must never relax its own audit — the fix is that someone else relaxes it, deliberately, on the record.

Adopted into doctrine on main: /user is a bad capability probe for least-privilege token classes, the
capability differential on an in-scope operation enters the seat-provisioning checklist, and verdict
classification happens on the error body, never the status code alone.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-05 11:58:50 -05:00
..