tegwick 36b707f0c3 RISK-WP-0004: five of six tasks done; the executor is the operator's call

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>

2026-08-20 08:49:23 +02:00

2.2 KiB

Raw Permalink Blame History

type

title

date

requested_by

requested_of

status

findings

workplan

RISK-V-0002

verification

Tenant boundary of user-engine — verification requested

2026-08-20

risk-nexus

user-engine

requested

RISK-F-0007

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.

2.2 KiB Raw Permalink Blame History