For a growing class of organisations — critical infrastructure, defence, aviation security, regulated industry — the question about any new platform is no longer just "what does it do?" but "where does my data go, who can reach the system, and what happens if the vendor disappears?" Sovereignty has moved from procurement footnote to design requirement.
ClearPath builds products for exactly these environments: Apex Vantage, a sovereign, cross-platform endpoint security and AI platform, and Tessara, a sovereign data-fusion and decision platform currently in development. This paper sets out the design principles behind them — and what to demand from any vendor claiming "sovereign".
What sovereignty actually means
Sovereign software is software you can run entirely within your own perimeter: your data stays on your infrastructure, the intelligence that processes it runs on your hardware, and the vendor's cloud is not a dependency for daily operation. It is the opposite of the SaaS default, where capability is rented and data is exported. Neither model is universally right — but for environments where data leaving the network is a breach by definition, sovereignty is the entry ticket.
Principle 1: Data never leaves
Analytics, search, correlation and AI inference all run inside the customer's environment. If a capability requires shipping your data to someone else's cloud, it is not sovereign — however the marketing reads. This extends to AI: a sovereign platform runs its models on-premises, so the questions you ask of your own data are themselves never exported.
Principle 2: Outbound-only, single-URL connectivity
Every remote component should need nothing more than outbound HTTPS to a single, controllable endpoint — no inbound connectivity, no firewall exceptions, proxy-safe by default. This one constraint eliminates entire classes of attack surface and makes deployment tractable in networks where inbound ports simply will not be opened.
Principle 3: Air-gap capable, not air-gap crippled
The strictest environments run fully disconnected. A sovereign platform should function in an air-gapped enclave, with updates and data arriving through one-way, cryptographically signed transfer — and it should be the same product, not a diminished "offline edition".
Principle 4: Simple enough to actually operate
Sovereignty fails in practice when the on-premises stack needs a vendor engineering team to keep it alive. Designing the whole platform to run as a single, compact stack on one host — rather than a sprawling microservice estate — is what makes self-hosting real for organisations that are not hyperscalers.
Principle 5: A supply chain you can audit
Sovereignty extends to the software's own composition: permissively licensed dependencies, enforced automatically in the build pipeline, and signed artefacts end to end. If you cannot audit what is running inside your perimeter, the perimeter is doing less than you think.
Questions to ask any "sovereign" vendor
- Does any of our data — including telemetry and AI prompts — ever leave our network? Prove it.
- What inbound connectivity do you require? (The right answer is none.)
- Can the platform run fully air-gapped, and how do signed updates arrive?
- How many hosts and specialist engineers does the on-premises stack really need?
- Can we audit your dependency licences and artefact signatures?
Consulting meets product
These principles come from delivery, not theory — years of putting systems into airports, critical infrastructure and security operations shaped what we build. The same engineering capability behind Apex Vantage and Tessara is available to clients through our product development services.
Closing thoughts
“Sovereignty is an architecture decision, not a deployment option — if the control plane, the data and the AI weren't designed to live inside your perimeter, no amount of configuration will put them there. That principle shapes everything we build.”
Gareth Wilson · Founder and Co-CEO
“For clients in security-conscious sectors, sovereignty is increasingly a procurement requirement, not a preference. Asking the questions in this paper early — before contract signature — is the cheapest risk mitigation available.”
Phil Moss · Founder and Co-CEO
Talk to the people who did the work. If the challenges in this paper look like yours, we'd be glad to share more of what we've learned — and how it could apply to your organisation.
Get in touch