Implement src/whitehat_security/platform_custody.py and focused tests
against the four custody schemas. Live admission still fails closed
without a value-safe projection receipt. No new engagement or traffic.
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
Meantime polish while live E2 waits on a new trial. Example receipts carry
handles only. admit-plane --receipt is tested. Aborts can be queued without
being target assurance.
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
WH-ENG-20260822-AUDIT-E2-02 projected and then aborted: admit-plane had no
receipt adapter, so the runner sent zero packets. Consume custody receipts
as handles only, keep unconnected admission fail-closed, and retire -02.
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
The retry record is distinct from the expired -01 identifiers and is only
authorized inside 19:15Z-19:30Z.
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
The 18:00Z-18:15Z window ended with no projection-ready notice and zero
packets. Mark the identifier terminal. Record platform-pg E3 as not
applicable for an ordinary runtime conformance-view identity.
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
Record the owner-acknowledged window, pin the runner invocation including
the forged fixture id, and ask railiance-platform to project identities
only at window start. No mint, no pod apply, no packets.
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
Align plane ordering with Mason's apply, record the fresh audit-core
engagement as proposed, and keep offline admission fail-closed until
operator approval and owner acknowledgement exist.
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
Register in-process E3 and capacity fixtures, keep live database and
substrate targets pending, and ask ops-mason for namespace-only provision.
No packets, no credentials, no cancelled engagement IDs.
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
Updated by fix-consistency on 2026-08-22:
- update .custodian-brief.md for whitehat-security
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
Encode fail-closed admission, target registrations, and a credential
broker that never returns secret values. Calibrate audit-core shaped
probes in-process. Send no packets and request no live credentials.
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
Updated by fix-consistency on 2026-08-22:
- update .custodian-brief.md for whitehat-security
Assistant: grok
Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
Operator decision: whitehat is a NetKingdom facility, framed offensively -
offence is how you find out, and a control is believed until someone tries it.
Our own estate is one target among those we choose, not the only one.
I had argued for the-custodian on independence grounds. The counter-argument is
better: offensive security is security work and belongs with the security repo.
The residual tension is real and recorded rather than argued away - NetKingdom
now owns both the Tenancy Posture framework and the facility that tests
conformance to it, which is NetKingdom assessing NetKingdom. The mitigation is
that findings leave for risk-nexus under separate ownership rather than being
resolved in place. Proportionate, not perfect, and worth revisiting if
conformance findings start getting quietly closed.
The reframe changes what this repo must guard against, and that is the
substantial part of this commit. A facility that can be pointed at
infrastructure we do not own is the single thing that could turn this repo from
an asset into a liability, so the targeting rule is structural rather than
cultural.
No target without recorded authorization from whoever is responsible for it.
Own estate in build mode has standing authorization; production needs its own,
because the blast radius differs and so does the decision; anything we do not
own needs written per-engagement authorization recorded here before a packet is
sent.
Three non-authorizations written down because each is a way teams talk
themselves into it: a commercial relationship with the target, the target being
publicly reachable, and believing the owner would obviously be fine with it.
Unauthorized probing is criminal in most jurisdictions regardless of intent,
and a white-hat facility that gets this wrong is an attacker with better
paperwork.
Two consequences. The authorization record is part of the finding - a report
that cannot name what it ran under is not a finding, it is an incident. And
scope creep during an engagement is prohibited: a probe that discovers an
adjacent system stops at the boundary, because following the interesting thing
is how an authorized test becomes an unauthorized one.
Findings routing now forks. Our estate goes to risk-nexus and on to the owning
repo. Any other target goes to that infrastructure's responsible party on the
engagement's agreed terms, with risk-nexus still recording that it happened.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Answers the Tenancy Posture question that has been unowned since the framework
was drafted - who verifies a consumer's tenant boundary. Two repos were asked
and both correctly declined as fleet-scope work. The work needed a home.
Independence is the load-bearing property, not a nicety. rapp-postgres wrote
fifteen probes against its own isolation model and found four real defects,
which is good work and still the author checking their own homework. The probes
worth having are the ones the author would not think to write, because the
assumption that produced the defect produces the blind spot.
That argues against NetKingdom owning this even though it owns the security
canon: a facility verifying conformance to a framework must not report to the
repo that owns the framework, or self-grading just moves up a level. Proposed
owner is the-custodian, consistent with policy and risk. Needs confirmation.
Two things stated because overclaiming is the failure this estate keeps
catching in itself. "Automated" has a ceiling - the highest-impact cross-tenant
findings need someone who understands what the data means, since a response can
be well-formed, 200, fast, and contain another tenant's rows; so automate the
reproducible and flag the irreducible for dated review. And a passing suite
proves the attacks we thought of did not work, not that the boundary holds. The
gap between those sentences is where breaches live.
WP-0001 gates everything behind rules of engagement, because an automated
facility probing systems without written scope is indistinguishable from the
threat it models. No standing privilege, no BYPASSRLS, no superuser - an
attacker would not have them and a probe holding them proves nothing. No
exfiltration of real tenant data even as proof; a count and a schema shape are
proof enough. And no saturation probing outside a declared window, because with
a six-consumer connection ceiling that is an outage for every co-resident.
T04 exists because a probe that has only ever passed is not evidence. Every
probe must be shown failing against a known-bad fixture before it is trusted
passing - the same discipline rapp-postgres used when it verified its drift
check by deliberately re-pinning to a bad digest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
