Zero-Knowledge Data Architecture & Cryptographic Controls
Target audience: Information Security (Infosec), Data Protection Officer (DPO), Enterprise Architecture Team.
Last reviewed: 1 September 2026. This briefing complements MapFlow's Information Security Statement with deeper technical detail on the cryptographic controls that protect local authority data at the application layer.
1. Executive Summary
This document provides a technical overview of the security controls engineered to protect local authority data within the application. The system implements a Zero-Knowledge Application-Layer Architecture. All free-text data fields containing potentially sensitive operational data or Personally Identifiable Information (PII) are cryptographically transformed into unreadable ciphertext before leaving the application runtime boundary. Consequently, the cloud data storage tier acts strictly as a blind, zero-knowledge storage layer. This configuration mitigates risks associated with data residency, third-party sub-processors, and extraterritorial data access requests.
The Principle of Separation of Concerns (SoC)
MapFlow™ UK is architected on the foundational engineering principle of Separation of Concerns: an absolute, mechanically-enforced division between citizen-data custody and pipeline orchestration. Decoupling the data layer from the cloud configuration network structurally eliminates the exposure vectors and extraterritorial compliance risks inherent to standard cloud-hosted integration utilities.
The Citizen Data Posture
Local Proxy / Browser RAM
- Real PostgreSQL 16 WASM instance (in-browser)
- Sandboxed local IndexedDB persistence (ciphertext)
- TPM-bound master key custody
- Zero plaintext egress to the orchestration layer
The Orchestration Posture
Base44 Cloud
- Pipeline dependency graphs
- Execution status & metadata
- System liveness heartbeats
- Zero stored citizen data
1. The Localized Data Layer — Custody & Execution
All processing, mapping, and transformation of raw records occur strictly within the client's secure local perimeter. Staging pipelines use a real PostgreSQL 16 engine compiled to WebAssembly (WASM), persisting to the browser's sandboxed local IndexedDB store on the operator's own machine — never written to cloud storage. PII values are AES-256-GCM encrypted before persistence, so the IndexedDB store holds only ciphertext; decrypted plaintext exists solely in the operator's volatile RAM for the duration of an authenticated session and is discarded on session end. Data encryption keys remain bound to the physical local motherboard via TPM 2.0 Key Binding and Windows Credential Guard; they never transit the internet or enter an external password manager.
2. The Cloud Orchestration Layer — Stateless Metadata Only
The cloud-native platform functions strictly as a stateless network orchestrator and plumbing mechanism. The backend layer processes exclusively non-sensitive configuration parameters, pipeline dependency graphs, and execution runtime liveness signals. Because the cloud orchestration layer holds absolute zero visibility of, or access to, plaintext citizen data or local decryption keys, any external production order or extraterritorial warrant served to the cloud provider returns only structural system metadata. Plaintext records remain mechanically un-retrievable.
Compliance Takeaway
Under the UK GDPR Accountability Principle (Article 5(2)), data controllers must maintain continuous, audited custody of personal records. By applying Separation of Concerns, MapFlow™ UK delivers the scalability and visibility of a modern cloud interface while maintaining the strict, air-gapped security boundaries of local hardware execution across the orchestration and AI-inference paths.
2. Cryptographic Controls & Data Protection at Rest
Rather than relying solely on cloud provider infrastructure-level encryption (Encryption at Rest), this application enforces strict Application-Layer Cryptography.
1 · Content Encryption
Application Runtime: AES-256-GCM (Probabilistic Encryption)
2 · Blind Index
Application Runtime: Lowercase + HMAC-SHA256 (Salted Pepper)
2.1 Content Encryption (AES-256)
High-grade confidentiality & authenticated integrity
- Algorithm
- Advanced Encryption Standard operating in Galois/Counter Mode (AES-256-GCM). This ensures both high-grade confidentiality and authenticated data integrity.
- Mechanism
- Probabilistic encryption is enforced. Encrypting the exact same string multiple times yields completely distinct ciphertexts, eliminating pattern-analysis and frequency-analysis risks.
- Scope
- All free-text entry fields, notes, and user-generated text inputs are encrypted at the application boundary prior to outbound transport.
2.2 Blind Indexing for Opaque Search
Exact-match querying without exposing plaintext to the database engine
To facilitate exact-match querying without exposing plaintext data to the database engine, the architecture implements isolated cryptographic search tokens (Blind Indexes).
- Algorithm
- Hash-based Message Authentication Code using SHA-256 (HMAC-SHA256).
- Normalization
- Strings are strictly normalised via .trim().toLowerCase() prior to token generation to guarantee determinism across case variations.
- Tokenization
- Each field value produces a single deterministic HMAC token. Exact-match lookups only — the index cannot be used for range, prefix, or substring queries by design.
- Database Optimization
- Blind index columns are mapped to standard PostgreSQL B-tree indexes, ensuring O(log n) query efficiency without exposing any underlying cleartext semantics to the host environment.
3. Strict Key Management & Cryptographic Isolation
Zero-knowledge model — keys and hashing materials share no common ancestry
Database Blindness
The database provider (Postgres / AWS) has zero access to the encryption keys, decryption keys, or hashing peppers. They hold only unreadable ciphertexts and irreversible hashes.
Cryptographic Isolation
Key material is derived using distinct, non-overlapping contexts to prevent cross-contamination:
- Encryption Master Key — derived dynamically via context-specific identifiers: 'encryption-v1:' + appId + keyVersion.
- Blind Index Pepper — powered by a dedicated, high-entropy, out-of-band blind-index pepper environment variable. This pepper is generated via a cryptographically secure pseudo-random number generator (CSPRNG) locally on development systems (crypto.randomBytes(32)).
Storage Environment
All secrets are injected directly into the application server's secure production runtime configuration. They are never checked into source control (Git) and are absent from database memory space.
4. Regulatory Compliance & Risk Mitigation
4.1 Data Residency & UK GDPR
- Host Location
- Postgres Cloud public managed infrastructure, physically situated in the United Kingdom (UK region). All staging data, audit rows, and PII-encrypted fields remain in UK data centres end to end.
- Legal Adequacy
- Under the UK GDPR, all data processing and storage remains within the United Kingdom. No personal data leaves the UK jurisdiction, so no cross-border transfer mechanism is required.
- Zero-Knowledge Technical Override
- Because all text data is encrypted prior to crossing network boundaries, the data residing in the EU is effectively pseudonymised and mathematically obscured. This layout reduces the operational profile of the database to that of an anonymous utility host.
4.2 Mitigating Third-Party & Sovereign Risk (US CLOUD Act)
Because the underlying infrastructure involves a US-headquartered cloud provider (AWS), standard deployments run the theoretical risk of extraterritorial data disclosure requests under the US CLOUD Act.
This architecture fully nullifies this risk. In the event of a legal disclosure demand issued to the infrastructure host, the host cannot comply with a request to provide readable council data. They do not possess, control, or have access to the decryption keys or the blind index peppers required to reverse-engineer the ciphertext.
4.3 Information Commissioner's Office (ICO) Breach Safe Harbour
In strict alignment with ICO security guidelines, the application of application-layer AES-256 encryption means that even in a worst-case scenario involving a complete database compromise, the data remains cryptographically secure. Because the risk of harm to data subjects is mitigated by the zero-knowledge design, it meets the standard threshold to avoid mandatory individual breach notifications under Article 34 of the UK GDPR.
5. Data Flow Diagram (DFD) & Security Boundary Mapping
This section outlines how data moves through the architecture, identifying exactly where encryption occurs and where security boundaries are established.
[ CITIZEN BROWSER ]
|
| (1) TLS 1.3 (HTTPS) - Outbound Plaintext
v
========== SECURITY BOUNDARY: APPLICATION RUNTIME ==========
[ APPLICATION SERVER ]
|
+-> [ Reads Master Key & Blind-Index Pepper from Env Vars ]
|
+-> [ Cryptographic Processing Layer ]
| |-- Text normalized: .trim().toLowerCase()
| |-- Ciphertext generated: AES-256-GCM(Plaintext)
| +-- Token generated: HMAC-SHA256(Normalized Text, Pepper)
|
| (2) TLS 1.3 - Secure Transport of Ciphertext + Token Only
v
========== SECURITY BOUNDARY: ZERO-KNOWLEDGE CLOUD ==========
[ SUPABASE CLOUD PLATFORM (UK REGION) ]
|
v [ PostgreSQL Storage Engine ]
(Stores Encrypted Text & B-tree Blind Indexes. Zero Cleartext Visibility)5.1 Data Flow Step-by-Step Breakdown
User Input to Application Server (Data In Transit — Phase 1)
- Data State: Plaintext.
- Mechanism: Data is transmitted from the citizen's browser or frontend client over public networks using TLS 1.3 (HTTPS).
- Endpoint: Destined for the isolated application runtime environment.
The Cryptographic Processing Layer (Inside the Trusted Boundary)
- Data State: Transformation from Plaintext to Ciphertext / Opaque Tokens.
- Process A (Confidentiality): The server intercepts the plaintext and encrypts it using the local application-layer AES-256-GCM key.
- Process B (Searchability): The server clones the plaintext string, normalises it (.trim().toLowerCase()), and passes it through the HMAC-SHA256 function bound with the production blind-index pepper secret.
- Result: The original plaintext is completely destroyed in active application memory immediately following this step.
Application Server to Database Tier (Data In Transit — Phase 2)
- Data State: 100% Mathematically Obscured (Ciphertext and Hashed Tokens only).
- Mechanism: The application client establishes a secondary, authenticated connection to Postgres via TLS 1.3.
- Payload: The database payload contains only the random-looking AES payload string and the static HMAC blind index tokens.
Database Storage Tier (Data at Rest — Zero-Knowledge)
- Data State: Protected at Rest.
- Mechanism: Postgres writes the ciphertext and tokens into the PostgreSQL database engine hosted in the UK region.
- Context: The hosting infrastructure performs its standard volume encryption, but from an informational security perspective, the database remains completely blind. It cannot parse, inspect, or run logical operations on the underlying data contents.
5.2 Trust Zones & Security Vectors
To assist the DPO with threat modelling, the table below highlights how potential attack vectors are negated by this specific data flow design:
| Threat Vector | Risk Mitigated By This Architecture |
|---|---|
| Network Eavesdropping (Man-in-the-Middle) | Prevented at all stages by mandatory, modern TLS 1.3 transport encryption. |
| Compromised Database Host (Insider Threat / SaaS Breach) | Attacker gains access only to random strings (U2FsdGVk...) and irreversible SHA-256 hashes. No citizen data leaks. |
| Sovereign Legal Warrants (US CLOUD Act / EU Interception) | Infrastructure providers cannot comply with readability requests because they do not hold the application decryption keys. |
| SQL Injection / Privilege Escalation | Combined implementation of Postgres Row-Level Security (RLS) and the fact that the underlying fields contain no readable data to leak. |
| Corporate TLS-Inspection Interception (Man-in-the-Middle) | Generated proxy scripts and the Local Proxy trust the council's own corporate CA bundle via the NODE_EXTRA_CA_CERTS / MAPFLOW_CA_BUNDLE / SSL_CERT_FILE environment variables. Certificate verification is never disabled (NODE_TLS_REJECT_UNAUTHORIZED is never set to 0), so licence validation and Salesforce uploads remain protected against Man-In-The-Middle interception behind a corporate TLS-inspecting proxy. |
6. Recent Control Updates
Operational hardening applied to the zero-knowledge access and credential layer.
MFA re-login enforcement
Fresh password logins now clear the in-session MFA-verified marker before authenticating, closing a 30-minute window during which a recent verification could let an enrolled user skip the MFA challenge on re-login. Every fresh password login now re-proves MFA for enrolled users.
Least-privilege provisioning state
The Postgres Role Provisioner now positively reflects an 'already provisioned' state when a connection's active DB user is a least-privilege role (not the postgres superuser), confirming at a glance that no superuser credential is in use — reinforcing the zero-trust credential model where credentials are generated server-side and never shown, not even to admins.
MFA-gated IP/location exceptions
Per-user IP/location check exceptions (audited, revocable, per-signal) are now honoured only when the user's multi-factor authentication is active (enabled and verified). If MFA is disabled or unavailable, full security applies and any granted exception is ignored for that user — pairing the weaker IP/location posture with the stronger authentication factor, so an attacker who controls a relaxed account still faces the second factor. Each exception is stored in a dedicated, admin-only record capturing who granted it, when, and a mandatory explanation (previous reasons offered as reselectable history), surfaced in the Security Settings panel.
AI / crawler bot refusal + admin-tier datacenter block
Automated AI/crawler User-Agents (ClaudeBot, GPTBot, OAI-SearchBot, CCBot, PerplexityBot, Bytespider and other known training crawlers) are now refused at the app layer on any signed-in session — there is no legitimate reason for an AI agent to use MapFlow. The gate logs a high-severity violation, emails admins, and shows the access-denied screen; a robots.txt additionally disallows the same crawlers from public pages (search-engine bots remain allowed). The admin-tier VPN/datacenter IP policy is set to block, refusing cloud/datacenter IPs (where AI agents run) from admin accounts; regular users stay on the softer tier to avoid blocking legitimate remote workers, and per-user MFA-gated exceptions keep specific people exempt. A headless browser with a spoofed Chrome UA bypasses the polite-bot layer, which is why login, MFA, and the datacenter IP block remain the deeper controls.
Council IP allow-list (CIDR boundary gate)
Admins can now configure an explicit Council IP allow-list — the council's office CIDR ranges plus its known VPN exit IP — so any signed-in IP that falls outside every configured range triggers a new fifth IP/location signal ('outside Council IP ranges') with its own off/log/warn/block policy. This strictly bounds access to the Council network perimeter: set to block, a connection from beyond the Council boundary is refused at the app layer. The gate is a single tier (applies to every user); an admin contractor email exemption list accommodates authorised outside contractors so they are not locked out, honoured on both the MFA pre-screen (via the email query param) and the signed-in app-layer gate. The check is opt-in (off by default) so the gate is not active until an admin supplies their ranges, and per-user MFA-gated exceptions still apply to relax the signal for a named individual.
Non-AI field mapping engine as default (zero data sharing)
The reverse-engineering engine (reverseEngineerMappings) is now the formal default for all field mapping. It performs algorithmic matching using schema metadata — column names, types, profiler analysis, cardinality values, candidate record pairs, and stored learning — entirely within the Base44 UK server-side runtime, with zero data shared with any AI provider. The AI-assisted engine (aiSuggestFieldMapping) is gated behind an admin setting (ai_mapping_enabled, default OFF) with mandatory InfoSec warnings when enabled, surfaced as a Medium violation in the weekly posture report. The browser cannot override this selection. This ensures zero citizen data leaves the database for AI-assisted mapping in the standard posture.
Corporate CA-bundle trust (no TLS verification bypass)
Generated proxy scripts and the Local Proxy now trust the council's own corporate CA bundle via the NODE_EXTRA_CA_CERTS / MAPFLOW_CA_BUNDLE / SSL_CERT_FILE environment variables, replacing the previous fallback that silently disabled certificate verification on corporate TLS-inspecting networks. Verification is never disabled (NODE_TLS_REJECT_UNAUTHORIZED is never set to 0), so licence validation and Salesforce uploads remain protected against Man-In-The-Middle interception behind a corporate TLS-inspecting proxy. On a TLS failure the proxy now fails fast with a clear, actionable message pointing to the corporate CA bundle path rather than silently weakening the transport.
Notes & Caveats
- Application-layer control. The cryptographic controls described here operate at the application layer, complementing — not replacing — the infrastructure-level encryption-at-rest provided by Postgres and the Base44 platform. Both layers apply simultaneously.
- Exact-match search. Blind indexes support exact-match queries only. They cannot be used for range, prefix, wildcard, or free-text search. This is a deliberate design trade-off to preserve the zero-knowledge property; admins opt fields in for blind indexing individually during Copy-to-Postgres.
- Complementary document. This briefing complements MapFlow's Information Security Statement, which covers identity, access control, audit, recovery, AI processing and platform hosting in more detail. Read both together for the full control picture.
- Review cadence. This briefing is reviewed at least annually and on any material change to the cryptographic architecture.
Need the full control picture?
This briefing covers the cryptographic architecture. The Information Security Statement covers identity, access control, audit, recovery, AI processing and platform hosting.