# Sovereign by Design: Why Your Data Platform Must Live Inside Your Perimeter

*A Project 82 white paper — ClearPath Partnership Limited*

## Executive summary

The modern data platform is, almost without exception, delivered as SaaS. For most organisations that is a reasonable trade. For yours — if you operate in government, defence-adjacent industry, critical infrastructure, or regulated financial services — it is a structural liability. Data residency becomes a contractual fiction, every integration widens the exfiltration surface, and the platform your operations depend on can be re-priced, re-hosted, or switched off by decisions taken outside your jurisdiction.

Sovereignty is not a deployment option bolted onto a cloud product. It is an architectural property: the data, the compute, the AI models *and the control plane* must all run inside your perimeter — on a single host, in a sovereign cloud, or in a fully air-gapped enclave. Project 82 is a data-fusion and decision platform designed for exactly this posture from its first commit: every remote component speaks outbound-only to one HTTPS URL, nothing connects into your networks, every unit of work is cryptographically signed, air-gapped installs receive updates through a one-way import channel, and tenancy is enforced in the database itself.

This paper sets out why perimeter-resident platforms matter, what genuine sovereignty requires, how Project 82 delivers it, and — whichever vendor you ultimately choose — what you should demand of any platform that asks to hold your most sensitive data.

## 1. The SaaS default, and who it fails

Over the past decade the centre of gravity for data integration and analytics moved decisively to multi-tenant SaaS. The economics are obvious: one codebase, one fleet, continuous delivery, usage-based pricing. If your data is marketing telemetry, that model serves you well.

It fails when the data itself is the sensitive asset. A national infrastructure operator fusing SCADA history with maintenance records; a bank assembling a register of information for operational-resilience regulation; a public body linking case files across departments — these organisations are not buying dashboards. They are concentrating their most consequential information into one place, and the question of *where that place is, and who else can reach it* stops being an implementation detail and becomes the primary risk decision.

Three risks compound in the SaaS model:

1. **Residency risk.** Contractual region-pinning is a promise about where data is stored, not about where it can be processed, cached, indexed, or subpoenaed. Support access, model training pipelines, and cross-region failover all create paths a residency clause does not close. For organisations answerable to national security frameworks or regimes such as GDPR, NIS2 and DORA, "the vendor says it stays in-region" is a weak foundation for an accountability you personally carry.
2. **Exfiltration risk.** Every SaaS data platform requires connectivity from your networks to the vendor's — agents, gateways, VPN tunnels, allow-listed API ranges. Each channel that carries your data out is a channel an attacker who compromises either end can abuse. The blast radius of a vendor-side breach is every tenant at once.
3. **Dependency risk.** When the control plane lives with the vendor, so does your operational continuity. Pricing changes, feature deprecation, acquisition, sanctions exposure, or a simple outage in another jurisdiction can degrade or halt capabilities your organisation has built its processes around. Regulators increasingly treat this concentration as a systemic issue; DORA's third-party provisions exist precisely because "it is in the cloud" is not a resilience strategy.

None of this is an argument against cloud computing. It is an argument that for a specific class of organisation — the regulated mid-market that cannot command an eight-figure bespoke engagement but carries sovereign-grade obligations — the default delivery model is misaligned with the risk.

## 2. What sovereignty actually means

"Sovereign" has become a marketing adjective, so it is worth being precise. A platform is sovereign when **all four** of the following run inside infrastructure you control:

1. **The data** — raw source extracts, transformed datasets, and the object model built over them.
2. **The compute** — the pipelines, query engines and indexes that process that data.
3. **The AI models** — any assistant or inference capability, with weights resident in your enclave and prompts that never leave it.
4. **The control plane** — the system that decides what work happens, who may see what, and what gets audited.

The fourth is the one most "sovereign" offerings quietly fail. A platform whose data plane sits in your data centre but whose orchestration, identity, entitlements or telemetry flow through the vendor's cloud has moved the *storage* inside your perimeter while leaving the *authority* outside it. Whoever operates the control plane can direct the data plane. If that is not you, you are not sovereign — you are hosting.

Genuine sovereignty therefore implies a spectrum of deployment postures, all under your authority:

- **Single host** — the entire platform as one composed stack on one machine in your data centre, publishing exactly one port.
- **Sovereign cloud** — the same stack on infrastructure within your jurisdiction, with egress allow-listed or eliminated.
- **Air-gapped enclave** — no internet connectivity at all, with updates and reference data arriving through a controlled, one-way, cryptographically verified import channel.

A platform that cannot run in the third posture was not designed for the first two; it was designed for SaaS and constrained afterwards.

## 3. Sovereign by design: the Project 82 architecture

Project 82 is a data-fusion and decision platform — integrate messy source data into governed, versioned datasets; model it as business objects and links; analyse and act on it with full provenance — built as installable software for the sovereign and regulated mid-market. Its trust architecture is inherited from a proven endpoint-security platform and was not retrofitted; the constraints below are invariants, present from the walking skeleton onwards.

### 3.1 One URL, outbound only

Connector agents — single static binaries installed beside your source systems (databases, file shares, OT historians) — dial **outbound-only, to exactly one HTTPS URL**, over the single published port, 443. Nothing ever connects *into* a customer network segment. Agents survive forward proxies and TLS-inspecting proxies, because the environments that need this platform have them. Even extracted data returns over that same channel as resumable, hash-checked chunked frames: there is no second endpoint, no presigned-URL side door to punch through your firewall.

The consequence for your network team is that onboarding a new source requires precisely one egress rule, and your inbound attack surface from the platform is zero.

### 3.2 Signed work: a compromised control plane still cannot exfiltrate

Every job an agent executes — every sync, every transform order, every writeback — is **Ed25519-signed by the platform key and addressed to that specific agent's device identity**. The agent verifies the signature and the addressing before executing anything. Writeback to source systems is further restricted to allow-listed statement templates; free-form SQL from the server is never executed.

This is defence in depth against the scenario most architectures wave away: what if the control plane itself is compromised? In Project 82, an attacker who owns the control plane still cannot instruct an agent to redirect output to an unpinned destination or run arbitrary commands against your sources. Source credentials never help them either — they are stored on the agent host, in the OS keystore or an encrypted file, referenced by identifier. The control plane never holds or sees them.

### 3.3 The Airlock: air-gapped, not out of date

Air-gapped enclaves still need software updates, reference datasets (sanctions and PEP lists, geographic data, vulnerability feeds for OT customers) and AI model weights. Project 82's answer is the **Airlock**: a single connected appliance that collects, signs and serves bundles, which the enclave pulls over pinned mutual TLS — GET-only, Ed25519-verified before ingest, with monotonic sequencing to defeat replay.

The channel is **architecturally one-way: import only**. Nothing leaves the enclave through it, by construction rather than by policy. If your mission ever requires cross-domain export, that is designed as a separate, human-reviewed appliance with its own approval flow — never the import path run in reverse. And there is no phone-home anywhere in the product: no licence pings, no telemetry, no CDN-loaded assets. Version checks arrive as Airlock bundles like everything else.

### 3.4 Tenancy and governance enforced in the database

Multi-tenancy in Project 82 is enforced by **row-level security in Postgres** — the coarse, non-bypassable layer that scopes every read and write to the tenant and its classification ceiling — with role, purpose-grant and property-level policy evaluated above it. Because the object and link indexes are materialised into the same database, object search inherits these controls natively rather than reimplementing them in application code.

Governance is treated as product, not paperwork: dataset versions are immutable, lineage records every input and transform that produced each version, mutations are audited append-only, and — by design intent — every read of classification-marked data becomes an audit row, with evidence packs exportable for your regulator. The platform's roadmap extends this into purpose-based access requests, classification markings and an on-prem AI assistant grounded strictly in the objects the caller is already entitled to see, running on local models whose prompts never leave the enclave.

### 3.5 Operationally boring, deliberately

Sovereignty fails in practice when the sovereign option needs a vendor's embedded engineers to keep it alive. Project 82 ships as one Docker Compose stack behind a single TLS terminator: one box, one port, one idempotent deploy script, with configuration — sources, pipelines, ontology mappings — declared as versioned code and applied declaratively. The same stack scales from a single host to a sovereign cloud to an enclave with the Airlock overlay added. Even the supply chain reflects the buyer: the shipped stack is permissive-licence only, enforced by CI gates, with third-party notices generated per release — because your procurement team will ask.

## 4. What to demand of any platform vendor

Whether or not you evaluate Project 82, put this checklist in your next RFP. A vendor's answers will tell you quickly whether "sovereign" is architecture or adjective.

1. **Where does the control plane run?** Can orchestration, identity, entitlements and audit run entirely inside our perimeter, with no vendor-side dependency?
2. **What is the complete egress map?** Enumerate every outbound connection, destination and port. The right answer is a very short list; for Project 82's remote agents it is one URL on 443.
3. **What connects inbound to our networks?** The right answer is *nothing*.
4. **Is work cryptographically verified?** If your control plane is compromised, what prevents it from turning our agents against us? Ask specifically about job signing and destination pinning.
5. **Where do source credentials live?** They should remain on our side of the boundary, never in the vendor's control plane.
6. **Can it run fully air-gapped — and stay current?** How do updates, reference data and model weights enter the enclave? Demand signed, verified, one-way import; reject any "temporary connectivity window".
7. **What leaves the enclave?** Telemetry, licence checks, crash reports, "anonymised" usage data — the answer must be nothing, architecturally, not contractually.
8. **How is tenancy and classification enforced?** At the database layer, non-bypassably — or only in application code?
9. **Can we prove what happened?** Immutable data versions, full lineage, append-only audit including reads of marked data, and regulator-ready evidence exports.
10. **Can our own team operate it?** One documented deployment, config-as-code, no embedded vendor engineers as a load-bearing dependency.
11. **Is the supply chain clean?** Licence posture of every shipped component, signed release artefacts, and third-party notices — before contract, not after.

## 5. Closing summary

For regulated and sovereign-sensitive organisations, the question is no longer whether a data platform is capable, but whether it is *yours*: whether the data, the compute, the models and — critically — the control plane operate under your authority, inside your perimeter, answerable to your regulator and no one else's. That property cannot be added to a SaaS product by contract language or a regional data centre. It has to be designed in.

Project 82 was: one outbound URL and no inbound connectivity, Ed25519-signed work orders that survive even a compromised control plane, a one-way Airlock that keeps air-gapped enclaves current without ever letting anything out, row-level tenancy and classification enforcement in the database itself, and an operational footprint of one host, one port, one script. Sovereign by design — because for the organisations Project 82 serves, sovereignty is not a feature tier. It is the point.

---

*Project 82 is a working name. For a technical briefing or an architecture walkthrough, contact ClearPath Partnership Limited.*