sub-modules
Tenant Isolation
Sleep through the next SaaS breach headline — your rows deny by default.
Every few months another headline: millions of records exposed across tenants by a bug nobody tested for. Tenant Isolation makes that headline structurally impossible here — force-enabled row-level security denies unscoped access at the database itself, so no application defect, however embarrassing, can read another tenant's rows.
Isolation layers
Each layer below denies by default — access flows only through issued decisions with scope enforced at every boundary including the database itself.
data Viz
data View
section: stages
Identity
Workforce, customer, and service identities federate through one path with sessions centrally issued, scoped, and lifetime-bound.
Decision
Access requests resolve against policy with purpose, scope, and version checked. Denials cite the rule; sensitive grants add redaction and disclosure records.
Enforcement
Force-enabled row security denies unscoped database access regardless of application behavior. Telemetry hygiene bars secrets from every observable surface.
Isolation guarantees
- Force-enabled RLS
- Unscoped reads and writes denied at the database on all tenant tables
- No shadow stores
- Zero local user, role, or permission tables capable of drifting
- Telemetry hygiene
- Raw identifiers and secrets barred from metrics, paths, logs, and packages
- section
- capabilities
Isolation by industry
Tenant enforcement bends per industry — same row-level denial, different regulatory stakes.
data Viz
data View
section: industries
Healthcare
Patient data isolated per covered entity with HIPAA access logging on every read. Cross-facility analytics run on de-identified projections, never raw rows.
Financial Services
Client data segregated per legal entity with Chinese-wall enforcement between advisory and proprietary scopes. Every cross-scope request records its authority.
Government
Agency and program isolation with classification handling per data type. Inter-agency sharing flows through governed disclosure decisions, not queries.
Tenant Isolation questions
Section 1
Can one tenant ever read another tenant's rows?
No. Force-enabled row-level security denies unscoped access at the database layer, independent of application logic.
Section 2
What about backups and exports?
Backup and export paths enforce the same tenant scope with purpose, authority, and evidence receipts before any bytes move.
Section 3
How do we prove isolation to enterprise prospects?
With architecture plus live demonstration: attempt unscoped access in a supervised session and watch the database deny it. Prospects stop asking after that.
data View
section: faqs
content section
value: XRP issues no local access tokens and maintains no local permission tables. Every access decision is issued centrally through one authority — and the database enforces scope even if application logic somehow failed to ask.
Section 6
Force-enabled row-level security on tenant tables
Section 7
Single ARGUS-issued access decisions, no local permission tables
Section 8
No vendor backdoor or hidden authorization paths
Section 9
Secret and identifier hygiene across telemetry surfaces