Version 2.1 — August 2026
This document describes how PII, PHI, and regulated data moves through the RGX Systems Compliance Engine across all five supported industries: healthcare (PHI/HIPAA), legal (privilege & output validation), finance (PCI/financial identifiers), professional_services (EIN/SSN/banking), and real_estate (standard PII). Sensitive data is scrubbed exclusively in-memory before any LLM call or database write. Raw regulated data is never persisted.
Architecture guarantee: Regulated data (PII, PHI, financial identifiers) is intercepted and anonymized entirely within the RGX gateway — in-memory, before any LLM call is made and before any database write occurs. The LLM provider never receives raw regulated data. No plaintext regulated fields are ever persisted to storage. What follows is the full technical decomposition of each stage.
┌─────────────────────────────────────────────────────────────────────────┐
│ ZERO-LEAKAGE ARCHITECTURE │
│ RGX AI Data Leakage Protection Layer │
└─────────────────────────────────────────────────────────────────────────┘
┌──────────────────┐
│ PARTNER CLIENT │ Protected request — payload may contain raw
│ APPLICATION │ PII, PHI, or financial identifiers
└────────┬─────────┘
│ HTTPS / TLS 1.3 (raw regulated data encrypted in transit)
▼
┌──────────────────────────────────────────────────────────────────────┐
│ RGX PROTECTION LAYER — INTERCEPTS & SCRUBS PII │
│ │
│ 1. Security token verified (SHA-256 hash only — plaintext never │
│ stored) │
│ 2. Workspace resolved — isolated data context enforced │
│ 3. Industry compliance profile loaded (healthcare / legal / │
│ finance / professional_services / real_estate) │
│ 4. Compliance Engine runs ENTIRELY IN-MEMORY: │
│ • Regex patterns scan for HIPAA identifiers, SSNs, EINs, │
│ MRNs, NPIs, card numbers, financial account numbers, etc. │
│ • Each match replaced with numbered token: │
│ {{REDACTED_PHI_1}} {{REDACTED_FIN_2}} {{REDACTED_LEG_3}} │
│ • Original PHI string goes out of scope — garbage-collected │
│ • ZERO disk / database / log writes of raw regulated data │
│ 5. Compliance audit event written non-blockingly: │
│ tenant_id · seat_id · redaction_count · pattern_types (no PHI) │
└──────────────┬───────────────────────────────────────────────────────┘
│
├────────────────────────────────────────────────┐
▼ │
┌──────────────────────────────┐ ┌─────────────────────────────┐
│ ISOLATED WORKSPACE │ │ RAW PHI — DISCARDED │
│ PIPELINE (per-workspace) │ │ │
│ │ │ Original input variable │
│ Scrubbed payload routed │ │ is garbage-collected by │
│ to LLM via workspace │ │ Node.js runtime. No write │
│ context. Data never bleeds │ │ to disk, DB, log, or any │
│ across workspace boundaries │ │ external service occurs. │
└──────────────┬───────────────┘ └─────────────────────────────┘
│
▼ ANONYMIZED PAYLOAD SENT TO LLM
┌──────────────────────────────────────────────────────────────────────┐
│ LLM PROVIDER (Anthropic) │
│ │
│ Receives ONLY scrubbed text — {{REDACTED_PHI_1}} tokens, not │
│ original values. LLM provider DPA prohibits model training on │
│ submitted data. Raw PHI never reaches this layer. │
└──────────────┬───────────────────────────────────────────────────────┘
│
▼ SAFE RESPONSE RETURNED
┌──────────────────────────────────────────────────────────────────────┐
│ RESPONSE RETURNED TO PARTNER APPLICATION │
│ │
│ LLM response contains token labels (not original PHI values). │
│ Partner may optionally de-tokenize client-side using the token map │
│ returned with the response. RGX does not log │
│ AI response content to persistent storage. │
└──────────────────────────────────────────────────────────────────────┘
ENCRYPTION: AES-256-GCM at rest · TLS 1.3 in transit
SECURITY TOKENS: SHA-256 hashed — plaintext never stored
WORKSPACE DATA: Query-layer isolation — no cross-workspace access possible
config.industry: "healthcare". The request body may contain raw PHI: patient text, SSNs, DOBs, MRNs, addresses. The payload is encrypted in transit via TLS 1.3. The partner’s Workspace Security Token is verified before any payload is read.X-Api-Key header carrying the Workspace Security Token is verified against a SHA-256 hash in PostgreSQL. The payload (including any PHI) is held in-process memory only — no disk write occurs at this stage.[NAME_1], [NAME_2], etc. This step runs for every industry, including real_estate, which has no PHI/PII pattern ruleset of its own. Unlike the PHI/PII tokens above, a name token can be reversed — using a mapping held only in this process's memory, scoped to the request's session_id, and purged after 30 minutes of inactivity. That mapping is never written to disk, logs, or the database. On the RGX-hosted path, reversal happens automatically (see the Response step below). In Passthrough Mode (see below), reversal is not automatic — RGX never sees the partner's own model's response — but the same mapping stays available for that session_id, resolvable on request via POST /process/rehydrate.{{REDACTED_PHI_1}}-style and [NAME_1]-style tokens, not original values) is sent to the LLM provider. The LLM provider never receives raw PHI or a raw name. Anthropic and OpenAI operate under data processing agreements with RGX Systems prohibiting use of submitted data for model training.[NAME_N] token the model echoed back is swapped for the real name using the Name Tokenizer's in-memory mapping (above) — the partner sees the real name normally; only the LLM provider never did. The partner receives a JSON response containing the AI output, token counts, processing time, model used, and a redactions count confirming how many PHI/PII patterns and names were scrubbed in total. The response includes the liability_disclaimer field and, where applicable, legal warnings. No raw PHI or PII is present in the response payload.passthrough: true, RGX never reaches the LLM Provider step: the scrubbed-and-name-tokenized text from steps 03 and 03b is returned directly to the partner as scrubbed_input, for the partner to send to their own model. Because RGX never sees that model's response, name tokens are not reversed automatically in this mode — the partner receives literal [NAME_N] text. If the finished response needs the real name restored, the partner calls POST /process/rehydrate with the same session_id plus the model's output text, and RGX resolves any [NAME_N] tokens against the same in-memory mapping — still without the name ever reaching a model. Everything about PHI/PII handling (in-memory only, zero persistence, per-industry ruleset) is identical to the RGX-hosted path above.Note on the inbound webhook endpoint: The public inbound webhook receiver stores a truncated body preview (first 500 characters) for webhook event logging. Partners should not route raw PHI through the inbound webhook endpoint. PHI should only be submitted through the authenticated protection gateway, where scrubbing is enforced.
Partner responsibility: RGX Systems scrubs PHI from input submitted through the protection gateway. Partners are responsible for ensuring that their applications only transmit PHI through the authenticated gateway endpoints, and that their own systems (front-end UI, local databases, logs) comply with applicable HIPAA obligations. RGX Systems’ scrubbing does not substitute for the partner’s independent HIPAA compliance obligations toward its own clients.