SCRS Data Firewall

Role-Based Access Control

Three personas with different access scopes. The same search behaves differently depending on who is asking.

Step 1: Pre-Loaded Corpus

This demo runs against a curated seed corpus — no uploads required.

Every document in the corpus has already been through SCRS:
1. Detected sensitive fields (PII/PCI/PHI) and applied a security label
2. Stored the real document AES-GCM encrypted in the secure store
3. Stored only a search representation (embedding + metadata) in the index
Use Step 2 (Query) to run queries against the seeded data.

Seeded Tenant

T1 — Finance & Legal
4 documents: earnings memo, expense policy, press release, vendor contract

Available Collections

finance · legal

Uploads are disabled in this live demo so the attack surface stays limited to the curated corpus. To try your own documents, clone the repo and run locally.

Step 2: Security Pipeline

The pipeline prepares content for safe AI usage:
• PII Detection: Identifies personal and regulated data
• Sanitisation: Creates a safe representation for search and AI prompts
• Policy Binding: Attaches scope rules (who can find, who can view)
• Audit Logging: Records controls applied
Before any text is sent to an AI model, SCRS can redact it by policy.

System Corpus loaded. Ready to demonstrate the pipeline when you run a query.

Step 3: Secure Retrieval (Alice)

What happens when you search:
• Gate 1 (Find): SCRS searches only inside Alice's authorised scope. Out-of-scope documents are not returned.
• Gate 2 (Reveal): SCRS verifies access again and only then decrypts and shows readable content.
If verification fails, it fails closed (returns nothing).

Unauthorized Access Simulation

This demonstrates why SCRS is different from "filter later" systems: Bob cannot retrieve what he is not allowed to know exists.

Bob is an external consultant with:

Role: 'consultant'
Max Security Label: 'public'
Allowed Collections: 'legal' (NOT finance)

Active Scope Payload (JSON)

{ "tenant": "T1", "user_role": "consultant", "purpose": "review", "max_label": "public", "allowed_collections": ["legal"] }

Attempt Retrieval (Bob)

Try searching for the same document Alice can see in the seeded corpus.

Expected result: Bob should receive no readable content. The system blocks at Gate 1 (scope) or Gate 2 (decryption).

Secure Retrieval (Charlie - Doctor)

Can only see Healthcare documents. Compliance enforced.

Charlie can only retrieve Healthcare documents within his scope. Cross-domain data (e.g., Finance) is excluded by default.

Transparency: See the Code

Don't trust marketing claims -- verify the implementation yourself. Here's the actual encryption code running this demo.

AES-256-GCM Encryption (crypto.py)

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

def encrypt(plaintext: bytes, key: bytes) -> bytes:
    """AES-256-GCM authenticated encryption.
    Returns: nonce (12 bytes) + ciphertext + tag (16 bytes)"""
    nonce = os.urandom(12)
    aesgcm = AESGCM(key)
    return nonce + aesgcm.encrypt(nonce, plaintext, None)

def decrypt(data: bytes, key: bytes) -> bytes:
    """AES-256-GCM authenticated decryption.
    Raises InvalidTag if tampered."""
    nonce, ciphertext = data[:12], data[12:]
    aesgcm = AESGCM(key)
    return aesgcm.decrypt(nonce, ciphertext, None)

Hash-Chain Audit Log (audit.py)

import hashlib, json, datetime

def append_event(action, data, conn):
    """Append to hash-chained audit log.
    Each entry's hash = SHA-256(previous_hash + action + data)"""
    prev = get_last_hash(conn) or "GENESIS"
    payload = json.dumps({"action": action, "data": data,
                          "timestamp": datetime.datetime.utcnow().isoformat()})
    new_hash = hashlib.sha256(
        (prev + payload).encode()
    ).hexdigest()
    insert_event(conn, action, payload, new_hash, prev)
    return new_hash

Key Management Service (kms.py)

class KeyManagementService:
    """In-memory KMS for demo. Production uses AWS KMS / Azure Key Vault."""

    def generate_document_key(self, tenant_id, doc_id):
        """Generate a unique 256-bit key per document."""
        key = os.urandom(32)  # 256 bits
        self._keys[(tenant_id, doc_id)] = key
        return key

    def revoke_document_key(self, tenant_id, doc_id):
        """Permanently destroy a document's encryption key.
        After this, the document's ciphertext is unrecoverable."""
        self._keys.pop((tenant_id, doc_id), None)
        # Key is gone. Data is dead. No backdoor.

UK Patent Application No. 2602911.6 — SCRS Dual-Gate Architecture
Companies House: 16742039 (Pop Hasta Labs Ltd)

Audit Trail

Every action during this demo has been logged with a tamper-evident hash chain. Click any entry to verify integrity.

Key Security Features

🔒

Zero-Knowledge Search

Vector index contains only sanitised embeddings. No PII exposed in search.

⚡

Instant Revocation

Revoke access immediately. Key deletion blocks decryption — no re-indexing needed.

🏢

Multi-Tenant Isolation

SQL-level tenant filtering prevents cross-company data leaks.

📝

Immutable Audit Log

SHA-256 hash-chained trail. Tamper-evident. Exportable for compliance.

Why Traditional AI Access Is Dangerous

Vector indexes contain plaintext — any breach exposes raw data

Single authorization check — insufficient for regulated industries

Revocation requires re-indexing — hours or days to remove access

Cross-tenant data leaks — compliance violations waiting to happen

In regulated industries, these failures lead to: GDPR fines (up to 4% of global revenue), PCI DSS violations, FCA/SRA penalties, and irreversible customer trust erosion.

Metric	Without SCRS	With SCRS
Data breach risk	HIGH (plaintext exposed)	LOW (encrypted + gated)
Revocation speed	Hours/Days (re-index)	Instant (key delete)
Compliance cost	HIGH (manual controls)	LOW (automated)
Tenant isolation	Application-level	Database-level
Employee offboarding	Manual revocation	One-click kill switch

Common Questions

Why two gates instead of one?

Defence in depth. Gate 1 prevents unauthorised candidates from ever appearing in results. Gate 2 provides independent verification before decryption. If either fails, no plaintext is revealed (fail-closed design).

What happens when an employee leaves?

The admin clicks one button to revoke their encryption key. Instantly, all their data becomes permanently unreadable — not deleted, not archived, but cryptographically destroyed. No backdoor, no admin override, no recovery. The audit trail records the revocation for compliance.

How does SCRS handle GDPR data residency?

The AccessScope includes geo-jurisdiction flags. Gate 1 filters by allowed regions. For US-based AI providers, all prompts pass through SCRS PII redaction first — the AI model never sees raw personal data. We are pursuing Standard Contractual Clauses (SCCs) with each provider.

What's the performance overhead?

Gate 1 filtering is SQL-level (fast). Gate 2 verification adds ~10-50ms per document depending on KMS latency. For 5 results, total overhead is ~50-250ms. This is acceptable for security-critical operations and invisible to end users.

Can I bring my own AI keys (BYOK)?

Yes. Enterprise customers can use their own OpenAI, Anthropic, Google, or xAI API keys. Keys are encrypted with AES-256-GCM using org-derived keys and decrypted per-request. Your data never touches our AI accounts.

Is this just a demo or a real product?

This demo runs real SCRS encryption and PII detection — it's not simulated. The full production system is live at pophastalabs.com powering the Other Me platform for families, businesses, and enterprises across the UK.

For Technical Evaluators

🧮 Verify the Mathematics

Click to expand 4 interactive cryptographic proofs

Proof 1: Encryption Correctness

AES-256-GCM provides authenticated encryption — the ciphertext is both confidential AND tamper-proof.

✅ Correct Key

plaintext = "Client: Sarah Johnson"
key = generate_key(256 bits)
ciphertext = AES_GCM_encrypt(plaintext, key)
result = AES_GCM_decrypt(ciphertext, key)
→ result == plaintext ✓

❌ Wrong Key

wrong_key = generate_key(256 bits)
result = AES_GCM_decrypt(ciphertext, wrong_key)
→ AUTHENTICATION FAILED
→ InvalidTag exception raised
→ Zero plaintext revealed

Why this matters: Brute-forcing a 256-bit key would require 2²⁵⁶ attempts — that's more operations than atoms in the observable universe. Even with every computer on Earth working together, it would take longer than the age of the universe.

Proof 2: Scope Isolation

Gate 1 enforces tenant and collection isolation at the database query level — not application level.

✅ Alice (Admin, Tenant T1)

scope = {tenant: "T1", collections: ALL}
query("earnings report")
→ 3 results from finance, legal

❌ Bob (Consultant, Tenant T1)

scope = {tenant: "T1", collections: ["legal"]}
query("earnings report")
→ 0 results (finance excluded from scope)

Why this matters: The SQL WHERE clause filters at the database level: WHERE tenant_id = ? AND collection_id IN (?). Out-of-scope documents never enter the candidate set — they're not "filtered out," they're never found.

Proof 3: Tamper Detection

The audit trail uses SHA-256 hash chaining. Modifying any record breaks the chain — making tampering instantly detectable.

Record 1:

data = "user:alice action:ingest doc:d1"
hash_1 = SHA256("GENESIS" + data)
→ hash_1 = a3f2b8c1...

Record 2:

data = "user:bob action:query doc:d1"
hash_2 = SHA256(hash_1 + data)
→ hash_2 = 7e4d9f2a...

✅ Unmodified Chain

verify(hash_2) → valid
SHA256(hash_1 + record_2) == hash_2 ✓

❌ Tampered Record

modify record_1 → hash_1 changes
SHA256(new_hash_1 + record_2) ≠ hash_2 ✗
→ CHAIN BROKEN — tampering detected

Proof 4: Irreversible Revocation

When an encryption key is revoked, the data becomes permanently unrecoverable — by design.

Before Revocation:

key_store = {doc_d1: key_abc123}
decrypt(ciphertext, key_abc123) → "Client: Sarah Johnson"

After Revocation:

key_store = {doc_d1: DELETED}
decrypt(ciphertext, ???) → IMPOSSIBLE
No key exists. No admin override. No recovery.

❌ Attacker with Database Access

SELECT ciphertext FROM documents
→ Has ciphertext bytes ✓
→ Has NO key to decrypt ✗
→ Data is permanently dead

❌ Admin with Full Server Access

Key was in memory only
Memory wiped on revocation
→ Even the admin cannot recover
→ Provable GDPR Art 17 compliance

GDPR implications: This satisfies Article 17 (Right to Erasure) and Article 5(1)(e) (Storage Limitation). The data isn't just deleted — it's mathematically proven to be unrecoverable. No forensic tool can retrieve it.

See SCRS in Action

Paste Your Own Data

Live Chat Redaction

Try to Reverse the Redaction

Key Revocation: The Kill Switch

Role-Based Access Control

Step 1: Pre-Loaded Corpus

Step 2: Security Pipeline

Step 3: Secure Retrieval (Alice)

Unauthorized Access Simulation

Attempt Retrieval (Bob)

Secure Retrieval (Charlie - Doctor)

Transparency: See the Code

Audit Trail

Dual-Gate Architecture

Key Security Features

Compliance & Regulatory Alignment

GDPR Ready

SOC 2 Controls

Industry Standards

Why Traditional AI Access Is Dangerous

Business Impact: ROI Analysis

Common Questions

Your SCRS Compliance Score

SCRS protection for everyone

For Families

For Small Business

For Enterprise

Get in touch or request your security assessment

Proof 1: Encryption Correctness

Proof 2: Scope Isolation

Proof 3: Tamper Detection

Proof 4: Irreversible Revocation