modules
Security and Identity
The breach that can't happen here: cross-tenant reads are denied by the database itself.
Every breach postmortem finds the same corpse: a permission table nobody owned, a role matrix that drifted, an admin flag from a migration three years ago. XRP keeps no tables to rot. One authority issues every access decision, every decision cites policy and evidence, and the database itself refuses unscoped access even if application logic somehow asked for it.
Security guarantees
- No local tables
- Zero shadow permission stores; decisions arrive centrally issued or not at all
- Row-level denial
- Force-enabled RLS blocks unscoped reads and writes at the database
- Purpose binding
- Sensitive reads carry purpose, scope, policy version, and redaction policy
- Full lineage
- Sessions, decisions, and mutations link into evidence envelopes and Timeline-X
- section
- capabilities
Who answers for Security
Four roles, four anxieties, one authority answering each.
data Viz
data View
section: personas
Section 1
col Title: CISO
col Cont: Breach classes removed by construction, not monitored for. No shadow tables to rot, no backdoor to discover, secrets barred from every observable surface.
Section 2
col Title: CIO
col Cont: Identity federation without local stores to sync, breach, or audit separately. One session model across every site and service.
Section 3
col Title: Compliance Leader
col Cont: Purpose-bound reads with policy versions and redaction recorded per access. Examiners query envelopes instead of sampling hope.
Section 4
col Title: CEO
col Cont: The board question — could our data leak across tenants — gets a structural answer: the database denies it, not a policy document promising it.
Security in daily operation
Each surface below flows through the same authority — authenticate once, decide centrally, record everything with lineage.
data Viz
data View
section: applications
Authentication
Workforce federation, customer identity federation, and service credentials verify through one path. Sessions issue centrally with scope and lifetime bound; no local token stores exist to steal.
Audit and Evidence
Decisions and mutations seal into envelopes with actor, policy reference, and source digests. Reviews, investigations, and public-records requests run as queries instead of document hunts.
Secret Hygiene
Credentials, tokens, and identifiers stay out of metrics, paths, logs, and packages by enforced rule. Leaks fail closed at emission instead of being scrubbed after exposure.
Security sub-modules
subtitle: Isolate tenants, prove everything.
data View: security-identity:sub-modules
Tenant Isolation
desc: Row-level enforcement, no exceptions.
link: /sub-modules/tenant-isolation
Audit Evidence
desc: Lineage on every mutation.
link: /sub-modules/audit-evidence
Security questions
Section 1
Where are permissions stored?
Nowhere inside XRP. All authorization decisions are issued centrally by ARGUS; XRP holds no local permission tables that could drift.
Section 2
What stops a bug from leaking another tenant's data?
Force-enabled row-level security at the database layer. Even a defective query cannot read rows outside its tenant scope.
Section 3
How are sensitive workforce records protected?
Purpose-bound reads with field classification, scope checks, policy version, evidence receipts, and redaction — plus disclosure decisions recorded per access.
Section 4
Isn't one authority a single point of failure?
Centralized decisions with topology-matched deployment: the authority runs per site with local trust roots, so a network partition pauses convergence without forking enforcement.
Section 5
We have Okta/Entra today. Does it survive?
Yes. Workforce and customer identities federate through your existing providers — the authority consumes their assertions instead of replacing your directory.
data View
section: faqs
content section
value: Whether you run one location or fifty, there is one session model and one access decision path. XRP issues no local access tokens and maintains no local permission tables — every decision arrives centrally issued, and tenant isolation holds at the database row.
Section 9
Centrally issued access decisions across every user and service
Section 10
Force-enabled row-level tenant isolation on all tenant tables
Section 11
Workforce and customer identity federation without local shadow tables
Section 12
Evidence-bound sessions with causal lineage into Timeline-X
Section 13
Secret and identifier hygiene across metrics, logs, paths, and packages
Section 14
Purpose-scoped sensitive reads with policy version and redaction
Section 15
No vendor backdoor or hidden authorization path by construction
Section 16
Export and disclosure decisions recorded per sensitive access