tegwick
36b707f0c3
T02 inbox check, wired into make check and verified against the actual 2026-08-19 failure — replayed at that moment it surfaces all three messages that were already waiting. T03 sweeps the rest of the quietly-tolerated class: bad dates, cadence off the ladder, undefined disclosure states, dangling constraint_on and related refs, embargoes without conditions, escalations without triggers. T04 requests verification of user-engine's tenant boundary — the first walk down the on-request path, chosen as a consumer not already known to fail it. T05 established by trying what this register can verify: cluster yes, OpenBao 403. T06 puts regulatory records on the findings ladder. T01 stays in progress: the procedure, make due and make checked exist, but arming something that runs them on schedule is a standing compute commitment and the operator's to make. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
58 lines
2.2 KiB
Markdown
58 lines
2.2 KiB
Markdown
---
|
|
id: RISK-V-0002
|
|
type: verification
|
|
title: "Tenant boundary of user-engine — verification requested"
|
|
date: "2026-08-20"
|
|
requested_by: risk-nexus
|
|
requested_of: user-engine
|
|
status: requested
|
|
findings: [RISK-F-0007]
|
|
workplan: RISK-WP-0004-T04
|
|
---
|
|
|
|
# RISK-V-0002 — user-engine tenant boundary (requested)
|
|
|
|
The first exercise of the on-request path the operator ruled on 2026-08-19.
|
|
`RISK-F-0007` is `accepted` until production on the strength of that path, and
|
|
a route nobody has walked is a plan rather than a route
|
|
(`RISK-WP-0004-T04`).
|
|
|
|
## The request
|
|
|
|
One named boundary: **can a caller acting for tenant A obtain, modify or infer
|
|
data belonging to tenant B through `user-engine`?**
|
|
|
|
Asked of `user-engine` because they are a consumer with a boundary and are not
|
|
already carrying a finding about one — `tenant-engine` (`RISK-F-0004`) and
|
|
`audit-core` (`RISK-F-0005`) both are, and using them would have tested the
|
|
path against systems already known to fail it.
|
|
|
|
## What was asked for, and what deliberately was not
|
|
|
|
Asked: whether anything **verifies** the boundary — a test, an assertion, an
|
|
authorization check on the path — and what would have to be true for the answer
|
|
to be yes.
|
|
|
|
Not asked: a general security review, a posture ladder self-assessment, or a
|
|
promise. `user-engine` owns the verification; this register scopes and records
|
|
it and verifies nothing itself here.
|
|
|
|
## What this exercise is really measuring
|
|
|
|
Whether the path works, and where it rubs. Specifically: does the request reach
|
|
someone who can act on it, is "one named boundary" a question a repo can
|
|
actually answer, and does what comes back constitute evidence or reassurance.
|
|
|
|
The value is in the friction it exposes, and that gets recorded here whatever
|
|
the answer turns out to be — including if the answer never comes.
|
|
|
|
## Outcome
|
|
|
|
Pending. Requested 2026-08-20.
|
|
|
|
- If the boundary holds with evidence: `RISK-F-0007`'s likelihood falls **for
|
|
this consumer**, and the record says how it was shown.
|
|
- If it does not: a finding of its own, with `user-engine` as fix owner.
|
|
- If nothing comes back: that is the most useful result of the three, because
|
|
the estate is currently carrying `RISK-F-0007` on the assumption that asking
|
|
works.
|