UK Patent Application No. 2602911.6

SCRS Data Firewall

Patent-pending AI security architecture. See how we protect sensitive data before it reaches any AI model.

Session: ...
Docs: 0
Revoked: 0

See SCRS in Action

A 7-minute walkthrough of the dual-gate architecture that keeps your data safe from AI exposure.

01

Paste Your Own Data

Paste any text containing personal information. Watch SCRS detect and redact PII in real time.

02

Live Chat Redaction

Type a message containing sensitive data. See two layers: what YOU typed vs what the AI receives.

Type a message and click "Send through SCRS"...
03

Try to Reverse the Redaction

We've pseudonymised this text. Can you figure out the original names, emails, or account numbers? Spoiler: you can't.

Loading challenge...
Why it's impossible: SCRS uses AES-256-GCM encryption with per-document keys. The pseudonyms ([PERSON_1], [EMAIL_2]) are random tokens with no mathematical relationship to the original values. Without the encryption key (which is stored in a separate KMS), reversal is computationally infeasible.
04

Key Revocation: The Kill Switch

When an employee leaves or data must be destroyed, SCRS permanently revokes the encryption key. Watch what happens.

Client: Sarah Johnson Account: 12345678 Balance: £234,500 Status: Active
Waiting for revocation...
What happens to the search index? The pointer to this document remains temporarily in the vector index but is immediately marked as a tombstone (inactive). Future searches will skip it entirely. The tombstoned entry is removed during scheduled cleanup — no index rebuild required. This is how SCRS achieves instant revocation without the costly re-indexing that conventional systems need.

Patent claim (§85–§88): "Pointers corresponding to revoked content items are marked as tombstoned in the vector index and removed during deferred index maintenance operations comprising at least one of: garbage collection, compaction, rebalancing, or scheduled cleanup processes."
05

Role-Based Access Control

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

Step 1: Ingest Document

Supports PDF, DOCX, TXT. Automatically detects PII.

When you upload a document, SCRS does three things:
1. Detects sensitive fields (PII/PCI/PHI) and applies a security label
2. Stores the real document encrypted in a secure store
3. Stores only a search representation (embedding + metadata pointer) in the search index
Important: The searchable index does not store full plaintext.

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 Ready for ingestion...

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"] }

What the Search Index Actually Contains

The vector index stores no plaintext. Here's exactly what Gate 1 searches over — and what it doesn't.

✅ Stored in Vector Index

embedding: [0.0234, -0.1892, 0.0541, ...] (1536 floats)
doc_pointer: "doc_a7f3d0" (UUID reference)
scope_tenant: "T1" (tenant isolation)
scope_collection: "finance" (RBAC filter)
security_label: "confidential" (classification)
integrity_hash: "sha256:a1b2c3..." (tamper check)
is_tombstoned: false (revocation flag)

❌ Never in Vector Index

"Dear Sarah Johnson, your account 12345678..."
"Client: Dr. James Chen, NI: AB 12 34 56 C"
"Revenue: £2.4M, Tax liability: £480,000"
Plaintext is stored separately in the Encrypted System-of-Record Store, protected by AES-256-GCM with per-document keys. It can only be accessed through Gate 2 after entitlement validation.
Patent claims (§7–§8): "The vector index stores embeddings and associated metadata optimised for similarity search operations... wherein the vector index excludes plaintext content items" and "the encrypted system-of-record store stores content items encrypted and physically and/or logically isolated from the vector index."
06

Re-Ranking: Smart Filtering Before Decryption

Gate 1 finds candidates. The re-ranker scores them using metadata only — no decryption happens yet. Only the best candidates reach Gate 2.

In plain English: Imagine you asked a librarian to find books about "finance regulations". Gate 1 pulls 9 books from the shelf. But the re-ranker is like a second librarian who checks the book covers, dates, and labels — without opening them — and narrows it down to the 3 most relevant. Only those 3 get unlocked (decrypted) by Gate 2.

Why this matters: The fewer documents that get decrypted, the less sensitive data is exposed. Even if Gate 1 over-retrieves, the re-ranker ensures only the most relevant documents are ever decrypted.

Patent claim (§45–§53): "A re-ranking module configured to receive at least a subset of the candidate pointers and produce re-scored candidate pointers based on relevance to the query, wherein the re-ranking module operates on metadata or sanitised representations without requiring decryption of full plaintext content."

Run a query in Section 05 to see re-ranking in action. The response will show Gate 1 candidates, re-ranked finalists, and Gate 2 decrypted results.

07

Dereference Entitlements: Temporary Access Passes

Before Gate 2 decrypts anything, it demands a time-limited cryptographic token — like a visitor pass that expires in 30 seconds.

In plain English: Think of it like a security building where you need a visitor pass to enter the vault. When you ask a question (query), the system issues you a pass. The pass has your name, what you're allowed to see, and an expiry time (30 seconds). If your permissions change between getting the pass and reaching the vault, the guard rejects it. No pass = no documents.

Why this matters: Even if a hacker intercepts a query, the token expires before they can replay it. And if an admin revokes someone's access mid-query, the token detects the scope change and blocks decryption instantly.

Patent claim (§58–§62): "The policy processor issues a time-limited dereference entitlement cryptographically bound to the access scope... The verification module requires presentation and validation of a valid dereference entitlement before performing the secondary authorisation check and releasing plaintext."
08

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)
09

Audit Trail

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

Dual-Gate Architecture

Both gates must pass before ANY plaintext is revealed. Fail-closed by design.

User Request → Policy Processor

┌─────────────────────────────────┐
GATE 1: Scoped Retrieval
│ Tenant isolation │
│ Collection filtering │
│ Classification check │
└───────────────┬─────────────────┘
↓ Candidate Pointers (NO plaintext!)
┌─────────────────────────────────┐
GATE 2: Verify & Decrypt
│ Expiry validation │
│ Revocation check │
│ Integrity verification │
│ AES-256-GCM decryption │
└───────────────┬─────────────────┘
Authorized Results

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.

Compliance & Regulatory Alignment

GDPR Ready

  • ✓ Purpose limitation
  • ✓ Consent management
  • ✓ Right to erasure (revocation)
  • ✓ Data minimisation (PII redaction)
  • ✓ Audit trails (immutable logs)

SOC 2 Controls

  • ✓ CC6.1 Logical access (dual-gate)
  • ✓ CC6.6 Encryption (AES-256-GCM)
  • ✓ CC7.2 Monitoring (audit logging)
  • ✓ CC7.3 Revocation (key deletion)

Industry Standards

  • ✓ ISO 27001 A.10 (Cryptography)
  • ✓ ISO 27001 A.9 (Access Control)
  • ✓ UK AADC (Children's Data)
  • ✓ ICO Data Sharing Code

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.

Business Impact: ROI Analysis

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.

Your SCRS Compliance Score

Based on your demo session, here's how SCRS would protect your organisation.

0% Protected
0
PII Entities Detected
0
Documents Secured
0
Unauthorized Blocked

SCRS protection for every use case

Whether you're a parent, a business owner, or an enterprise CISO — your data deserves a firewall.

👨‍👩‍👧‍👦

For Families

Parental controls, engagement tracking, weekly brain health reports, content filtering, and child-safe AI.

Learn more
🏛

For Enterprise

SCRS API, BYOK encryption, compliance frameworks, webhooks, IP allowlisting, and dedicated support.

Talk to sales
See pricing on pophastalabs.com →

Get in touch or request your security assessment

Fill in the form below and we'll send you a detailed report + get back to you about how SCRS can protect your organisation.

AES-256-GCM
UK Patent Pending
Companies House 16742039
GDPR Compliant
Hash-Chain Audit
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 2256 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.