audit-core, railiance-platform and flex-auth all reviewed. Every posture I
guessed was too generous, on every repo that has now self-reported.
Two of my statements about other repos were wrong as fact in canon. flex-auth
does not call tenant-engine synchronously on the authorization path - the
adapter is built and has no non-test caller, which is also why they cannot
reach I3. And I justified A4 partly as ending the copying of action strings
between repos; AuthZEN standardises the envelope and deliberately not the
action vocabulary, so that argument is withdrawn and the interoperability one
kept.
Section 13.1 was found broken independently by audit-core and flex-auth: it
required an evidence artifact for every claim while defining none below I2, A2,
E1, P1, R2 - so section 5's own worked example of a conformant absorbed repo
could not satisfy it on any axis. At or below the no-control rung a declaration
now needs a stated reason, not an artifact.
The weakest-surface rule from draft-6 was insufficient alone. A bare minimum
destroys signal, since E3-write with E1-read declares identically to E1/E1.
Declare per path, quote the minimum. Two services found this shape in
themselves within a day, so it is the common case rather than a corner.
n/a is now an admissible level. P0 presupposes a database and R0 presupposes
retained data; a stateless service is neither, and without n/a a missing rung
forces the fabrication section 6 prohibits - which is what draft-1 was rejected
for.
The A ladder had no seat for a decision point. flex-auth cannot occupy A3,
since delegating to flex-auth is not something flex-auth can do. A PDP now
declares two numbers: its own inbound level and the maximum it enables. They
read A0 enables A3, which is more alarming than A3, which is the point.
The ladders described consumers and not providers. railiance-platform showed
apps-pg at I0 A0 E0 where the zeros are structural, and OpenBao at E0 where the
mechanism in place is E4 machinery aimed at a consumer boundary - literally
correct and inverting the real security position. A provider now declares what
it makes reachable.
Crypto-shredding needed a condition it did not have. audit-core showed that a
hash over a low-entropy canonical record is a confirmation oracle, so
destroying the key does not make content unrecoverable while the commitment
survives - and that shreddability is not retrofittable onto a chain committing
to cleartext. R4 by key destruction now requires that no retained commitment
reveal the erased content.
Section 9 named database credentials only; audit-core pointed out the argument
applies with more force to the credential carrying the tenant claim. Extended.
Section 17 led with the connection ceiling when memory binds first and fails
worse. Corrected against rapp-postgres ADR-0004.
Also: a low level may be permanent by design and the guard must not nag it, and
the A4 evidence artifact now requires recording decision differences, since
substitution proves interface portability rather than equivalence.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tenant-engine assessed itself against the ladders and came back with
corrections. All five are adopted, because the ratification test says that if a
repo cannot express itself the ladders are wrong - and it could not, in three
places.
I2 conflated authority with verification. Its text named tenant-engine as the
source of existence, which made the level describing canonical identity
unclaimable by the service that provides it. An axis is assessed on a service's
own inbound surface, never on its authority over the concept. tenant-engine is
the source of tenant records and is at I1, because the acting identity arrives
in the request body rather than in a verified token.
A level now reports the weakest surface. tenant-engine has PDP-authorized
mutations and three unauthorized read routes - including the one flex-auth
calls for aal2-class decisions - and reported A2 rather than A3. Publishing the
stronger surface would be accurate about that surface and misleading about the
service. A per-surface vector was considered and rejected as premature.
The E ladder assumed all data is tenant-keyed. A registry whose rows ARE the
tenants has no predicate to scope a policy by, and enforcing one would break
the service rather than secure it. Mixed-shape services now declare an E level
plus a named registry exception; an unnamed exception is an overclaim. Without
this they overclaim or sit at E2 forever, which is what tenant-engine was
facing.
Retention and erasure are two dimensions and one level cannot carry both.
tenant-engine is R1 on backup and R0 on erasure - its lifecycle contract
deliberately defines no hard-delete, so a tenant record cannot be deleted ever,
by design, while carrying display_name and contact_email. Declared R1/R0 now.
And the compounding - personal data, no erasure path, a backup window set by
the longest-retaining co-resident - is the substrate owner's to surface,
because each part looks locally reasonable alone.
My own error, corrected: I listed tenant-engine as a live P1 occupant in both
the ladder and the E/P matrix. They are on SQLite. P1 is TEN-WP-0009's target
and the provisioning is my own unapplied intake. Asserting a placement that a
workplan exists to create is exactly the kind of claim this document forbids.
Worth recording: they found an unfiltered cross-tenant read in their own event
accessor while assessing against the ladder, before publishing anything.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An earlier revision of this section asserted the adversarial facility was
deliberately not NetKingdom's, on independence grounds. Overruled, and the
counter-argument is better: offensive security is security work.
The facility is also framed more broadly than this document assumed - it is
pointed at infrastructure we choose, our own estate among them, and testing
conformance to this framework is one use of a general capability rather than
its purpose.
The tension I raised is left in the text rather than deleted, because it is
real: NetKingdom now owns both this framework and the facility that tests
conformance to it. The mitigation is that findings leave for risk-nexus under
separate ownership instead of being closed in place, and the trigger to
revisit is conformance findings starting to close quietly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Question 12 asked whether to add a quality-of-service dimension. No - because
we could not enforce it. Community PostgreSQL has no resource governor, so a
declared priority would be an unenforced claim in a declaration, which is what
retiring tenantIsolation was about. An axis implies graduation and enforcement
and this has neither.
Co-residents are equal, and a consumer whose latency cannot survive an
unprioritised neighbour escalates to P2. Service class is still declared, as a
category not a level: it informs placement, acts as a trigger, and gives
"acceptable degradation" in the noisy-neighbour artifact something to be
acceptable relative to - what batch tolerates is an outage for latency-critical.
Class mixture must be visible, because an unenforceable risk nobody can see is
worse than one that is stated. rapp-postgres now reports it and the live
instance already flags latency-critical beside batch.
Gateway-level prioritisation in a connection proxy is recorded as the known
escalation short of P2 - real, and infrastructure we do not run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
whitehat-security takes the adversarial evidence artifacts - the framework's
highest-severity gap, unowned since it was drafted. audit-core and tenant-engine
were right to decline it as fleet-scope work; the answer was a home of its own
rather than a volunteer.
Recorded here with the part that bears on this document: the facility is
deliberately not owned by NetKingdom, which owns this framework. Verifying
conformance to a standard while reporting to the standard's owner is
self-grading one level up.
Two consequences land back on the framework. Cadence becomes a security
parameter rather than a schedule, since for a detection-based control the
interval between runs is the exposure window. And a passing suite is proof that
the attacks attempted did not work, not proof of isolation - recording a green
run as "E2 verified" would be exactly the overclaim section 6 prohibits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ratifies the tenant capability-role model (PLTF/IAM/VEN/CUS, non-exclusive,
independent of ADR-0013's grouping axis), a hybrid carrying mechanism
(tenant-engine authoritative, key-cape caches a tenant_roles claim at
issuance, flex-auth re-validates live for aal2-class decisions), and
tenant-engine as a new, separate service owning tenant existence, grouping,
capability roles, and plan/subscription assignment -- not a module inside
user-engine, whose own boundary contract already scopes it to consuming
tenant identifiers, not owning them.
canon/standards/tenant-engine-boundary-contract_v0.1.md defines that
ownership boundary before the repo exists, mirroring how
user-engine-boundary-contract_v0.1.md was sequenced.
canon/standards/iam-profile_v0.3.md (minor version per ADR-0011's own
governance -- optional claim addition, no breaking change) adds the
tenant_roles claim, folds in ADR-0013's tenant-identifier vocabulary, and
documents the live-revalidation requirement. docs/platform-identity-
security-architecture.md's Tenant Model section and SCOPE.md's canonical
spec pointer updated to match; other historical citations of v0.2 left as
version-pinned references, not bulk-updated.
Records Bernd's trial-tenant policy: trial-grouped tenants may hold any
capability role (showcase/test/explore), with safety enforced through
tenant-engine-owned resource guardrails (spend limits, entity/action
counts) rather than role gating -- guardrail design is reserved, explicitly
not specified by this change.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Refine the recursive platform security architecture to make OpenBao the
canonical runtime secret authority, with SOPS/age, K8s Secrets, and the
emergency bundle reframed as bootstrap/delivery/break-glass mechanisms.
- credential-management standard v0.2: add OpenBao runtime authority
section, rotation rules, and prohibited patterns (OpenBao-as-PDP,
tenant platform-root)
- platform-identity-security-architecture: mark implemented; add
flex-auth/Topaz implications, Coulomb onboarding path, and a
production-readiness checklist
- NK-WP-0004/0005: document bootstrap-to-OpenBao handoff boundary
- NK-WP-0006/0007: status -> done with implementation reviews; add
recursive platform/tenant split and OpenBao broker/audit role for
object-storage STS vending
- NK-WP-0008: status -> done; repoint corpus to infospace-bench
- new ADR-0007 (orchestration boundary), ADR-0008 (STS vending
boundary), and the object-storage STS credential-vending architecture
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
