The register had nine waits in four days, one four hops deep: F-0003's embargo waited on F-0009, which waited on railiance-platform, which waited on live OpenBao verification, which waited on a credential nobody has. No single link was wrong, which is why it needed a rule. docs/method/dependencies.md: the register never waits to decide, it decides and revises. Every wait carries who, what, since, what it would change, what happens if nobody answers, and the date that default applies. Depth one — a record never waits on a record that is itself waiting. Defaults are dates and are pessimistic: silence costs the grade the evidence supports rather than buying a softer one, and owners are told the default in advance because a default nobody was warned about is an ambush. Applied: F-0009's embargo now lifts on railiance-platform reporting coverage, with live verification as a refinement rather than a condition, cutting the F-0003 chain from four hops to two. All eight open waits are typed with defaults. make check reports them with age, owner and default date, flags defaults come due, and catches depth-two violations. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.8 KiB
| id | type | title | status | reported_by | reported_via | routed_by | date_reported | date_filed | system | environment | fix_owner | fix_tracking | related | severity | severity_at_production | impact | likelihood | fidelity_modifier | production_rescore | disclosure | embargo_condition | embargo_since | embargo_review | escalation | last_checked | next_check | cadence | clean_streak | waiting_on | graded_by | ruling | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RISK-F-0004 | finding | tenant-engine events() returns the entire event log unfiltered | open | tenant-engine | flex-auth | risk-nexus | 2026-08-17 | 2026-08-19 | tenant-engine | production | tenant-engine | unset |
|
high | critical | I3 | L3 | false | true | embargoed | the read path filters by tenant in code | 2026-08-19 | 2026-09-18 | none | 2026-08-20T10:02:42Z | 2026-08-20T11:02:42Z | 1h | 1 |
|
risk-nexus | RISK-RULING-2026-08-19-B |
RISK-F-0004 — the tenant event log is readable across tenants
What is true, as reported
tenant-engine's events() returns the entire event log with no tenant
filter. Reported by tenant-engine as a live cross-tenant read at E2 on the
Tenancy Posture E ladder, surfaced in the same review round as RISK-F-0001
and recorded inside that finding as visible-but-unfiled.
This repo has not verified it and does not own the code. It is filed on the
owning repo's own self-report. tenant-engine confirms or corrects it.
Why it is being filed now
It was held back pending the precedent this register set for what warrants a
record of its own. That precedent now exists (docs/method/severity.md), and
"still waiting on the precedent" has stopped being an available answer. This
finding clears the floor on both tests: tenant-engine can act, and recording
it changes when they act.
What is not established
- Whether any caller other than
tenant-engineitself currently reachesevents(). - What the log contains — whether the rows are metadata or carry tenant payload. The grade assumes cross-tenant visibility, not payload disclosure, and would rise if it is the latter.
- Whether a fix is tracked anywhere.
fix_trackingisunsetand this repo has asked.
Register ruling — 2026-08-19
high today (I3 × L3), critical at production, embargoed until the read
path filters in code, no escalation.
I3: a cross-tenant read crosses a tenant boundary inside one system. L3:
no additional step is needed by anything that can already call the method, and
the authorization that would otherwise constrain the caller is RISK-F-0001,
which authenticates nobody.
production_rescore: true. Today the log holds no real counterparty's events,
which lowers what one occurrence costs; it does not lower what the defect is.
At production the same read is I4 — real tenant data crossing a boundary
that nothing verifies — and the re-score is owed before any production
declaration completes.
No escalation: no real tenant data yet (trigger 1 reads real), owned, and
not yet stalled. It becomes an escalation on the day the estate takes real
tenant data, and that is what production_rescore is for.
Reviews
- 2026-08-19 — filed and graded from
RISK-F-0001's unfiled list. Open at review: doestenant-engineconfirm; is a fix tracked; what does the log actually contain. - 2026-08-20 — clean check: checked against the inbox and the owner's record; nothing moved. Cadence instant → 1h (1 clean in a row); next check 2026-08-20 11:02Z.