---
id: RISK-F-0007
type: finding
title: "No consumer's tenant boundary is verified anywhere"
status: open
reported_by: net-kingdom
reported_via: risk-nexus
routed_by: risk-nexus
date_reported: "2026-08-19"
date_filed: "2026-08-19"
system: estate
environment: build
fix_owner: unset
fix_tracking: unset
related: [RISK-F-0004, RISK-F-0005]
# Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-second-grading.md
severity: high
severity_at_production: critical
impact: I3
likelihood: L3
fidelity_modifier: false
production_rescore: true
disclosure: embargoed
embargo_condition: "a verification exists for at least one consumer boundary"
embargo_since: "2026-08-19"
embargo_review: "2026-09-18"
escalation: required
escalation_trigger: 4
escalation_status: pending-operator
last_reviewed: "2026-08-19"
review_by: "2026-09-18"
graded_by: risk-nexus
ruling: 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_owner` is `unset` deliberately — 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.