tegwick
4daff5503f
Four in as findings — tenant-engine unfiltered event read (high), audit-core read path bounded by a flag not by code (medium), apps-pg with no backup at all (high, escalated on spend), and the unverified tenant boundary itself (high now, critical at production, escalated on ownership, fix_owner deliberately unset). Two out as notes — noisy neighbours and erasure-versus-audit, both real, neither changing a decision this month, both carrying an event to be re-read at. The round amended the scale twice: build mode lowers impact as well as likelihood, and non-adversarial findings get their own likelihood reading. The escalation rule gained a ratio test that distinguishes a first sweep from steady-state intake, and a batching rule. 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 | escalation_trigger | escalation_status | last_reviewed | review_by | graded_by | ruling | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RISK-F-0007 | finding | No consumer's tenant boundary is verified anywhere | open | net-kingdom | risk-nexus | risk-nexus | 2026-08-19 | 2026-08-19 | estate | build | unset | unset |
|
high | critical | I3 | L3 | false | true | embargoed | a verification exists for at least one consumer boundary | 2026-08-19 | 2026-09-18 | required | 4 | pending-operator | 2026-08-19 | 2026-09-18 | risk-nexus | RISK-RULING-2026-08-19-B |
RISK-F-0007 — nothing checks that tenants stay apart
What is true
No consumer's tenant boundary is verified anywhere in the estate. This is Broken Object Level Authorization, first on the OWASP API Security Top 10 since that list launched.
It is currently open question 3 in NetKingdom's Tenancy Posture, which is a
draft and not a register — which is precisely why INTENT.md names it as the
thing that had nowhere to live. Filing it here does not amend that standard,
does not ratify it, and does not settle the question it poses. A finding may
say a standard is wrong; it cannot change one.
Why it is a finding and not a research note
The floor asks whether an owner could act and whether recording it changes a
decision. Both are yes, and the second is now demonstrable rather than
asserted: every time a repo has looked at its own boundary this month, it has
found a defect. RISK-F-0004 (tenant-engine, unfiltered event read) and
RISK-F-0005 (audit-core, no tenant filter on read) are two instances found
by two repos in one round.
An absent verification is not the same as an absent boundary. But the sample so far is two for two, and the register does not get to assume the unexamined cases are better than the examined ones.
What is not established
- Whether any consumer boundary is in fact correct. Nobody has checked; that is the finding.
- Who owns the fix.
fix_ownerisunsetdeliberately — see the escalation.
Register ruling — 2026-08-19
high today (I3 × L3), critical at production, embargoed, escalated on
trigger 4 (ownership).
Today's impact is I3 and not I4 because there is no real tenant data behind
the unverified boundary yet; the consequence of one occurrence is bounded by
what the estate is currently holding. L3: no additional step is needed by
anything already inside, and the two confirmed instances say the reach is real
rather than theoretical.
production_rescore: true, and this is the finding that matters most on that
day: at production the same defect is I4 × L3 — critical — and the
re-score is not optional.
Escalation, trigger 4. This is the ownership case the trigger was written for, in its purest form: the defect is estate-wide, no repo owns "every consumer's boundary", and a routing exchange cannot settle it because there is nobody to route it to. Only the operator can say who verifies tenant boundaries — a repo, a test suite, a review obligation on each consumer — or that the estate deliberately carries it unverified until production.
Until that is answered, fix_owner stays unset rather than being assigned to
a repo that has not accepted it. An unowned finding with an honest unset is
better than a routed one nobody agreed to.
Reviews
- 2026-08-19 — filed and graded. Open at review: has an owner been named; have any further instances been found; is the Tenancy Posture question still open.