Is cloud data sovereignty all just a case of ‘Trust me, bro’?

Summary

<p>In the UK, giant cloud providers – Amazon Web Services (AWS), Google Cloud and Microsoft – run the systems we depend on for vital functionality in the public and private sectors.&nbsp;</p> <p>In the public sector alone, US hyperscale cloud providers have near-universal penetration and account for the bulk of technology spending.&nbsp;</p> <p>In the financial year 2023/2024, 95% of central and local public sector organisations in the UK spent budget on hyperscale cloud services across more than 1,100 public sector bodies, including government departments, councils, police forces and NHS organisations, <a href="https://www.computerweekly.com/feature/This-rise-of-the-splinternet-Data-sovereignty-risks-and-responses">according to data that comes from analyst Tussell</a>.</p> <p>This begs the question, if the UK’s key national infrastructure is run by foreign-owned companies, is the data of UK citizens secure should a court in the US compel a hyperscaler to provide it? Here lies <a href="https://www.computerweekly.com/resources/Software-as-a-Service-SaaS">the nub of data sovereignty</a>.&nbsp;</p> <p>In this article, we provide a definition of data sovereignty, the ways it may be undermined from overseas – particularly by the US Cloud Act and FISA Section 702 – drill down into the detail of differing states of encryption and what they mean for security and sovereignty, and look at the inherently cross-border nature of cloud services and its impact on data sovereignty.&nbsp;</p> <p>Core to the article are questions we asked the hyperscalers that aimed to get at exactly how their services could be described as providing data sovereignty.&nbsp;</p> <p>These included how they could technically prevent US court-compelled snooping, the protection afforded by encryption, especially during processing, and how <a href="https://www.computerweekly.com/news/366632561/Court-dismisses-Apples-appeal-against-Home-Office-backdoor">court-compelled backdoors</a> might be injected into infrastructure updates. We also asked to what extent it is possible to offer a sovereign UK cloud region and whether standard cloud terms conflict with <a href="https://www.computerweekly.com/opinion/Data-is-a-sovereignty-issue-And-broader-than-just-the-hyperscalers">data sovereignty</a>.</p> <p>The results illustrate the paradox that lies at the heart of cloud services and data sovereignty.</p> <section class="section main-article-chapter" data-menu-title="Defining data sovereignty"> <h2 class="section-title"><i class="icon" data-icon="1"></i>Defining data sovereignty</h2> <p>We live in a land where the government can’t define data sovereignty. <a href="https://www.computerweekly.com/feature/Breaking-the-stranglehold-Responses-to-data-sovereignty-risk">We asked</a> the UK Department for Science, Innovation and Technology (DSIT) in February about its progress towards a <a href="https://www.techtarget.com/whatis/definition/data-sovereignty">definition of data sovereignty</a>, but it couldn’t give one or say when it would have one.&nbsp;</p> <p>But we can work out a definition.</p> <p>The idea of sovereignty as applied to states means the solely held power to govern or control a country.</p> <p>For example, if country A invades country B and establishes control over a swathe of land, where country B’s armed forces, police, and so on, no longer have any authority, then it can be said that country B no longer has sovereignty in the portion of its territory so affected.&nbsp;</p> <p>We can form a definition of data sovereignty based on the same principle.&nbsp;</p> <p>So, if a company headquartered in country A provides technology services in country B, and can effect access to data of citizens of that country, then country B cannot say the data of its citizens is sovereign.</p> <p>Country B may have laws that protect the data of its citizens. But if the country in which the tech company is headquartered has the ability to compel it to provide data held in its systems in another country, then those two sets of laws conflict. Or more to the point, the laws of country B are undermined, and are not sovereign.&nbsp;</p> <p>It’s a parallel to where a country has laws that govern its citizens, but the presence of foreign armed forces and the rules they impose nullify its writ.&nbsp;</p> <div class="extra-info"> <div class="extra-info-inner"> <h3 class="splash-heading">Read more about data sovereignty</h3> <ul class="default-list"> <li><a href="https://www.computerweekly.com/feature/Breaking-the-stranglehold-Responses-to-data-sovereignty-risk">Breaking the stranglehold – responses to data sovereignty risk</a>: We look at the political and government responses to risks around data sovereignty and massive dependence on the three US hyperscalers – AWS, Azure and GCP – in the UK and Europe.</li> <li><a href="https://www.computerweekly.com/feature/This-rise-of-the-splinternet-Data-sovereignty-risks-and-responses">The rise of the splinternet? Data sovereignty risks and responses</a>: We look at the political, legal and economic risks around data sovereignty, the fears for digital dependency and massive hyperscaler penetration in the UK public sector.&nbsp;</li> </ul> </div> </div> </section> <section class="section main-article-chapter" data-menu-title="The Cloud Act and FISA Section 702"> <h2 class="section-title"><i class="icon" data-icon="1"></i>The Cloud Act and FISA Section 702</h2> <p>A good example of a law that compels companies headquartered within its jurisdiction to hand over data they possess is the <a href="https://www.techtarget.com/searchsecurity/news/252437526/CLOUD-Act-stirs-tension-between-privacy-advocates-and-big-tech">US Cloud Act</a>, passed into law during US President Donald Trump’s first term.</p> <p>Cloud here stands for Clarifying Lawful Overseas Use of Data. It was enacted in 2018 after Microsoft refused to hand over customer data held in a datacentre in Ireland, and it was determined that the US Department of Justice could not use domestic warrants to seize data held overseas.&nbsp;</p> <p>The Cloud Act compels US companies to provide to US law enforcement data in their “possession, custody, or control” even if overseas.&nbsp;</p> <p>At the same time, a US court can issue a non-disclosure order alongside any order under the Cloud Act. That’s basically a gag order that prohibits a company from telling the data subject that their information has been requested or handed over.</p> <p>There are ways a company subject to a Cloud Act order can challenge the court. These include a challenge on grounds of “comity”, in which the user in question is not a US person and that disclosure would violate the laws of a “qualifying foreign country”, namely one that has a bilateral agreement with the US, like the UK or Australia.</p> <p>Also, the Cloud Act is considered to be “encryption neutral”, so companies can be compelled to hand over what they have, but it does not compel them to break their own encryption if they do not already have the keys.</p> <p>Having said all that, US government agencies have other laws in their toolbox.&nbsp;</p> <p>Namely, the <a href="https://www.computerweekly.com/news/252433611/New-controversies-upset-plans-for-US-Foreign-Intelligence-Surveillance-Act">Foreign Intelligence Surveillance Act (FISA)</a> Section 702, which is up for an imminent vote to re-authorise it. Using this, the US government can compel a service provider to provide “technical assistance” to facilitate a search, with no protection for foreign citizens who are targeted by provisions under the act.</p> <p>The European Court of Justice (ECJ) has twice struck down data-sharing agreements between the US and EU (<a href="https://www.computerweekly.com/feature/Max-Schrems-The-man-who-broke-Safe-Harbour">Schrems I</a> and <a href="https://www.computerweekly.com/opinion/How-Schrems-II-will-impact-data-sharing-between-the-UK-and-the-US">Schrems II</a>) because FISA Section 702 does not provide equivalent protection to EU citizens.</p> <p>Such “technical assistance” could take the form of compiled code in a software update that enabled the exfiltration of data.&nbsp;</p> </section> <section class="section main-article-chapter" data-menu-title="Does encryption protect citizen data?"> <h2 class="section-title"><i class="icon" data-icon="1"></i>Does encryption protect citizen data?</h2> <p>When we get to the responses of the hyperscalers to questions about data sovereignty, we will see an appeal to the fact that data in their systems is encrypted and that only customers hold the keys.</p> <p>We have also seen that the US Cloud Act does not compel a court-ordered company to hand over encryption keys, although FISA 702 can compel “technical assistance” to gain access to data.</p> <p>Here, it is important to drill down into encryption.&nbsp;</p> <p>Firstly, to say that for most data for most of the time, encryption is as good a protection as you can get. Current encryption standards dictate algorithms that are practically impenetrable.</p> <p>So, if you apply, for example, <a href="https://www.techtarget.com/searchsecurity/definition/Advanced-Encryption-Standard">AES-256</a> to data-at-rest or data-in-transit, it cannot be read.</p> <p>The fly in the ointment comes when data is being processed. It’s also a problem for companies that argue that the data they hold is secure because it is encrypted.</p> <p>The problem is that – generally speaking – data-in-use must be unencrypted to be processed. And so, in theory, a foreign law enforcement agency that wanted to access data in a cloud system overseas could order data to be collected during processing.</p> <p>Memory scraping, in which malware scans active memory to steal unencrypted data, is possible, for example.</p> <p>It’s true that most data-in-use is unencrypted, although cloud providers do offer so-called confidential computing of some sort.</p> <p>For example, a <a href="https://www.techtarget.com/searchitoperations/definition/trusted-execution-environment-TEE">trusted execution environment (TEE)</a> in so-called confidential computing creates a hardware-encrypted “black box” inside the central processing unit (CPU), which means an unauthorised intruder cannot see inside it while data is being processed.</p> <p>TEEs are breakable, however. It is possible to “listen” to the CPU and measure power consumption or tiny timing fluctuations to guess the data being processed.</p> <p><a href="https://www.techtarget.com/searchsecurity/definition/homomorphic-encryption">Fully homomorphic encryption (FHE)</a> is the Holy Grail, however, because it allows for computation without decrypting data. But that also means it is computationally expensive and isn’t commonplace.</p> </section> <section class="section main-article-chapter" data-menu-title="Air gaps, updates and follow-the-sun"> <h2 class="section-title"><i class="icon" data-icon="1"></i>Air gaps, updates and follow-the-sun</h2> <p>Hyperscaler clouds are an international web of regions and availability zones. They comprise a global operating system, almost entirely managed by artificial intelligence (AI) and orchestrated automation.</p> <p>Cloud networks are made up of regions and availability zones (AZs). Regions are geographically separate – and thus upon them rests the claim of sovereignty by the cloud providers – while AZs are datacentres within a region. AZs within a region are connected by high-bandwidth connections, whereas regions are all interconnected but not by the same low-latency connections.</p> <p>Clouds run on software-defined everything, with every component represented as code, where faults can be monitored and workloads shifted to a different location should issues be detected, and with rolling updates on a non-disruptive zone-by-zone basis.</p> <p>Follow-the-sun in support terms is when support teams hand off responsibility to teams elsewhere in the world to benefit from more convenient (ie, less costly) working hours than the region in question.&nbsp;</p> <p>Follow-the-sun in workload terms means the movement of workloads across the globe to take advantage of lower energy costs or cooler ambient temperatures.</p> <p>In both cases, there is potentially a risk to sovereignty, by dint of where data resides at any given time and the jurisdiction under which support staff may operate, although customers can specify that data permanently resides in a given region.&nbsp;</p> <p>If you sign a standard business or enterprise support contract with a hyperscaler, you are opting in to follow-the-sun by default. A standard agreement usually means you agree to terms that allow the provider to support your account from any global location to meet 24/7 uptime guarantees.&nbsp;</p> <p>It also allows them to route technical metadata (logs, access records, telemetry) to global hubs to maintain the cloud and to allow global administrators access for emergency maintenance, regardless of where those administrators are.</p> <p>The fact that it is metadata that moves potentially allows a provider to say, “We don’t move your data”, but the metadata may be enough for a FISA Section 702 investigation, for example.&nbsp;</p> <p>You can’t just uncheck a box in the settings to opt out of follow-the-sun. Instead, you have to move to a <a href="https://www.computerweekly.com/feature/Sovereign-cloud-and-AI-services-tipped-for-take-off-in-2026">sovereign cloud</a> or regulated industry contract – the AWS European Sovereign Cloud or Microsoft Sovereign Cloud, for example. These guarantee that support and operations are handled only in a specific region.</p> <p>There are also “sovereign cloud” solutions, in which the “cloud” is disconnected from the wide area network (WAN).</p> <p>Obviously, if a customer is on a standard contract, support has full oversight of maintenance and updates, and quite likely from anywhere in the world. You’d think that a local sovereign cloud would remove that scenario, but the cloud provider’s infrastructure must still be maintained, and it is via patching that that occurs. Here is where unwanted snooping could be introduced.&nbsp;</p> <p>Even if the UK staff are the only ones physically in the datacentre, the private keys used to sign “official” software updates likely reside in a hardware security module (HSM) in the US or its facility elsewhere.</p> <p>So, if a US court compels the company to sign an update that contains legally sanctioned spyware, UK “sovereign” staff have no technical way to verify that the code doesn’t contain a backdoor.&nbsp;</p> </section> <section class="section main-article-chapter" data-menu-title="Questions to the hyperscalers"> <h2 class="section-title"><i class="icon" data-icon="1"></i>Questions to the hyperscalers</h2> <p>We asked <a href="#AWS">AWS</a>, <a href="#Google">Google Cloud</a> and <a href="#Microsoft">Microsoft</a> five questions around data sovereignty. We also asked <a href="#IBM">IBM</a> and Oracle, because they are both fair-sized US-based suppliers to the UK public sector.&nbsp;</p> <p>The intention was to gauge the levels of exposure their customers could face with regard to data sovereignty.</p> <p>All responded except Oracle, whose PR representatives failed to reply to three emails.&nbsp;</p> <p>The questions were preceded by a preamble that drew attention to the US Cloud Act, non-disclosure orders and FISA Section 702, and the powers therein to compel a provider to grant access, forbid notifications to customers of a court order, compel “technical assistance”, and the possibility of updates authored in the US as a means to effect access to customer data.&nbsp;</p> <p>The questions asked about:</p> <ul class="default-list"> <li>The technical barriers, if any, in the provider’s cloud services that prevent a court order from forcing the use of encryption keys to decrypt customer data.</li> <li>The technical means by which data-in-use functions are carried out without cloud provider access to encryption keys.</li> <li>Whether the cloud provider can guarantee a US-authored software update that contains “technical assistance” aimed at gaining access to data cannot bypass air-gapped systems.</li> <li>Whether the cloud provider has a wholly distinct UK region with exclusively UK-resident support and engineering, including third-party contractors.&nbsp;</li> <li>Whether standard terms of cloud service allow for customer data to be moved offshore, or whether a customer can have 100% UK data residency without a bespoke contract.</li> </ul> </section> <section class="section main-article-chapter" data-menu-title="Hyperscalers dodge the questions"> <h2 class="section-title"><i class="icon" data-icon="1"></i>Hyperscalers dodge the questions</h2> <p>Here we summarise their responses. Full responses are available to view in the <a href="#QandAs">box at the end of this article</a>.</p> <p>Hyperscaler responses to our questions fall under the following categories.</p> <p><strong>“Don’t look there! Look at the air gap!”</strong> The subject of the questions was cloud services in general, but responses often shifted attention to specifically air-gapped offerings.</p> <p><a href="#Google">Google</a> opted to talk about its niche, air-gapped Google Distributed Cloud in response to nearly every question. Perhaps a tacit admission that standard cloud terms of service come nowhere near providing data sovereignty.&nbsp;</p> <p>Google wasn’t alone here, though; just the most dependent on the tactic. AWS also pointed to its AWS Dedicated Local Zones and Outposts managed on-premise offers when asked about cloud services.&nbsp;&nbsp;</p> <p><strong>“Look! Local people!” </strong>A number of responses tried to distract from the inherent technical vulnerabilities that come with the global, linked nature of hyperscaler cloud. They instead drew attention to the residency or nationality of human operators rather than the reality that automated, US-signed code updates can bypass human gatekeepers entirely.</p> <p>It is virtually impossible for a locally resident operator to scan a multi-gigabyte compiled binary for a state-level backdoor. A backdoor in a modern cloud stack wouldn’t be a line of code that said, “<em>if (user == 'FBI') return data</em>”. It would be a subtle mathematical weakness in an encryption library or a port knocking sequence hidden in a network driver.&nbsp;</p> <p>Local operators can, at best, scan for known viruses, not state-level “technical assistance”.</p> <p><strong>Encryption? Of course. For data-in-use? Errr. </strong>All hyperscalers highlighted the use of encryption in customer data and customer key retention to imply total security.&nbsp;</p> <p>That works for “at-rest” and “in-transit” scenarios. But it glosses over data-in-use scenarios where data must, in most cases, be decrypted in memory.&nbsp;</p> <p>If a US-compelled “technical assistance” order under FISA Section 702 forces a US company to push a firmware update to its own HSMs or Nitro controllers, that update is signed by the US parent. Hardware isolation is only as sovereign as the person who holds the cryptographic signing key for the firmware.</p> <p>Also, in a software-as-a-service (SaaS) environment like M365, Microsoft provides the application and is the administrator. Here, customer-managed keys often break “search” and “discovery” features in SaaS. So, if a customer wants to search their emails in M365, the data must be decrypted by Microsoft’s service.&nbsp;</p> <p><strong>Is it sovereign? Of course; it’s in the EU. </strong>In some cases, hyperscalers responded by pointing to European sovereign solutions. <a href="#AWS">AWS</a>, for example, points to its <a href="https://www.computerweekly.com/news/366557158/AWS-to-open-European-sovereign-cloud-region">European Sovereign Cloud service</a>, which doesn’t locate data in the UK and is not technically sovereign anyway, given the EU is not a sovereign state.&nbsp;</p> <p>Meanwhile, if AWS Seattle has “control” over the AWS Germany subsidiary, which it does, financially and technically, a US court doesn’t care about the EU’s “Sovereign Cloud” label.</p> <p><strong>“Trust Me, Bro,” as a legal pledge.</strong> <a href="#Microsoft">Microsoft</a> majored on this one in its responses. It switches out technical proof of impossibility for corporate pledges to “challenge every government request” in court. This asks the customer to trust a legal process rather than a technical lock.&nbsp;</p> <p>Spoiler alert: There are zero known instances where a hyperscaler has successfully and permanently defied a final, non-appealable US court order to protect a non-US citizen’s data stored abroad.</p> <p>To sum all this up, the hyperscalers are essentially saying that standard cloud is not sovereign. To achieve a level of protection that would allow them to answer these questions with any level of integrity, a customer must move to isolated, air-gapped, or hardware-encrypted tiers that are significantly more expensive, regionally limited and functionally constrained. And would that be cloud?</p> </section> <section class="section main-article-chapter" data-menu-title="The paradox of data sovereignty in the cloud"> <h2 class="section-title"><i class="icon" data-icon="1"></i>The paradox of data sovereignty in the cloud</h2> <p>At the end of the day, hyperscaler cloud is caught in a paradox when it comes to data sovereignty. If a cloud were truly sovereign – disconnected, local-only, human-managed – it would lose the cloud economics that make it attractive due to its global scale, automation and the accompanying economies. And so, “sovereign cloud” is really often a marketing term that means standard cloud with extra paperwork.</p> <div class="extra-info"> <div class="extra-info-inner"> <h3 class="splash-heading"><a id="QandAs"></a>The questions we asked and hyperscaler responses</h3> <p>We wanted to get to the bottom of just how sovereign hyperscaler cloud services are. The main article discusses the key issues and summarises the responses of hyperscalers to the questions put to them by Computer Weekly.</p> <p>Here we reproduce the questions in full, along with hyperscaler responses.</p> <p>We asked for “specific, technical” answers to questions, and hyperscalers were told general marketing statements or high-level policy positions would not be printed (though that’s what some responses amount to and are printed here).</p> <p>The goal of the questions was stated as: “To provide readers with a clear view of which sovereignty claims are backed by verifiable technical mechanisms and which remain matters of corporate policy.”</p> <p>The following context was also given, namely that under 18 USC 2705(b), federal courts can issue non-disclosure orders alongside US Cloud Act data warrants that legally forbid providers from notifying customers of a breach.&nbsp;</p> <p>Also, that when combined with the “technical assistance” provisions of FISA Section 702, the US government can compel a provider to facilitate access to data.&nbsp;</p> <p>Finally, a key assumption stated in the preamble to questions was that because cloud stacks rely on a global supply chain where code is authored and signed at a US headquarters, the “update” is a potential invisible vector for state-level intervention that is difficult to obstruct.</p> <h2>What we asked the hyperscalers</h2> <p><strong>Question 1:</strong> If your cloud services require access to data “in the clear” to perform processing tasks (such as indexing, AI inferencing, or analytics), how do you technically prevent a US-compelled warrant from forcing you to use the required cryptographic keys to decrypt and surreptitiously provide that data to law enforcement?</p> <p><strong>Question 2:</strong> If you claim to never have access to encrypted customer data, how do you technically perform “data-in-use” functions without possessing the keys to decrypt that data within your processing environment?</p> <p><strong>Question 3:</strong> If your sovereign cloud relies on a software supply chain authored and signed by a US-headquartered parent company, how can you technically guarantee that a US-compelled “technical assistance” update – issued under a mandatory gag order – could not silently bypass local air gaps and data controls?</p> <p><strong>Question 4:</strong> Can you provide evidence of a wholly distinct UK region capable of operating all core services in total isolation from your global infrastructure, managed exclusively by a 100% UK-resident support and engineering framework – including all third-party subcontractors?</p> <p><strong>Question 5:</strong> Do your standard terms of service grant you the discretion to move or “offshore” customer data and metadata for residency, resiliency, or global support purposes, and if so, how can a UK customer maintain 100% residency without a bespoke contract that breaks your global automation model?</p> <h2><a id="AWS"></a>The responses: AWS</h2> <p><strong>Computer Weekly commentary</strong></p> <p>Where the questions ask for “specific, technical” responses, AWS answers vaguely, such as when it refers to “a range of technical measures and operational controls” in questions 1 and 2.&nbsp;</p> <p>Also, when what has been asked is specifically technical, what appears as a sleight of hand is to refer to operator and staff access to data. In the context of a massive, automated technical environment, whether an individual has access to masses of compiled code in updates is irrelevant.&nbsp;</p> <p>We see that type of response in questions 1, 2 and 3. The effect here is to draw attention away from a potential scenario in which a US court forced AWS to provide “technical assistance” in an update script that would easily cross borders and bypass human gatekeeping. The idea that some update code is written in European countries is another irrelevance thrown in.&nbsp;</p> <p>When asked in question 4 about a discrete UK region isolated from the rest of AWS’s global infrastructure, the response refers to AWS-managed on-premise infrastructure. Such an offer might provide in-country capacity – although we don’t know whether updates come from elsewhere – but it isn’t really the cloud.&nbsp;</p> <p>When asked whether “standard Terms of Service grant you the discretion to move or ‘offshore’ customer data and metadata”, AWS points to its European Sovereign Cloud service, which doesn’t apply to the UK and is arguably not sovereign, given the EU is not a sovereign state.</p> <p><strong>AWS response to question 1:&nbsp;</strong></p> <p><em>AWS customers have a range of technical measures and operational controls to prevent access to data, and AWS has designed products and services that make sure that no one – not even AWS operators – has any technical means to access customer content.</em></p> <p><em>The Cloud Act does not create any new authority for law enforcement to compel service providers to decrypt communications.</em></p> <p><strong>AWS response to question 2:&nbsp;</strong></p> <p><em>AWS customers have a range of technical measures and operational controls to prevent access to data, and AWS has designed products and services that make sure that no one – not even AWS operators – has any technical means to access customer content.</em></p> <p><strong>AWS response to question 3:&nbsp;</strong></p> <p><em>Only AWS European Sovereign Cloud employees located in the EU and subject to EU law have deployment authority over software updates. Authorised EU-resident employees of the AWS European Sovereign Cloud also have independent access to a replica of the source code needed to maintain the AWS European Sovereign Cloud services.</em></p> <p><em>“The premise of this question is also misleading. Amazon is a global company that operates worldwide supply chains reliant on suppliers and teams from every part of the world. Some of our largest AWS development teams are located in Europe – with key centers in Dublin, Dresden, and Berlin – contributing to core AWS solutions including the AWS Nitro System that powers all modern EC2 instances, Amazon Linux, and Amazon CloudWatch.</em></p> <p><strong>AWS response to question 4:</strong></p> <p><em>AWS offers several products that help customers address UK-specific sovereignty requirements. AWS Dedicated Local Zones can be deployed in a chosen UK location with local AWS employee operations and security features for data isolation and compliance. AWS Outposts deploy in customer UK facilities with hardware-enforced isolation ensuring no AWS operator access to customer data.&nbsp;</em></p> <p><strong>AWS response to question</strong> <strong>5:</strong></p> <p><em>With AWS, customers own their data, control where it’s stored, and decide who can access it. AWS is transparent about how services process customer data, and customers can use tools like AWS Control Tower for management. The AWS European Sovereign Cloud allows customers to keep all metadata they create entirely in the EU, including sovereign Identity and Access Management (IAM), billing, and usage metering systems.&nbsp;</em></p> <h2><a id="Google"></a>The responses: Google Cloud</h2> <p><strong>Computer Weekly commentary</strong></p> <p>The questions were about hyperscaler cloud services. Google provided more information than the other providers, but responded to nearly all the questions as if it had been asked about one very specific and not particularly common offering, namely Google Distributed Cloud (GDC) air-gapped.&nbsp;</p> <p>GDC air-gapped is an on-premise solution, where – Google claims – any updates must be physically transported across the air gap and can be scanned by a trusted operator. Likewise, it says it literally could not comply with a US court order to spy on a customer or hand over data because it has no reach into their systems. That’s likely true for GDC air-gapped, but it’s not what it was asked about.</p> <p>But, Google – rather helpfully – provides information about its mainstream cloud offer that allows us to get a good idea about standard cloud services terms and conditions that the other hyperscalers don’t elaborate upon.</p> <p>For example, it says: “In a standard cloud, Google pushes updated code silently, and often multiple times in a day.”&nbsp;</p> <p>Similarly, it says: “Standard Terms of Service (ToS) that govern the public cloud . . . often include clauses for global load balancing, ‘follow-the-sun’ support, and data movement for resiliency.”</p> <p>And: “The standard ‘global support’ model relies on an engineer in any region being able to ‘see’ your project to troubleshoot.”</p> <p><strong>Google response to question 1:</strong></p> <p><em>In the context of Google Distributed Cloud (GDC) air-gapped, the solution to the compelled disclosure dilemma isn't just a policy promise – it is a fundamental architectural constraint. Because the air-gapped version of GDC is physically and logically isolated from the public internet and Google’s corporate network, the technical barriers to a US-compelled warrant are built into the "sovereignty by design" model.</em></p> <p><em>1. Physical and Network Isolation</em></p> <p><em>No Remote Access: GDC air-gapped does not have a backhaul connection to Google’s global infrastructure. There is no persistent management plane or "phone home" feature that Google can toggle to extract data.</em></p> <p><em>Hardware Ownership: The hardware resides in the customer's chosen location (or a partner's sovereign data center). Google employees generally do not have unescorted physical access to the site.</em></p> <p><em>2. Customer-Managed Encryption Keys (CMEK)</em></p> <p><em>While processing data “in the clear” requires keys, the ownership of those keys is the technical pivot point:</em></p> <p><em>Hardware Security Modules (HSM): In a GDC air-gapped environment, the keys are stored in local HSMs physically located within the air-gapped boundary.</em></p> <p><em>Root of Trust: The customer (or a designated sovereign partner) holds the root of trust. Google does not possess a master key or a remote mechanism to bypass the local HSM to decrypt data for indexing or AI tasks.</em></p> <p><em>3. Tactical Operational Sovereignty</em></p> <p><em>To prevent surreptitious access, GDC air-gapped utilizes a Sovereign Operations model:</em></p> <p><em>No Google Personnel Required: The day-to-day operations, including patching and AI model deployment, can be handled by the customer or a local, cleared third party.</em></p> <p><em>Auditability: Every action taken within the environment is logged locally. Since Google cannot access these logs remotely, they cannot hide a data extraction process from the customer’s own security operations center (SOC).</em></p> <p><em>From a legal standpoint, if Google is served a warrant for data residing in a GDC air-gapped instance, the technical response is “Inability to Comply.” Because Google does not have the network path to reach the data, the physical access to the servers, or the cryptographic keys to decrypt the disks, they cannot “surreptitiously” provide the data. Any attempt to gain that data would require a physical raid on the customer’s own facility – which falls under the customer's local laws and security protocols, not Google’s.</em></p> <p><strong>Google response to question 2:</strong></p> <p><em>In the context of Google Distributed Cloud (GDC) air-gapped, the claim of no access isn’t saying the data is never decrypted; it is saying that Google (the entity/personnel) never has access to the keys or the environment where decryption occurs. The distinction lies in the transition from Data-at-Rest to Data-in-Use within a boundary that Google cannot enter. Here is how that is technically achieved:</em></p> <p><em>1. Sovereign Boundary Logic</em></p> <p><em>In a standard public cloud, the provider manages the hypervisor and the orchestration layer. In GDC air-gapped, the entire stack, from the silicon to the AI workbench, is moved inside the customer’s perimeter.</em></p> <p><em>Local Decryption: When an AI model needs to “see” data in the clear to perform inferencing, the decryption happens on-premises using keys pulled from a local HSM&nbsp;</em></p> <p><em>Isolation of the Execution Environment: The decryption occurs within the customer’s air-gapped hardware. Because there is no network path back to Google, the “clear text” data exists only in the local RAM of the air-gapped servers.</em></p> <p><em>2. Customer-Controlled Key Access</em></p> <p><em>The software performing the processing must request the key from the local Key Management Service (KMS).</em></p> <p><em>Access Control Policies: The customer defines the Identity and Access Management (IAM) roles.</em></p> <p><em>Technically Barred: Google does not have an identity in the customer’s local air-gapped IAM system. Therefore, the processing environment can’t “ask” for a key on Google’s behalf, and Google cannot “push” a command to release a key to an unauthorized third party as these are Customer managed encryption keys (CMEK).</em></p> <p><strong>Google response to question 3:</strong></p> <p><em>In Google Distributed Cloud (GDC) air-gapped, this risk is mitigated through a combination of Customer-Led Updates, Binary Authorization, Third-Party Operations.</em></p> <p><em>1. No “Automatic” Updates</em></p> <p><em>In a standard cloud, Google pushes updated code silently, and often multiple times in a day. In GDC air-gapped, there is no physical connection to Google.</em></p> <p><em>The Manual Bridge: Updates are provided as signed container images and binaries. The customer (or their trusted sovereign partner) must download these to a separate secure workstation, scan them, and then physically move them across the “air-gap” via encrypted media.</em></p> <p><em>Technical Sovereignty: This creates a human-in-the-loop bottleneck. A US-compelled “silent” update is impossible because Google cannot “push” anything. The customer chooses when and if to ingest the update.</em></p> <p><em>2. The “Sovereign Operator” Audit</em></p> <p><em>A critical technical defense is who applies the update.</em></p> <p><em>Third-Party Managed: GDC can be operated entirely by a local, cleared partner (eg, STE in Singapore, Proximus in Belgium). These operators act as a “sovereign shield.”</em></p> <p><em>Inspection: Before the update is applied to the live environment, these operators can deploy it in an isolated “staging” air-gap. They monitor for “phone home” behavior (which would fail anyway due to the air-gap) or unauthorized data export attempts at the virtual network layer.</em></p> <p><em>3. Technical Assistance vs. Technical Impossibility</em></p> <p><em>A company can be compelled to provide “technical assistance,” but they cannot be forced to perform the “technically impossible.”</em></p> <p><em>Hardware Root of Trust: Because the keys are in your HSM, Google cannot remotely sign a command to “export” data.</em></p> <p><em>The Gag Order Paradox: Even if Google were under a gag order, they cannot physically enter your data center to plug in a USB drive. If the only way to execute the warrant is to walk a physical drive into a sovereign facility, the legal burden shifts to the local government and the physical security team at the door.</em></p> <p><strong>Google response to question 4:</strong></p> <p><em>Yes - this could be built for customers using Google Distributed Cloud Air Gapped, like the landmark deal we have announced for the MOD. In 2025, Google Cloud and the UK Ministry of Defence (MoD) formalized a landmark agreement for a sovereign, air-gapped cloud. [Link to press release].&nbsp;</em></p> <p><em>Pasting the helpful info here:&nbsp;</em></p> <p><em>Google Distributed Cloud Air Gapped: The sovereign cloud environment will be built upon Google Distributed Cloud (GDC) air-gapped, a platform designed for workloads that require strict data residency and security controls. GDC provides a hardened, air-gapped environment, ensuring that the MOD’s critical data remains within UK sovereign territory and under their direct control. This platform will also enable the responsible integration of Google's advanced AI and machine learning tools, empowering the MOD with enhanced analytical capabilities to provide operational efficiencies.</em></p> <p><strong>Google response to question 5:</strong></p> <p><em>The short answer is no. In the context of Google Distributed Cloud (GDC) air-gapped, the standard Terms of Service (ToS) that govern the public cloud which often include clauses for global load balancing, “follow-the-sun” support, and data movement for resiliency do not apply. GDC air-gapped is governed by a separate, specific legal and technical framework designed to ensure that the global automation model is physically unable to move our customers’ data or metadata.</em></p> <p><em>1. Service-Specific Terms</em></p> <p><em>Instead of the standard online ToS, air-gapped customers use GDC Air-Gapped Service Specific Terms. These terms explicitly recognize the disconnected nature of the environment:</em></p> <p><em>Removal of “Offshoring” Discretion: Because the system is air-gapped, Google legally and technically removes its own ability to move data. The terms define the "Sovereign Boundary," stating that data and metadata (logs, telemetry, and configuration) must remain within the customer-controlled or partner-operated facility.</em></p> <p><em>2. Breaking Global Automation</em></p> <p><em>You do not need a “bespoke contract” to prevent data movement because the automation model itself is local.</em></p> <p><em>Local Management Plane: In the public cloud, the control plane lives in a global mesh. In GDC air-gapped, the control plane is physically located inside the rack in your UK data center.</em></p> <p><em>Hardware-Locked Metadata: Metadata like IP addresses, VM names, and audit logs are stored on local disks within the air-gapped environment. There is no automated routine that can “call” this metadata back to a global database because there is no network route to the outside world.</em></p> <p><em>3. Sovereign Operations vs. Global Support</em></p> <p><em>The standard “global support” model relies on an engineer in any region being able to “see” your project to troubleshoot. GDC air-gapped replaces this with Resident Support.</em></p> <p><em>100% Residency of Support: Support is provided by a UK-resident, cleared team. If they need to look at a log, they do it within the UK boundary.</em></p> <p><em>No Remote Access: Even if a US engineer wanted to help, they have no technical way to log into the system. The "automation" for support is localized to a secure UK-based operations center.</em></p> <p><em>4. How to Maintain 100% Residency Without “Breaking” the Cloud</em></p> <p><em>The innovation of GDC air-gapped is that it provides a cloud-native experience that is functionally identical to the public cloud but architecturally siloed.</em></p> <p><em>Local Resiliency: Instead of relying on a US region for backup, you achieve resiliency by deploying multiple GDC racks across different UK-only zones</em></p> <p><em>The Secure Supply Chain: Google provides the code (the binaries), but you provide the home. Once that code is installed, it operates as a “black box” that answers only to your local UK administrators.</em></p> <h2><a id="Microsoft"></a>The responses: Microsoft</h2> <p><strong>Computer Weekly commentary</strong></p> <p>Microsoft chose not to respond to the questions inline, so it’s not as easy to see what its answers respond to.</p> <p>Again, we see reference to “workloads in air-gapped or disconnected environments”, when that was not the subject of the questions.&nbsp;</p> <p>Where questions asked for “specific, technical” responses, we get bland answers. There’s also a long paragraph about encryption keys that appears to be about data-at-rest or in-transit, which we didn’t ask about.</p> <p>There is also reference to “UK customers . . . ability to store and process their data within UK datacenters . . . [That] includes compliance with local regulations and provides geo-redundant protection for business continuity”.&nbsp;</p> <p>Microsoft Azure does have a data-in-use encryption offer in Azure Confidential Computing, although it doesn’t mention it by name.</p> <p>In its final paragraph, Microsoft talks of its commitment to and “strong record” in challenging court orders. But really, it amounts to “Trust me, bro.”</p> <p><strong>Microsoft responses</strong></p> <p><em>Microsoft customers can deploy workloads in air-gapped or disconnected environments using Azure Local and Microsoft 365 Local, with full control over update management, monitoring, and lifecycle operations via a local control plane.</em></p> <p><em>External Key Management allows customers to use their own on-premises or third-party Hardware Security Modules (HSMs) for encryption, ensuring Microsoft does not have access to customer keys. Microsoft’s custom HSM is deployed globally. In addition, Azure Confidential Compute, Azure Key Vault, and Double Key Encryption, are designed, deployed, and operated such that Microsoft is incapable of accessing, using, or extracting data stored in the service, including cryptographic keys.</em></p> <p><em>Microsoft performs "Data-in-Use" functions without possessing customer encryption keys by leveraging a layered encryption model and customer-managed keys.</em></p> <p><em>Microsoft offers UK customers the ability to store and process their data within UK datacenters. This includes compliance with local regulations and provides geo-redundant protection for business continuity.</em></p> <p><em>Microsoft does not provide any government with direct, unfettered access to customer data. Any data access request is subject to rigorous review, according to a strict process, by internal and external legal teams to ensure it is legally valid and compulsory, compliant with all applicable law, and strictly limited to specific account identifiers.&nbsp; Further, as part of our Defending Your Data initiative we’ve committed to challenge every government request for an EU public sector or commercial customer’s data where we have a lawful basis for doing so. We have a strong record of doing just that, including through litigation where necessary.</em></p> <h2><a id="IBM"></a>The responses: IBM</h2> <p><strong>Computer Weekly commentary</strong></p> <p>IBM considered that question 1 merged disparate issues, so it didn’t answer it.</p> <p>Like others, it answered questions as if it had been asked about air-gapped environments, when it wasn’t.&nbsp;</p> <p>When asked about data-in-use encryption, it refers to its new IBM Sovereign Core, which appears to be a product aimed at holding encryption keys in-country but doesn’t specifically mention in-memory encryption. It references the same product when asked about “a wholly distinct UK region”.</p> <p>IBM Sovereign Core is currently in tech preview and published materials are a little light on detail. We’d want to know more about in-use encryption and connections to IBM’s global network, updates, and so on.</p> <p><strong>IBM response to question 1:&nbsp;&nbsp;</strong></p> <p><em>This question merges several distinct concepts that are technically separate. In modern software applications data‑in‑use processing, encryption key management and lawful access requests, are all designed and governed by different architectural and operational controls. Please refer to questions 2 and 3 for relevant information.&nbsp;</em></p> <p><strong>IBM response to question</strong> <strong>2:</strong></p> <p><em>IBM Sovereign Core processes data‑in‑use within the customer application’s trusted execution environment, where purpose‑bound application code determines when and how data is processed; decryption, where required, is transient, in‑memory, and under the application’s control with customer visibility. Capabilities like Keep Your Own Key encryption ensure keys are held and managed exclusively by the customer and are not accessible to IBM.</em></p> <p><strong>IBM response to question 3:</strong></p> <p><em>Software supply‑chain, execution in air‑gapped environments, and legal access frameworks are all independent by design, governed by separate technical and operational controls: our clients hold full technical authority in air gapped environments, and IBM technology places transparency and control in the hands of our clients, consistent with our publicly available data access principles and law‑enforcement transparency reports.&nbsp;</em></p> <p><strong>IBM response to question</strong> <strong>4:&nbsp;</strong></p> <p><em>IBM Sovereign Core enables UK enterprises to run and govern AI workloads within the UK jurisdictional boundaries, without relying on a global provider control plane, and with the flexibility to choose UK‑based operating partners.&nbsp;</em></p> <p><strong>IBM response to question</strong> <strong>5:</strong></p> <p><em>For more than a century, IBM has earned the trust of our clients by responsibly managing their most valuable data. IBM is transparent about how it handles client data and does so in accordance with all applicable laws.</em></p> </div> </div> </section>