Where Data Sovereignty as a Service sits.
Six adjacent categories solve part of the sovereignty problem. None of them solves it the way an architecture can. This is the whole map — rated by category, with an evidence status on every claim we make about ourselves.
We rate categories, not companies.
Every segment below contains vendors doing excellent work, and several of them are partners rather than competitors — national cloud providers are our anchor hosts, governance platforms are our inputs, and confidential computing is a compute target we support. A rating of partial is not a criticism of any product. It describes what a category is architecturally designed to do.
So no vendor is named on this page. That is deliberate, and it is the same argument the product makes: a claim you cannot verify is not worth making. Any specific company can ship a change tomorrow that a page we revised last quarter would misrepresent. The architectural question — can a single operator be compelled to produce plaintext? — is stable, checkable, and the one that actually decides the outcome.
We hold ourselves to the same standard in the other direction. Every SkyeConnex cell carries an evidence status, so shipped work and scoped work are never conflated, and the one row where we rate below the field is left in.
Capability by capability, across the Five Pillars.
Security, legal, residency, portability and algorithmic — the five questions that decide whether sovereignty is real, plus how each category reaches its customers.
| Capability | SkyeConnexData Sovereignty as a Service — a BYOC custody layer | Hyperscaler sovereign offeringsSovereign regions, local operating entities and contractual controls layered on a globally parented platform. | National sovereign cloudsDomestically owned and operated providers, under a single national jurisdiction. | Key management & HYOKCustomer-held keys and external key stores; the data decrypts wherever the application runs. | Distributed & zero-knowledge storageData split and encrypted across independent nodes or clouds, with customer-held keys. | Data governance & DSPMDiscovery, classification and posture management across an existing estate. | Confidential computingHardware enclaves that protect data while it is in use. |
|---|---|---|---|---|---|---|---|
| Pillar 01 · SecurityWho can see it? | |||||||
| Client-side encryptionKeys never leave the customer boundary | Native client path: keys stay inside the client boundary. The S3 gateway path holds a wrapped key and sees plaintext on PUT, disclosed as the compatibility trade-off.Live | Customer-managed keys and external key stores are options; the platform still processes plaintext for its services. | Provider-side encryption by default; client-side is a customer project. | Core purpose. Customer holds keys; applications in the cloud still decrypt to work. | Client-side encryption is standard in this category. | Discovers and classifies; does not hold or encrypt data. | Protects data in use inside an enclave; data at rest is a separate control. |
| Zero-knowledge operatorNo single party can reconstruct the data | Erasure-coded shards plus a zero-knowledge key hierarchy: no host, and not SkyeConnex, can reconstruct a file.Live | Operator has technical access; controls are contractual and procedural. | Single operator with full technical access, bound by domestic law. | Zero-knowledge for keys, not for the data path. | Closest analogue: data split across nodes or clouds with customer-held keys. | Not a custody model. | Trust shifts to the silicon vendor's attestation root rather than being removed. |
| Post-quantum cryptographyML-KEM-1024 (FIPS 203), ML-DSA-87 (FIPS 204) | Post-quantum algorithms across key encapsulation and signatures, by default.Live | Hybrid PQC rolling out at the transport layer; not the default for stored data. | Varies by provider; largely transport-level. | PQC algorithms appearing in HSM roadmaps; customer-selected. | Classical algorithms are the norm. | Not applicable. | Depends on the underlying platform's attestation and TLS stack. |
| Tamper-evident custody recordWho touched what, provable after the fact | SkyeLedger: a company-rooted, hash-chained, ML-DSA-87 signed, omission-evident attestation chain.Scoped | Provider-controlled audit logs. | Provider-controlled audit logs. | HSM and key-use logs; strong for keys, silent on data movement. | Basic access logging. | Access and lineage records for governance, not cryptographically bound. | Remote attestation proves the code, not the data's history. |
| Pillar 02 · LegalWho can seize it? | |||||||
| Compelled disclosureCan any operator be ordered to produce plaintext? | Mathematically impossible for any one operator: each holds shards below the reconstruction threshold, and no key.Live | A foreign parent remains subject to its home disclosure law regardless of region or operating entity. | Outside foreign reach, but fully compellable by the home jurisdiction. | The customer can withhold keys; the key server itself sits in some jurisdiction. | Depends on where nodes and the operator sit; policy is rarely jurisdiction-aware per file. | Maps exposure; cannot prevent it. | Reduces host access; the host still runs the enclave and can be ordered to stop or snapshot it. |
| Jurisdictional separationShard placement set by policy, per file | Shard count and reconstruction threshold are set per file by geopolicy, across independent legal domains.Live | One provider, one legal parent. | One provider, one jurisdiction by design. | Not a placement control. | Multi-cloud placement exists; per-file legal policy generally does not. | Reports on it; does not enforce it. | Not addressed. |
| Pillar 03 · ResidencyWhere does it really live? | |||||||
| Data residency controls | Residency is a policy input; each country's anchor host is domestically owned and bound by domestic law.Live | The category's primary promise. | The category's primary promise. | Key location only. | Region or cloud selection, often coarse-grained. | Discovers where data is; enforcement is elsewhere. | Not addressed. |
| Residency without residency riskLocation does not become the single point of failure | Because no host can read the data, a residency breach is not a data breach.Live | Residency is the control; if it fails, the data is exposed. | Residency is the control; if it fails, the data is exposed. | Encrypted at rest; the key is the residual risk. | Encrypted and distributed; location loss is not data loss. | Not addressed. | Not addressed. |
| Pillar 04 · PortabilityCan you leave — and can they make you? | |||||||
| Bring Your Own CloudWorks over the customer's existing providers | Orchestration, not a cloud. Customers keep their hyperscalers; custody is layered on top through an S3-compatible gateway (SkyeBucket).Live | Is the cloud; moving in means moving. | Is the cloud. | Multi-cloud key control, not data placement. | Some are multi-cloud overlays; some run their own networks. | Connects to many clouds for visibility. | Runs on supported hardware in supported clouds. |
| Exit and continuityCan data be recovered without the vendor? | Escrow sits with the anchor host in each country; recovery tooling reassembles data without SkyeConnex, and a shard node can be reconstituted on another provider from surviving shards.Live | Export tooling exists; egress and format lock-in are the customer's problem. | Open-standards leaning, but still a migration. | Keys are portable; data lives wherever it lives. | Retrieval depends on the vendor's network or gateway staying up. | Not applicable. | Not applicable. |
| Standard interfacesS3, file system, mail | SigV4-compatible S3 gateway (verified with MariaDB, DuckDB, ClickHouse and MASV), Windows virtual drive, Outlook add-in.Live | Full native APIs. | S3-compatible object storage is standard. | KMIP and cloud KMS integrations. | S3-compatible is the norm. | Connectors, not a data path. | Container and VM level. |
| Pillar 05 · AlgorithmicWhat's learning from it? | |||||||
| AI on custody objectsTraining and inference inside the customer boundary | SkyeGXU: shards reassemble only inside the client boundary, federated agents run on customer-owned hardware, and outputs are written back into custody. Governed distributed AI, running since 2025.Live | Strong AI stacks, but data is processed by the provider under contract. | Domestic GPU capacity; the same single-operator exposure. | Not addressed. | Storage only. | Governs what AI may access; does not run it. | Confidential AI inside enclaves is a core use case, on the enclave vendor's terms. |
| Policy-bound workloadsModels and encoders registered as governed adapters | Workloads packaged as signed adapter blobs — image hash, I/O contract, resource ask — bound per collection. Sits under existing analytics platforms and notebooks rather than replacing them.Scoped | IAM and model governance within the provider's own stack. | Not addressed. | Not addressed. | Not addressed. | AI governance policies, enforced elsewhere. | Attested workload identity, with no data-policy binding. |
| Operating modelHow it reaches customers | |||||||
| Route to market | OEM-first and channel-first: one domestically owned anchor host per jurisdiction, MSP marketplaces and ISV embeds. Partners set end-customer pricing. | Direct, plus a partner ecosystem. | Direct, plus regional partners. | Enterprise direct and channel. | Mostly direct; some MSP channel. | Enterprise direct. | Direct and cloud marketplaces. |
| Independent cryptographic audit | Internal automated security and penetration suite in place. A third-party cryptographic audit is a named use of funds — not yet done.Planned | Extensive certifications are the norm. | National certification schemes and ISO. | FIPS 140-3 validated hardware. | Varies widely by vendor. | SOC 2 / ISO typical. | Relies on hardware vendor validation. |
Why each category is not a substitute.
The one-paragraph version of each column, for the reader who wants the reasoning rather than the dots.
Hyperscaler sovereign offerings
Residency and operations controls layered on a globally parented platform. They matter, and we expect customers to keep using them. What they cannot do is remove the operator's technical access or the parent's legal exposure — which is precisely the layer SkyeConnex adds on top. Complement, not competitor.
National sovereign clouds
Solve the foreign-law problem by moving to a domestic operator, then recreate the single-operator problem under domestic law. We treat this segment as anchor hosts: each holds shards it cannot read, and the domestic partner becomes the route to market rather than a rival.
Key management & HYOK
Excellent at proving the customer owns the key. The data still decrypts wherever the application runs, and the key server has an address. SkyeConnex extends key custody into data custody: even with the key, no single party holds enough shards to reconstruct.
Distributed & zero-knowledge storage
The nearest mechanism, and the right instinct — split and encrypt across nodes or clouds. The differences are policy and reach: per-file geopolicy that sets shard placement by legal domain, post-quantum defaults, a tamper-evident custody ledger, and an AI substrate that computes on custody objects rather than treating storage as the end of the story.
Data governance & DSPM
Answers “what do we have, and where is it exposed.” An indispensable input to a sovereignty policy and a natural integration partner — but discovery is not custody. It tells you the door is open; it does not lock it.
Confidential computing
Protects data in use by moving trust from the cloud operator to the chip vendor's attestation root. Genuinely useful for the compute step, and compatible with SkyeGXU as a hardened compute target. It does not address where data rests, under whose law, or whether it can leave.
What is shipped, what is scoped, what is funded.
The honest version of a roadmap. Hold us to this list — and ask for the documentation behind any row of it.
| Capability | Status | Evidence |
|---|---|---|
| Raidr.cloud custody engineClient-side encryption, dynamic erasure coding, zero-knowledge key hierarchy | Live | In production. Per-file coding parameters set by geopolicy. Whitepaper v1.3 and API documentation available under NDA. |
| SkyeBucket S3-compatible gateway | Live | In production. Interoperability confirmed with MariaDB, DuckDB and ClickHouse; MASV is the first third-party gateway integration. |
| Post-quantum cryptographyML-KEM-1024 (FIPS 203), ML-DSA-87 (FIPS 204) | Live | Default across key encapsulation and signing. |
| SkyeGXU governed distributed AIOn customer hardware | Live | Running since 2025. NVIDIA PAIR-compatible routing; v3 adapter-blob packaging in additive rollout. |
| Multi-jurisdiction anchor host network | Live | Canada anchored on a domestically owned OEM host. Additional hosts and jurisdictions onboarding. |
| Standards mapping | Live | DGSI 100-8:2026 clause-by-clause conformance map. Sovereignty Risk Register crosswalked to ISO 42001, NIST AI RMF and the EU AI Act. |
| Intellectual property | Live | Two 2026 provisional filings (69 claims) covering data custody and the ML lifecycle, plus five earlier granted patents. |
| SkyeLedger custody attestation chain | Scoped | Architecture and specification complete. |
| Company-rooted threshold key custody (CRKC) | Scoped | Fully architected; roughly 34 engineer-weeks estimated. |
| Independent third-party cryptographic audit | Planned | A named use of funds in the current raise. Internal automated security and penetration suite already in place. |
Bring us the row you doubt.
The most useful briefing is the one where you arrive with a cell you think is wrong. We will show you the architecture behind it, or correct the page.