Sovereign deployment means the platform, its data, and the ability to access that data all stay under a single jurisdiction's legal and operational control, so no foreign law or foreign operator can compel access. For software supply chain security, that translates to running inside a national or regional boundary, on infrastructure and keys the customer or an in-jurisdiction entity controls. Safeguard supports this through dedicated single-tenant, on-premise, and fully air-gapped deployments with customer-controlled keys and offline data sync. This FAQ explains what sovereignty covers, what it cannot, and how to achieve it without hand-waving.
Frequently Asked Questions
What does "sovereign" mean beyond just "data stays in-region?" Data residency puts data in a region; sovereignty adds control over who can operate and legally access it. True sovereignty means the compute, the storage, the encryption keys, and the operational access are all governed by your jurisdiction's law, so a foreign entity cannot lawfully compel disclosure. Region choice alone does not achieve this if a foreign-owned operator still holds the keys or the access.
How does Safeguard support sovereign requirements? Through deployments where you hold the keys and control the environment: a dedicated single-tenant instance in your chosen region, an on-premise install in your own datacenter, or a fully air-gapped deployment. The stronger your sovereignty requirement, the further toward on-prem or air-gapped you move. In those tiers the operator with physical and cryptographic access is you, not us.
Who holds the encryption keys in a sovereign deployment? You do, through your own KMS or HSM, so that key material never leaves your jurisdiction or your control. Because we cannot decrypt data we hold no keys for, a compulsion order served on Safeguard cannot produce your plaintext. This is the cryptographic foundation of the sovereignty claim, not a contractual promise.
Does the AI engine keep analysis within the sovereign boundary? Yes. Griffin AI runs on locally hosted model weights inside the deployment boundary, so reachability and exploitability analysis never call an external model endpoint in another jurisdiction. Your code and findings do not cross a border for inference. This matters because model APIs are a common hidden leak of sovereignty.
Can a sovereign deployment stay current on vulnerability data? Yes. A connected dedicated or on-prem instance pulls signed advisory bundles inbound only, and an air-gapped instance imports them from signed media you carry across the boundary. Either way, only advisory data flows in; nothing about your code flows out. You control the update cadence and the path.
Does the platform address concerns about foreign-government access laws? The deployment model is designed so that access laws applying to the vendor cannot reach your data, because in the sovereign tiers we do not hold your keys, ciphertext, or an operational path to your environment. To be precise and honest: this is an architectural property, and whether it satisfies a specific national framework is a determination your legal team makes against that framework. We give you the technical basis; we do not adjudicate the law.
Which ecosystems and scanning are available in sovereign deployments? The same as everywhere else. Software composition analysis, CycloneDX and SPDX SBOM generation, container scanning, and infrastructure-as-code scanning all run identically inside the sovereign boundary. Sovereignty changes where and by whom the platform is operated, not what it can scan.
Is a multi-tenant cloud ever sovereign? Not in the strict sense, because shared infrastructure and a single global operator undercut the "no foreign access" property even with regional data storage. For genuine sovereignty, choose a dedicated single-tenant, on-prem, or air-gapped deployment. Be skeptical of any vendor calling a shared multi-tenant SaaS "sovereign."
How does sovereign deployment relate to FedRAMP and IL requirements? The sovereign tiers share the same architecture we build toward FedRAMP HIGH and DoD Impact Level control sets, and SOC 2 Type II is in progress. Honestly stated: "built toward" and "in progress" are not "authorized," and government sovereignty programs have their own accreditation paths that depend on your environment. The compliance overview sets out what is certified versus underway so you can plan accordingly.
Can an in-country partner or integrator operate the deployment? Yes. Because on-prem and dedicated deployments run in infrastructure you designate, an in-jurisdiction integrator or your own team can operate them, keeping operational control local. Safeguard provides the software and support; the operating hands can be entirely domestic. This is often the deciding factor for public-sector sovereignty.
What are the honest limits of sovereignty here? Sovereignty is about your data and access, not about the software's origin: the platform is still built by Safeguard, and the update bundles originate from us even when you carry them in. If your framework requires domestically developed software, that is a supply-chain-of-the-tool question we are transparent about rather than one deployment alone solves. We would rather state that plainly than overclaim.
How do I choose between sovereign options? Map your requirement to the strongest constraint: connected dedicated for region and single-tenancy, on-prem when the environment must be yours, air-gapped when no connection may exist at all. The deployment comparison walks through each, and the pricing is quoted per tier since these provision or support dedicated environments. See pricing for the structure.
To scope a sovereign deployment, review the software composition analysis and Griffin AI capabilities, confirm what is certified on the compliance page, weigh the tiers on the deployment comparison, and contact our team for a jurisdiction-specific scoping session. Full documentation is at https://docs.safeguard.sh.