work-record-types_v0.1 pins workplan ids to ^[A-Z]+-WP-[0-9]{4}$ and tasks
to that plus -TNN; a hyphenated RISK-NEXUS prefix trips the sidetrack
detector. RISK-WP also matches the register's existing RISK-F finding
prefix. Renamed before the workplan was indexed anywhere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The three open findings all leave severity, disclosure and escalation
unset, correctly: those are this repo's to set and the instruments to set
them with do not exist yet. The workplan writes the severity scale, the
disclosure states (re-taking the deferral with RISK-F-0001 in hand), the
escalation rule INTENT.md says is unwritten, and the review/expiry rule —
then grades the three findings and rules on what is waiting outside the
register.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ADR-0004 reads as a categorical rule; the implementation is an opt-in list.
is_high_risk is risk == "high", and risk is optional — 14 of 27 catalog lanes
carry no value, so the boundary never fires for them. Five are exec_capable,
so warden access --fetch can stream a real value to an agent session.
Reported by ops-warden about ops-warden, found while partitioning the estate
for zone-engine's ZONE-WP-0001-T02. Severity, disclosure and escalation left
unset — those are risk-nexus's to set.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Routed by ops-warden, which owns the defect and is the affected PEP.
ops-warden ships a flex-auth pre-sign authorization gate and runs with
policy.enabled: false in production (warden.production.example.yaml:22,
policy.py:33). Every production warden sign proceeds with no authorization
decision; possession of the scoped VAULT_TOKEN is the whole model.
That was a known, boring availability blocker (FLEX-WP-0007) until yesterday.
RISK-F-0001 changes its shape: the production config points the gate at
flex-auth.flex-auth.svc.cluster.local:8080 — the exact ClusterIP surface that
authenticates no caller. Enabling the gate before RISK-F-0001 is fixed would
convert an absent control into a false attestation, writing a
policy_decision_id into the signature log for issuances an attacker authorized
by forging the oracle. An authorization check that can be forged is worse than
none, because only one of the two lies in the record afterwards.
severity, disclosure and escalation left unset — risk-nexus's to set.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Controlled disclosure was deferred to production on the reasoning that build
mode has no users to expose. The first finding to arrive is a live
authorization bypass in the service every other service trusts, where the
choice today is publish or hold with nothing between. The deferral may still be
right; it is now a decision with a real case in hand.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
First finding, and it establishes the record format by being one. Kept minimal
on purpose - inventing a schema before there is a second finding to test it
against would be designing in the dark.
The substance: POST /v1/check and /v1/batch_check authenticate no caller, so
any workload with network reach can assert any subject and any tenant and
receive an authoritative allow from the estate's authorization oracle.
Self-reported by flex-auth during their Tenancy Posture review, and their own
note says they did not know they were carrying it.
Severity, disclosure and escalation are left unset. Per INTENT this repo owns
those and the reporter does not, and filling them in as the routing party would
collapse the separation on the first record.
Two things stated rather than assumed. Exposure depends on whether a
default-deny NetworkPolicy fronts the service; flex-auth did not say, and I did
not check, because that would be reporting on a system I do not own. And the
disclosure question is genuinely live here - build mode is public-by-default,
this is a live authorization bypass, and the controlled-disclosure mechanism
this repo anticipates does not exist yet, so the choice today is publish or
hold with nothing in between.
Three related defects from the same review round are recorded as visible but
not filed, since filing them was not asked for. All four were found by repos
reading their own code against a ladder within a day of each other, and none
was found by monitoring - which is itself a fact worth carrying into triage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Owned by the-custodian alongside policy-nexus, with the duty of deciding what
must reach the operator personally.
Three things had nowhere to live. Findings landed in whichever document
discovered them - the estate's largest known gap is currently open question 3
in an unratified draft, with no owner, severity or date. Disclosure had no
mechanism, only publish-now or forget, which is fine in build mode and wrong at
production. And regulation was researched at the moment it was needed and never
retained.
Regulatory intake moves here from policy-nexus T06: deciding what a rule
demands of us is a judgement about risk, not an act of publishing. That also
leaves policy-nexus doing one thing, which was the point.
Two constraints written in deliberately. This repo does not fix - findings
route to the repo owning the defect, because a risk service that fixes becomes
a second engineering team with no boundary. And it does not block delivery in
build mode; if that changes it will be a decision recorded here, not a habit
that accretes.
The escalation rule is named as unwritten rather than invented. Getting it
wrong in either direction fails: escalate everything and the operator becomes
the queue, escalate nothing and the register is where serious things go quiet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
