Security ≠ Sovereignty
Part of the Sovereign AI analyst series. A field guide to the security vendors weaponizing the datacenter attack surface to sell you sovereignty — how to tell the pillar from the paint, and what to actually build instead.
There is a specific move happening in the AI infrastructure market right now, and once you see it you cannot unsee it. A security vendor identifies a genuine, technically real vulnerability in the AI datacenter — usually the exposure of data while it is being processed on shared GPUs — ships a legitimately useful product to address it, and then, in the same breath, reaches for a word that does not belong to it. That word is sovereignty.
The pitch has become almost liturgical. Confidential computing plus attestation equals “sovereign AI.” A trusted execution environment on a Blackwell GPU equals “self-sovereign AI.” An encrypted VRAM demo equals a nation’s “AI independence.” The Confidential Computing Summit — a fine technical conference — now bills its 2026 program as showcasing “the next era of AI Sovereignty.” The category has produced its own market-sizing reports, its own coined verbs (“geopatriation”), and its own $15 billion forecast, all resting on a conflation that deserves far more scrutiny than it is getting.
So let me be direct about the thesis of this piece, because the rest of it is an argument for the claim: security is a necessary pillar of AI sovereignty, but it is nowhere near sufficient, and a large and growing number of vendors are exploiting one narrow attack vector to market a single security control as if it were the whole of sovereignty. Confidentiality is not control. Encryption is not jurisdiction. Attestation is not independence. When a vendor sells you the first and invoices you for the second, that is not sovereignty. That is window dressing with a compliance logo on it.
This matters because sovereignty is real, it is strategic, and it is expensive. Governments are committing material public investment to it — the CNAS Sovereign AI Index counts national initiatives across infrastructure, models, and data, with roughly 59% of tracked projects concentrated in infrastructure alone. When the word gets cheapened into a security feature checkbox, buyers make a category error that costs them the very thing they were trying to buy. They think they have purchased autonomy. They have purchased an enclave. The good news — and this is where the piece is going — is that the real thing is buildable today, and I will lay out exactly how.
The attack vector doing all the work
Every good marketing narrative needs a real fear underneath it, and this one has a legitimate one. Here is the honest version of the problem the vendors are pointing at.
To run inference or training, sensitive data has to be decrypted somewhere. It sits encrypted at rest on disk and encrypted in transit over the wire, but the moment a GPU actually computes on it, that data exists in cleartext in accelerator memory. On a modern AI datacenter — a multi-tenant GPU cloud, a “neocloud,” a shared AI factory — that cleartext lives on hardware you do not own, administered by operators you do not employ, alongside workloads you cannot see. This is the “data-in-use” gap, and it is a real gap. A privileged administrator, a compromised hypervisor, a firmware implant, or a failure of tenant isolation could, in principle, expose personally identifiable data, healthcare records, financial transactions, or classified material at the exact moment it is most valuable and least protected.
The technical answer to this specific problem is genuinely elegant: confidential computing. You establish a trusted execution environment (TEE) that keeps data encrypted even in memory, you cryptographically attest that the hardware and software stack are what they claim to be, and you gate the release of decryption keys on that attestation passing. NVIDIA has built this into Hopper and Blackwell; Intel TDX and AMD SEV-SNP do it on the CPU side; the attestation ecosystem (Intel Trust Authority and others) verifies it. Done well, it closes a category of insider and infrastructure attacks that used to be simply unaddressable. This is good engineering solving a real threat. I want to be unambiguous about that, because the critique that follows is not “confidential computing is snake oil.” It emphatically is not.
The critique is what happens next. Having solved data-in-use confidentiality on shared hardware, the marketing department reaches for sovereignty — a word about national and organizational control, not about confidentiality. Those are different axes. And the slippage between them is where the window dressing lives.
Calling out names
I am naming vendors here not to single any one of them out as uniquely guilty — most ship real products — but because the pattern is only visible when you see how many firms are running the identical play at once. Read these claims with one question in mind: does the thing being sold actually confer control, or merely confidentiality?
Fortanix, in its October 2025 launch with NVIDIA, announced “a turnkey, on-premises platform for running secure and sovereign, agentic AI in AI Factories and highly regulated environments,” explicitly invoking “data sovereignty.” What it actually ships is excellent: composite attestation across CPUs and GPUs, attestation-gated key release, a FIPS 140-2 Level 3 HSM, on Hopper and Blackwell. Every one of those is a confidentiality-and-integrity control. None of them, by itself, answers who holds legal authority over the workload.
OPAQUE‘s CEO Aaron Fulkerson puts it most plainly: “Confidential computing and Confidential AI are becoming foundational infrastructure for secure, sovereign AI at scale.” Super Protocol, in a co-authored NVIDIA technical blog, brands its confidential-computing approach as “self-sovereign AI.” VoltageGPU markets “Confidential AI Agents on Intel TDX” as a “Sovereign GPU Cloud,” and publishes a “State of Confidential AI 2026” report projecting the market from $9.31B to $15.15B at a 62.7% CAGR, complete with the neologism “geopatriation.” Prem “launches Enclave for secure sovereign AI clusters.” Phala and Corvex ride the same confidential-AI wave — Corvex among the first to reach verified production confidential computing on NVIDIA HGX B200 — and while their claims are more carefully scoped to confidentiality, they swim in the same rebranded current. Squirro frames “Sovereign AI” as fundamentally “solving the compliance problem.”
And it is not only the startups. The Confidential Computing Summit 2026 markets its entire program as “the next era of AI Sovereignty,” with keynotes from Microsoft (Mark Russinovich), Google Cloud (Nelly Porter), and AMD (Hugo Romero, who frames confidential computing as addressing “data sovereignty and risk mitigation”). The hyperscalers — the very U.S.-parented entities whose jurisdictional reach is the reason sovereignty is a live concern in Europe and the Gulf — are among the loudest to attach the word to a memory-encryption feature. There is a particular irony in a company subject to the U.S. CLOUD Act selling “sovereignty” whose mechanism is a key it can still be compelled to help unlock.
That irony is the whole ballgame, so let us make it precise.
Why confidentiality is not sovereignty
Sovereignty, stripped to its core, is the ability to exercise control under adversarial conditions — specifically, the ability to keep operating, and keep others out, when a powerful external party (a foreign government, a foreign-headquartered vendor, a sanctions regime) would prefer otherwise. It is a question about who can compel, who can revoke, who can see, and who can shut you down. Confidential computing answers exactly one of those questions (“who can see”) and only partially, and only if a set of other conditions — conditions the marketing rarely mentions — happen to hold.
Here is the test that cuts through it. Ask what changes if the vendor’s home government issues a lawful order tomorrow. If a confidential-computing platform is operated by a U.S.-parented provider, holds or brokers the attestation service, and can be compelled to modify the attestation policy, push a firmware update, or release keys under a court order or national-security letter, then the encryption in memory is not protecting you from the party you were most worried about. As the “missing middle” analysts put it bluntly: “A data center in Frankfurt operated by a US-parented company still answers to the US CLOUD Act.” The GPU memory can be perfectly encrypted and the sovereignty can still be zero, because sovereignty was never a property of the memory. It was a property of the control plane and the jurisdiction.
This is why the sharpest voices in the sovereign-cloud debate keep returning to control, not confidentiality. The three questions that actually separate real sovereignty from “sovereign washing” are: Where does the data physically reside? Can the provider guarantee legal insulation from foreign jurisdictions? Is there true operational independence from foreign-controlled control planes or APIs? Note that not one of those three is answered by a TEE. “Sovereignty is not a logo,” as the critique goes, “and trust can’t be marketed.” A memory-encryption feature is closer to a logo than its sellers would like to admit.
There is a second, subtler failure. Confidential computing defends the confidentiality and integrity of a workload against the infrastructure it runs on. It does nothing for availability — and availability is the sovereignty attack vector that the security-vendor pitch conveniently ignores. Researchers at the University of Maryland and Sandia National Laboratory have made the point that frontier AI datacenters are fixed, locatable, resource-hungry targets that “an adversary can locate, measure, and degrade.” When Iran targeted Amazon datacenters in the UAE with drones in March 2026 and subsequently named U.S. technology firms as possible military targets, no amount of encrypted VRAM was relevant. Data poisoning during training, supply-chain compromise of accelerator chips, intrusions into cooling and power control systems, information operations against the communities hosting the sites — these are sovereignty-relevant threats, and confidential computing addresses precisely none of them. A vendor that sells you a TEE and calls it sovereignty has not just overclaimed; it has quietly narrowed your definition of the problem to the one slice it happens to sell.
The Sovereignty Litmus Test
If security marketing has taught buyers to accept “encrypted therefore sovereign,” the antidote is a test that a memory-encryption feature cannot pass on its own. Here is the one I use. A claim earns the word “sovereign” only when it can answer all five of these, not one. The table below scores confidential computing on its own against each — the pattern is unmistakable.
| Dimension | The question it answers | Does confidential computing satisfy it alone? |
|---|---|---|
| 1. Jurisdictional control | Who can lawfully compel access, and which flag are they under? Are you insulated from foreign extraterritorial law (e.g. the CLOUD Act)? | No — a TEE does not change whose court order the operator must obey. |
| 2. Operational independence | Who runs the control plane, holds root, and pushes firmware and attestation policy? Can they be directed from abroad? | No — whoever controls attestation policy and updates controls the enclave’s meaning. |
| 3. Key custody | Who ultimately holds, escrows, or can be compelled to release the keys? Are they held outside the vendor’s jurisdiction? | Partial — only if YOU hold keys in your own jurisdiction, which is not the default in most managed offerings. |
| 4. Supply-chain provenance | Who controls the hardware, firmware, and model supply path, and can it be embargoed or backdoored upstream? | No — attestation verifies a known-good state; it does not give you control of the supply that defines “good.” |
| 5. Continuity & revocation | Can a foreign vendor or government degrade, throttle, or switch you off — through licensing, updates, or physical disruption? | No — confidentiality is silent on availability, the most kinetic sovereignty risk of all. |
The scoring is deliberately unforgiving. Confidential computing, deployed well, contributes meaningfully to dimensions 2 and 3 and can be part of a genuinely sovereign architecture. But a product that satisfies only “who can see the data” and leaves the other four to the vendor’s home jurisdiction has met one-and-a-half of five tests. Selling that as sovereignty is selling one-and-a-half fifths of a castle as the castle.
Where security genuinely is a pillar of sovereignty
None of this is an argument that security is peripheral to sovereignty. It is a pillar — a load-bearing one. The argument is that it is a pillar, not the roof, and that honest security work is scoped as security, not smuggled in as sovereignty.
The cleanest illustration of the honest version is a framework built explicitly for this layer: FORGE (forge-framework.io), a practical security framework for AI infrastructure and datacenters. Its premise is a sentence the whole industry should sit with: “AI datacenters are being built faster than they are being secured.” FORGE evaluates risk across five domains — Fleet Integrity (trust in hardware, firmware, and supply paths), Operations & Management Planes (the privileged systems that administer infrastructure), Resource Isolation (the boundaries between tenants and workloads), Grid (networking fabric and facility systems), and Evidence & Exposure Management (customer visibility into a provider’s security maturity and patch velocity).
Now watch what happens when you map the confidential-computing sovereignty pitch onto that. A TEE with attestation lands squarely in Resource Isolation, and touches Fleet Integrity through attestation of firmware and artifacts. That is roughly one-and-a-half of five security domains — and FORGE is itself scoped to security, deliberately excluding the sovereignty and geopolitical questions entirely. So the vendor selling “TEE equals sovereignty” is offering you a fraction of one honest security framework and relabeling it as a strategic-autonomy guarantee that sits above the entire framework. The gap between what is sold and what is claimed is not a rounding error. It is most of the map.
What FORGE gets right — and what the sovereignty-washing vendors get wrong — is scope discipline. It says: here is the security of the infrastructure layer, here are the top risks, here is how a buyer can assess a GPU cloud or neocloud, and here is where our remit ends. That honesty is exactly what lets security be a credible pillar of sovereignty. A national or organizational sovereignty posture needs strong Fleet Integrity so that hardware and firmware cannot be backdoored upstream; it needs Operations & Management Plane control so that root does not sit in a foreign jurisdiction; it needs Resource Isolation so that co-tenants and operators cannot reach the workload; it needs Grid resilience so the facility survives disruption; and it needs Evidence so that the sovereignty claim is auditable rather than asserted. Security done at that breadth genuinely underwrites sovereignty. Security sold as one encrypted memory region, wearing sovereignty’s clothes, undermines it — because it convinces the buyer the box is checked when four of the five load-bearing questions are still open.
The way out: own the stack, don’t rent the sovereignty
So what do you actually do about it? If the problem is that a foreign-controlled control plane, license, and jurisdiction sit underneath your “sovereign” AI, then no amount of additional encryption fixes it — because the defect was never confidentiality. The answer is ownership. Concretely, that means owning three important layers that actually constitute an AI capability: compute, intelligence, and inference. Not encrypting someone else’s version of them — owning your own.
Open weights are the intelligence pillar’s answer. The last two years have made open-weight models — the Llama, Mistral, Qwen, DeepSeek, and gpt-oss families among them — good enough that a very large share of real enterprise and government workloads no longer require a proprietary frontier API at all. This is the single most underappreciated fact in the sovereignty debate. An open-weight model you host yourself is a model no foreign vendor can throttle, deprecate, price-gouge, or switch off; it passes the continuity-and-revocation test (dimension 5) that a TEE fails outright, because you hold the weights. Pair it with an open-source serving, orchestration, and governance stack — no proprietary runtime, no hidden dependency, substitutable components you can swap across models and vendors — and the operational-independence and supply-chain dimensions (2 and 4) begin to close as well.
Your own infrastructure is the compute and inference answer. Run that open stack on infrastructure you actually control — on-prem GPU, a sovereign colocation, or capacity you operate under keys you generate and hold — and you have answered jurisdiction and key custody (dimensions 1 and 3) in the only way that survives a lawful order issued to a foreign vendor: there is no foreign vendor in the loop to compel. This is the difference between confidentiality and control, restated as an architecture. Where confidential computing protects your data on someone else’s stack, owning open weights on your own stack removes the someone else. Do both — own the stack and harden it with confidential computing where it genuinely helps — and now the TEE is doing honest work as one control among five, instead of impersonating the whole.
The catch — and it is a real one — is that this is hard to build. The models are open; the last mile is not. Standing up a sovereign stack means reference architecture, integration into the systems you already run, evals and governance, security hardening across all five FORGE domains, and the unglamorous Day-2 operations that keep it alive in production. Most organizations do not have that muscle in-house, and building it from zero is slow precisely when the strategic clock is loudest. This is where forward-deployed engineering earns its place: not a vendor who hands you a license and a slide, but a partner who embeds, architects, and operates the stack inside your perimeter — and then hands you the keys, literally and figuratively.
Full disclosure, since I would rather state my bias than hide it: this is the thesis my own firm, Agentcy Labs, was built to execute — sovereign agentic AI that runs on your infrastructure, under your control, on an open-source-first, swap-friendly stack, with the forward-deployed engineering to carry it from reference architecture to Day-2 operations. I am not a neutral observer here. But the strategic point stands entirely independent of who does the implementing: sovereignty is something you own, layer by layer — compute, intelligence, and inference to name a few — not something you buy pre-encrypted. The organizations that will genuinely have it three years from now are the ones building that ownership today, not the ones who bought a TEE and a logo.
A buyer’s field guide
If you are procuring “sovereign AI” infrastructure this year, here is how to keep the pillar and reject the paint. Put these questions to any vendor that uses the word:
On jurisdiction: Under whose law does your parent entity operate, and can you be compelled by a foreign government to assist access to my workload, keys, or attestation policy? If the honest answer involves the CLOUD Act or an equivalent, the sovereignty claim is capped there regardless of the cryptography.
On the control plane: Who holds root on the management plane, who can push firmware and attestation-policy updates, and can that authority be exercised from outside my jurisdiction? A sovereign posture requires that the answer be “no.”
On keys: Do I hold and generate my own keys in my own jurisdiction, or do you hold, broker, or escrow them? “Attestation-gated key release” is only sovereign if the party gating it is me.
On the model: Am I dependent on a proprietary model behind an API you or a foreign vendor control, or can I run open weights I host myself? If the intelligence layer can be revoked by someone else, the sovereignty ends there.
On the full attack surface: Show me how your offering addresses availability, supply chain, and operational-plane compromise — not only data-in-use confidentiality. If the answer is “that is out of scope,” that is fine and honest — but then do not call it sovereignty.
On evidence: Can you produce independent, auditable attestations of all of the above, or am I taking the sovereignty claim on the strength of a press release? Sovereignty that cannot be audited is branding.
The bottom line
The security industry has found in “sovereign AI” a phrase with enormous pull — it carries the weight of national interest, regulatory anxiety, and geopolitical urgency, and it attaches beautifully to a real and fundable technical problem. That is precisely why it is being overused. Confidential computing is one of the more important advances in datacenter security in a decade, and the vendors building it deserve credit for solving the data-in-use problem. They do not deserve to redefine sovereignty down to the size of the problem they solved.
Sovereignty is control under adversarial conditions: jurisdiction, operational independence, key custody, supply-chain provenance, and continuity. Security — done at the honest breadth of something like FORGE, not the width of a single memory-encryption feature — is a genuine and necessary pillar of that structure. But a pillar is not a building, and a feature is not a pillar. The path to the real thing is not a better enclave on rented infrastructure; it is owning your stack — open weights, open source, your compute, your keys — with the engineering discipline to operate it. The next time a vendor tells you their TEE makes you sovereign, run the five-question test. If it answers only “who can see the data,” you have found the window dressing. The sovereignty is still for sale somewhere else — and it is built, not bought.
In the next installment of the series: what a genuinely sovereign AI reference architecture looks like across all five FORGE domains — and the three places where today’s neoclouds are quietly conceding sovereignty they claim to protect.
Sources
Forge Framework — forge-framework.io
Agentcy Labs — sovereign agentic AI on your infrastructure — agentcylabs.com
Fortanix + NVIDIA confidential computing launch — Businesswire, Oct 2025
Confidential Computing Summit 2026 — “Next Era of AI Sovereignty” — Linux Foundation
Super Protocol — “self-sovereign AI” with NVIDIA Confidential Computing — NVIDIA Technical Blog
VoltageGPU — “Sovereign GPU Cloud” / State of Confidential AI 2026 — VoltageGPU
Prem launches Enclave for “secure sovereign AI clusters” — SecurityBrief
Corvex verified confidential computing on NVIDIA HGX B200 — PR Newswire
“Cloud Washing in the Age of AI: When ‘Sovereign’ Isn’t” — The New Stack
“AI sovereignty makes data centers strategic targets” (U. Maryland / Sandia) — Help Net Security
“The Neglected Security Gaps in the Global Race for Sovereign AI” — World Politics Review
Sovereign AI Index — CNAS
“The Missing Middle of Sovereign AI” — Spectro Cloud
NVIDIA AI Security with Confidential Computing — NVIDIA
