# Security and Identity Canonical URL: https://babadook.tech/modules/security-identity Entity: modules Content hash: cad6e76bc610b0b9d1e1bbbd7bd57d7f56aba6c7074a731d3ba0c2b5b19095f1 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. ## Why central authority removes entire breach classes Shadow permission tables are where access control goes to rot: a role matrix in one module, an allow-list in another, a forgotten admin flag from a migration three years ago. XRP keeps no local tables to rot. One authority issues every decision, every decision cites policy version and evidence, and the database itself refuses unscoped access even if application logic somehow asked for it. ### data Viz ### data View section: thesis ## 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. ## From permission sprawl to one authority subtitle: What each stage feels like after adoption. layout: alternating enable Slideshow: false slideshow Interval: 5000 ### Shadow tables decommissioned date: Phase 1 status: in-progress Local user and permission stores switch off; decisions issue centrally. has Learn More: false ### Rows enforce themselves date: Phase 2 status: upcoming Force-enabled isolation denies unscoped access at the database layer. has Learn More: false ### Secrets leave telemetry date: Phase 3 status: upcoming Metrics, logs, and paths scrubbed by enforced rule, not convention. has Learn More: false ### Audits query envelopes date: Phase 4 status: upcoming Access reviews run as queries over sealed decisions with lineage. has Learn More: false ## 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. ### Authorization Every access carries purpose, scope, and policy version into the decision. Denials cite the rule; sensitive reads add redaction and disclosure records before data moves. ### 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 ## Relationships ### products - XRP — https://babadook.tech/products/xrp ### sub modules - Tenant Isolation — https://babadook.tech/sub-modules/tenant-isolation - Audit Evidence — https://babadook.tech/sub-modules/audit-evidence