Seed INTENT and WP-0001: adversarial evidence facility

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>

INTENT.md

@@ -0,0 +1,140 @@
+# INTENT — whitehat-security
+
+## Why this repo exists
+
+`whitehat-security` is the estate's **adversarial evidence facility**. It
+attacks the estate's own systems, on a schedule, to find out whether the
+security properties they claim are actually true.
+
+It exists because of a specific gap. NetKingdom's *Tenancy Posture* standard
+splits evidence into two kinds: **mechanical** — a structural assertion a
+machine can make, which belongs in each repo's own CI — and **adversarial** —
+a semantic claim that requires setting up hostile conditions and observing what
+happens. Every repo can produce the first. **No repo can honestly produce the
+second about itself**, and the framework's most severe open question has been
+sitting unowned for exactly that reason: who verifies that a consumer's tenant
+boundary actually holds.
+
+Two repos were asked and both correctly declined, on the grounds that a service
+which grows fleet responsibilities because it happened to be nearby is how
+boundaries erode. They were right. The work needed a home of its own.
+
+## Independence is the point
+
+A repo testing its own boundary grades its own homework.
+
+`rapp-postgres` wrote fifteen adversarial probes against its own isolation
+model and found four real defects in its own provisioning SQL. That is good
+work and it is still the author checking their own homework — the probes most
+worth having are the ones an author would not think to write, because the same
+assumption that produced the defect produces the blind spot.
+
+So this repo is **independent by construction**:
+
+- It does not take a repo's declared posture as true. It tests the claim.
+- It is not owned by the repo whose canon it verifies. NetKingdom owns the
+  tenancy framework; a facility verifying conformance to that framework must
+  not report to it, or the self-grading problem simply moves up one level.
+- It reports findings to `risk-nexus`, which owns severity and disclosure. It
+  does not decide how bad its own findings are, for the same reason.
+
+**Proposed owner: `the-custodian`**, consistent with `policy-nexus` and
+`risk-nexus`, and deliberately not NetKingdom. To be confirmed.
+
+## What it owns
+
+- **Adversarial evidence artifacts.** The tests that produce the evidence the
+  Tenancy Posture ladders require but no repo can self-certify:
+  cross-tenant read and write attempts (E2), row-level-security conformance
+  under attack (E3), per-tenant credential confinement (E4),
+  noisy-neighbour characterisation (P1/P2), erasure verification (R4).
+- **The attacker model.** What an adversary is assumed to hold at each level —
+  a leaked runtime credential, SQL execution, a compromised process — written
+  down, so a probe can be judged against a threat rather than against taste.
+- **Cadence.** How often each probe runs. This is not a scheduling detail: for
+  any control whose guarantee is *detection rather than prevention*, the
+  interval between runs **is** the exposure window. `rapp-postgres` ADR-0003
+  says so explicitly and leaves the number to be set here.
+- **Differential testing between tenant contexts.** Running the same request as
+  two tenants and comparing responses is the mechanically reproducible core of
+  cross-tenant testing, and it is this repo's principal technique.
+- **Rules of engagement.** What may be probed, where, with what credentials,
+  and what must never be done. An automated facility without this is
+  indistinguishable from the threat it models.
+
+## What it does not own
+
+- **Fixing anything.** A finding routes through `risk-nexus` to the repo that
+  owns the defect. A security facility that fixes things becomes a second
+  engineering team with no boundary and no reviewer.
+- **Severity, disclosure and timing.** `risk-nexus`. This repo says what is
+  true; that repo says how much it matters and who hears about it.
+- **Mechanical CI evidence.** Schema assertions, unit tests and provisioning
+  checks stay with the repo that owns the code. This repo does not take over
+  anyone's test suite.
+- **Deciding what the security model should be.** NetKingdom's canon says what
+  good looks like. This repo says whether we have it.
+- **Blocking delivery.** In build mode a finding is information. If that
+  changes it will be a recorded decision, not a habit that accretes.
+
+## Honest limits on "automated"
+
+The word in the repo's description is *automated*, and it must not be oversold
+— overclaiming is the failure this estate keeps catching in itself.
+
+External testing practice is consistent that the highest-impact cross-tenant
+findings concentrate in access control, business logic and tenant isolation:
+precisely the categories that need someone who understands what the data
+*means* to recognise that a response is wrong. A response can be well-formed,
+200, fast, and contain another tenant's rows.
+
+So:
+
+- **Automate the reproducible.** Structural conformance, differential responses
+  between tenant contexts, credential confinement, resource saturation. This is
+  most of the surface and it should run without anyone remembering to run it.
+- **Flag the irreducible.** Where a finding requires semantic judgement, the
+  facility's job is to set up the conditions, capture the evidence, and mark it
+  for review with a date — not to return green.
+- **A passing suite is not proof of isolation.** It is proof that the attacks
+  we thought of did not work. State it that way in every report, because the
+  gap between those two sentences is where breaches live.
+
+## The failure this repo must avoid
+
+**A probe that has only ever passed is not evidence.** `rapp-postgres` verified
+its own drift check by deliberately breaking the thing it watched and
+confirming the check failed. Every probe here inherits that obligation: it must
+be shown to fail against a known-bad fixture before it is trusted against a
+real system.
+
+The second failure is subtler. A probe that starts passing because it was
+weakened is worse than a deleted probe, because it reports safety. Probe
+changes are therefore reviewed as security changes, and a probe that begins
+passing after a change to *itself* rather than to the system is treated as a
+finding.
+
+## Relationship to the rest of the estate
+
+```
+whitehat-security  →  risk-nexus  →  policy-nexus
+   finds                triages         publishes
+                     (severity,      (permanent,
+                      disclosure)     addressable)
+```
+
+It reads posture claims and canon from the repos that own them, attacks the
+running systems those claims describe, and hands what it finds to `risk-nexus`.
+It publishes nothing directly and fixes nothing.
+
+The first work is already specified and waiting: the E2 cross-tenant evidence
+artifact, which is Tenancy Posture's highest-severity unowned gap, and the
+noisy-neighbour characterisation, which the framework had to reword once
+already because its first draft asserted something shared infrastructure cannot
+provide.
+
+## What good looks like
+
+The estate knows which of its security claims have been tested, when, and by
+what attacker model — and can tell the difference between a property that has
+been verified and one that has merely never failed.