Billing Ledger Isolation · Forced Row-Level Security and Trust-Strip Integrity
Why This Matters
The billing subsystem keeps two internal ledgers: a mirror of every payment-provider event, and the reconciliation ledger that compares that mirror against the provider on a schedule. Both hold tenant-scoped rows, but until now their row-level isolation was relied upon by convention rather than forced at the database. This release forces it. A tenant database connection can no longer read or write either ledger at all; the only paths that can are the system jobs that own those writes, running under an elevated role. Isolation that was operational is now structural.
The same release reconciles the security-grade badge in the footer to a single source of truth, so the grade shown can never disagree with the audit behind it.
Billing Ledger Isolation
-
Row-level security forced on both billing ledgers The payment-event mirror and the reconciliation ledger now have row-level security enabled and forced. Reads are constrained to the owning organisation and writes are reserved for the elevated system role the billing jobs run under, so a tenant connection sees zero rows and cannot insert. Class M, proof anchor: migration 103, verified continuously by the access-control check in the security harness.
-
Write paths elevated, correctness re-proven The handler that records provider events and the scheduled reconciliation job both perform cross-organisation reads and writes by design, so each runs under the elevated role for the duration of its work. Their behaviour is re-proven by the executable anchors that gate every deploy. Proof anchor: AX-BIL-003 (webhook ordering and staleness), plus a clean reconciliation run under the forced policy.
Privilege Containment
-
Continuous bypass-privilege check A new check in the security harness asserts that the database bypass privilege is held only by the expected system roles, that the tenant application role never holds it, and that the read-only audit role stays read-only. It runs on every audit and fails the board if that set ever changes. Operational control (Class O), evaluated every audit.
-
Coverage gap closed A tenant table that was already isolated but had been skipped by the audit is now included in the check, so the audit verifies what the database enforces rather than a subset of it.
Trust-Strip Integrity
-
One grade, one rank model, one writer The security grade in the footer is now derived through a single rank model end to end, and the whole trust block is written by one process from the audit report. The grade, its rank, the report date, and the audit link can no longer drift apart, because nothing else writes them.
-
The build refuses an inconsistent grade Build-time validation now rejects any grade outside the published scale, and any grade whose rank does not match it. A corrupt or stale grade fails the marketing build instead of reaching the site. Class M at build, proof anchor: footer schema validation in the marketing build pipeline.
-
Self-healing badge Each audit rewrites the trust block from its own result, so the badge reflects the latest audit automatically and recovers on its own once a clean audit runs.
Operational Impact
- Tenant connections read zero rows from either billing ledger and cannot write to them.
- Database bypass privilege confined to the expected system roles, checked on every audit.
- The footer security grade can no longer drift from the audit that produced it; an inconsistent grade fails the build rather than reaching the site.
- Pending operating-system security updates applied.
Files Changed
Backend: billing ledger isolation policy (migration 103); elevation of the webhook and reconciliation write paths; security harness (new bypass-privilege check, audit coverage fix).
Frontend: shared footer (grade validation with a rank-consistency check, single-writer trust block, render-time rank derivation).
Billing data is now isolated by the database itself, which is the foundation the live-payment rollout sits on.