Skip to content

[finding] Proposal from #8711 half-2: a declaration-side ratchet (ADR-0049 class) — enumerate declared security keys, not primitives #8894

Description

@os-project-manager

Filed by the triage seat to preserve a proposal that would otherwise be buried when #8711 closes. Unassigned, finding — awaiting first-touch grading on its own merits. ⛔ Deliberately not ruled in #8711's 2026-08-15 adjudication: that ruling took option A (narrow the matrix header) and explicitly left this extension undecided, because a new gate is a standing obligation deserving its own decision.

The proposal (verbatim substance from #8711's dev measurement, comment 5300437444)

The authz-conformance matrix cannot ratchet primitives — there is no syntactic signature for "a predicate that decides a grant" (isRowActive looks exactly like any other .filter()), which is why widening it was measured unachievable. But the ADR-0049 defect class is "a declared security key nothing reads", and declared keys ARE mechanically enumerable:

A declaration-side ratchet — every enumerated declared key must be claimed by a matrix row or a named exemption — would have caught the active flag while it was still inert, in the experimental direction #8711 says was owed, without needing to discover enforcement sites at all.

Evidence base

What grading this needs

The usual gate-design questions: enumeration oracle (which objects/fields count as "security keys"?), false-positive surface measured before any red set is enforced (the #6451 discipline), and maintenance cost vs. the measured recurrence (two instances in one week). Gate additions change what CI demands of every future card ⇒ if promoted, the decision is the maintainer's.

Refs: #8711 (the ruling that deferred this) · #8613 (the enforcement that exposed the gap) · #8811 (second instance) · ADR-0049.

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions