Solutions portfolio
Products built on the Canopy foundation.
Canopy provides the universal interface layer. SovereignTEE Ltd packages it into deployable products that solve specific trust, sovereignty, and integration problems.
The shared foundation
Every SovereignTEE product is built on the same principle: service interfaces defined once in Canopy IDL, generated consistently at each boundary, and bindable to hardware evidence where policy requires it. The products differ in which trust problem they solve, not in their underlying architecture.
Interface contracts are the source of truth — not documentation, not convention. Where trust matters, TEE attestation lets a relying party verify the workload and bind that decision to a protected route. C++ services, generated browser clients, and supported external runtimes share the same contract across the transports configured for a deployment. See Canopy's remote-attestation capabilities.
Layer 7 Gateway Customer deployment
A policy-enforced application gateway that understands service interfaces, not just URL routes.
Conventional API gateways operate on HTTP verbs and URL patterns. They can route
POST /inference/generate but they cannot distinguish a safe read-only call from
a sensitive compute call on the same service — because that distinction lives in the interface
contract, not the URL.
The SovereignTEE L7 gateway operates on the Canopy IDL layer. Policy is expressed in terms of interfaces and methods: which callers may invoke which methods, under what conditions, and whether the call must originate from or terminate in an attested enclave. The gateway's policy enforcement itself runs inside a TEE, so its behaviour is hardware-attested by both the service operator and the caller.
Where this applies
- Multi-tenant platforms Enforce per-tenant method-level permissions without modifying the service implementation.
- Regulated services Demonstrate to auditors that only attested, policy-compliant calls reach sensitive compute.
- Zero-trust architecture Combine attested routes with method-level authorization at sensitive service boundaries.
- Cross-organisation integration Expose a narrow attested subset of your service catalogue to partners without opening internal infrastructure.
Honest Broker Customer deployment
A neutral trusted intermediary for data exchange between parties who cannot expose raw data to a common operator.
Many valuable data problems require multiple parties to contribute data they cannot share with each other. A hospital network cannot share patient records with a research institution even for anonymised analysis. A bank cannot share transaction history with a fraud consortium without exposing customers. A supply chain consortium cannot share margins with a shared analytics platform without revealing competitive information.
The honest broker runs inside a TEE. Each contributing party independently attests the broker's workload before sharing data — verifying that its identity and security state match the agreed policy. The broker is "honest" not because of a contract or a reputation, but because the code receiving the data can be cryptographically identified before a protected session is opened.
Where this applies
- Healthcare analytics Compute aggregate statistics across patient populations from multiple providers without sharing records.
- Financial reconciliation Reconcile positions between counterparties without revealing individual books to each other or the operator.
- Supply chain verification Attest provenance claims across a supply chain without exposing each participant's costs or suppliers.
- Privacy-preserving ML Train or evaluate models on combined datasets from multiple data owners without pooling the raw data.
Hardware-attested DRM
Content protection where enforcement is hardware-attested, not software-promised.
Conventional DRM systems enforce usage rules in software that runs on hardware the content consumer controls. Given enough motivation, software protections can be reversed or bypassed. The harder the protection, the more friction for legitimate users — an unsatisfying trade-off.
Hardware-attested DRM moves the enforcement boundary into a TEE. Decryption keys are only released to enclaves running code that the rights holder has attested. The machine operator — including a cloud provider — cannot extract protected content even with full OS access. The attacker cannot win by controlling the machine, because the machine's TEE enforces the rules independently of the OS.
Where this applies
- AI model protection Distribute model weights for inference without exposing them. Weights are decrypted inside the TEE and never leave it.
- Premium content distribution Stream or deliver content with usage rules enforced in hardware rather than in a reversible software layer.
- Software licensing Tie software execution to attested hardware and code identity rather than to licence keys that can be copied.
- IP protection in distributed pipelines Process sensitive assets — financial models, drug compounds, proprietary algorithms — in third-party infrastructure without exposing them to the operator.
Building something that fits this space?
These products are delivered around the customer's trust boundary, policy, platform, and operating model. If your use case requires confidential computation or cross-organisation data exchange, talk to us about the deployment profile.