Your AI Has a Passport Problem : Three sovereignty risks the humanitarian sector has not confronted

AI disclosure: AI tools assisted with public-source research, source cross-referencing, adversarial review, and drafting and editing options for this piece and the linked working paper, under MarketImpact's verification standard. No beneficiary-level data, client-confidential material, or unpublished operational datasets were used. The three-risk framework, the legal analysis, the final wording, and all editorial judgement are the author's own. How we use and verify AI:marketimpact.org/how-we-use-ai.

On 12 June 2026, a US export-control directive required Anthropic to restrict access to its two most capable AI models, Fable 5 and Mythos 5, by foreign nationals. Anthropic said it had no reliable way to verify nationality across users and deployments in real time, so it switched both deployments off for everyone. That distinction matters legally: the US government did not order a global shutdown, it imposed a nationality condition, and the provider could not operationalise that condition at scale. For users, the practical difference was thin. The directive arrived at 5:21pm on a Friday, without explanation of the specific national-security concern. By that evening, access was gone.

The controls were lifted on 30 June. Fable 5 returned globally from 1 July; Mythos 5 returned more narrowly, initially to a set of US organisations following government approval. Access resumed after government review of safeguards, new information-sharing commitments, and pre-release government testing arrangements for future models; the Commerce Secretary described the process as working with Anthropic to "analyze and approve" the model. The outage was temporary. The governance lesson was not, because access did not simply come back. It came back through a government gate.

The instinct will be to file this as an AI story that resolved itself: a powerful model got restricted, a government got nervous, the company negotiated, access returned. I think that is the wrong frame, and it will lead the sector to the wrong fix. The Anthropic episode is a symptom. The condition is that the operational infrastructure of global humanitarian response — the email, the file storage, the coordination platforms, the databases, the analytics, and now the AI layer — runs on systems owned by companies incorporated somewhere, governed by law somewhere, and subject to political decisions somewhere. That "somewhere" matters.

In early June I argued that beneficiary data in a conflict zone is like nuclear fuel: hazardous from the moment it is created, dangerous long after its purpose ends. That piece was about the data. This one is about the systems that hold it, move it, and increasingly think with it. If the data is nuclear fuel, the AI models are the reactor, and in June the reactor was export-controlled, inspected, and conditionally recommissioned. That should make the sector uncomfortable.

The fully referenced working paper is linked at the end. This essay is the public version: fewer footnotes, same argument.

The passport problem

The sector has spent the last two years debating whether it is safe to paste beneficiary data into a chatbot. That is a real question, but it is not the biggest one. The bigger question is whether it is safe to run an entire operation on infrastructure subject to legal and political authority the sector does not control. Email has a jurisdiction. So do SharePoint, Google Drive, Teams, AWS, Palantir, Starlink, and the AI models themselves. They all have passports.

When I say a government can "control" this infrastructure, I do not mean it operates the servers or logs into your tenant. I mean something narrower and more operationally important: it can compel, restrict, sanction, license, approve, prohibit, or condition the provider. That is the control that matters when access disappears.

The sector treats these tools as infrastructure. The providers treat them as products. Governments treat them as jurisdiction. That mismatch is the risk, and three distinct sovereignty problems sit inside it. They get harder to manage as you go, and together they create a neutrality problem the sector has not faced.

Risk one: commercial sovereignty

The first risk is that a company you depend on decides your use case no longer serves its interests. On 5 May 2025, Microsoft retired Skype. Skype had documented historical use in humanitarian field contexts, including UNHCR-supported low-bandwidth deployments in hardship locations where heavier applications did not work well. Was it still mission-critical across the sector in 2025? I cannot prove that, because I have found no systematic public dataset on collaboration-tool use in humanitarian operations. That absence is part of the problem: we do not map these dependencies until they break.

Microsoft gave public notice and a general migration path, so this was not a sudden disappearance. But I have found no humanitarian-specific transition plan and no public assessment of what the retirement meant for teams using Skype precisely because it was lightweight, familiar, and good enough on bad connections. The product went away because the product owner moved on, and the sector moved too — in practice, to Teams, WhatsApp, Zoom, Signal, Google Workspace, or local equivalents. Some of those are better tools. Some are worse in low-bandwidth settings. The point is not Skype. The point is that the dependency did not shrink; it moved.

The same logic runs across the whole SaaS estate. Microsoft can change humanitarian licensing terms, Google can alter what Workspace includes at nonprofit tier, Palantir can reprice, and any platform can deprecate a feature, change a policy, restrict an integration, or remove a product. Whatever continuity these providers owe is contractual, limited, and defined by product terms and commercial strategy, not by humanitarian necessity. The sector calls it infrastructure. The provider calls it a product line.

Risk two: legal sovereignty

The second risk is quieter. It is not dramatic like an AI shutdown or visible like Skype going away. It has been in force for years, and the public humanitarian conversation has barely touched it.

The US CLOUD Act can require covered US-jurisdiction service providers, through valid legal process, to preserve, back up, or disclose customer communications and records within their possession, custody, or control, regardless of whether the data is stored in the United States or abroad. That phrase matters: possession, custody, or control. Your SharePoint files on a Microsoft server in Frankfurt are not outside US legal exposure because the server is in Frankfurt. Your Outlook mailboxes, OneDrive files, Teams records, and Gmail may sit in the same problem space, depending on the provider, service, architecture, configuration, encryption, key custody, and legal process. EU hosting does not remove US legal exposure by itself; it creates overlapping regimes. GDPR still matters, Article 48 matters, and providers may face a US obligation to produce alongside an EU-law problem if they do. That is a conflict-of-laws problem rather than simple US access. But from the perspective of a host authority deciding whether to trust your registration system, conflict and uncertainty are not reassuring.

The point is not that Microsoft or Google provide direct, unfettered access. They say they do not: requests go through legal process, and they review, narrow, reject, challenge, or notify where they can. That matters. But the legal pathway exists, it can reach data controlled by US-jurisdiction providers, and in some cases notice to the customer can be delayed or prohibited. Nor is exposure binary. Customer-held keys and client-side encryption can change what content a provider can produce, while metadata, account records, access logs, support records, and telemetry may remain reachable even where content is protected. If your agency has mapped that properly, platform by platform and data type by data type, you are ahead of the public evidence base.

FISA Section 702 is separate and should not be confused with the CLOUD Act. It is not a normal stored-data production mechanism for a SharePoint folder. It targets non-US persons reasonably believed to be outside the United States for foreign-intelligence purposes, with compelled provider assistance under approved procedures. Its relevance to humanitarian work is narrower, but not zero: humanitarian communications may be acquired incidentally where staff communicate with, or through selectors tasked against, lawful foreign-intelligence targets. Its status is currently unsettled. The statute lapsed on 12 June 2026 after Congress declined a further extension — the same day as the Anthropic directive, a coincidence rather than a connection — while collection reportedly continues under existing court-approved certifications into 2027. Two distinct forms of US state capacity over digital infrastructure were visible on the same day.

Exposure also differs by organisational legal status. UN entities, the ICRC, INGOs, national NGOs, and local partners do not face the same legal position: privileges and immunities, headquarters agreements, and inviolability of archives can materially alter the analysis. Jurisdictional exposure is a risk factor requiring organisation-specific review, not a single conclusion that applies equally to every humanitarian actor.

The sector's data-governance conversation has focused heavily on chatbots — do not paste sensitive data into ChatGPT, check the processing agreement, be careful with prompts. That covers a fraction of the actual exposure. The question is not only whether someone pastes beneficiary data into a chatbot. It is which data, in which services, under which provider's possession, custody, or control, can be reached through which legal authority, under which safeguards. The AI layer does not create that exposure. It inherits it.

Risk three: political sovereignty

The third risk is what happens when a state uses the override capacity it already has, and June showed the mechanism at both ends.

First, the restriction. Reporting linked the directive to a jailbreak technique reported by outside researchers. Anthropic disputed that characterisation, describing the technique as narrow and non-universal, and I am not adjudicating who was right — the dispute is part of the point. A provider contested the public characterisation of the risk, and the restriction stood anyway. Whatever the trigger, a nationality-based access condition was imposed on two frontier AI deployments, and because the infrastructure did not come with a nationality filter, a restriction aimed at one category of user produced a global outage.

Second, the restoration. Access returned after government review of safeguards, new information-sharing arrangements, and pre-release testing commitments, with Fable 5 returning globally and Mythos 5 more narrowly. The episode does not prove that every cloud platform can be switched off tomorrow. It proves something narrower and still important: state authority can alter access to frontier AI capabilities quickly, and restoration can be conditioned on government-facing review. That mechanism now exists in the open.

It is worth being honest about scale. I have found no public evidence that the less-than-three-week suspension materially disrupted humanitarian operations. That absence does not dissolve the risk; it locates it. The outage was survivable because frontier AI is not yet deeply embedded in most humanitarian workflows. As AI moves into search, triage, drafting, translation, analysis, reporting, case management, and decision support, the operational cost of the next restriction rises. The moment to govern the dependency is now, not after it becomes load-bearing.

Nor is the mechanism limited to standalone models. AI is being built into the platforms the sector already runs on: Microsoft 365 Copilot sits across Word, Outlook, Teams, and SharePoint; Google is embedding Gemini across Workspace; Palantir Foundry underpins operational data platforms such as WFP's DOTS, although that is a different kind of dependency from an office-suite assistant. Today many AI features are still administratively separable — Copilot is not Teams, Gemini is not Gmail, and restricting an AI feature does not automatically shut down the underlying service. But workflows change. People start drafting, searching, summarising, translating, classifying, and triaging with AI in the loop, processes get rebuilt around assistance that feels ambient, and the AI layer becomes part of the work rather than an add-on. Then the question changes from "can we access the model?" to "what breaks when the model is removed?" Nobody knows yet, which is why this is a risk rather than a solved problem.

The same question sits below the software layer. Starlink is becoming operationally important in disaster and conflict settings because it works when fibre is cut and towers are down, and it is also a US-jurisdiction infrastructure layer with concentrated corporate control. Connectivity has a passport too. That deserves its own piece, but the governance question is the same one running through this essay: what happens when the system that connects the operation is subject to corporate discretion, state jurisdiction, export controls, and owner-level decisions?

Where the three risks meet: neutrality

Any one of these risks is manageable alone. A tool gets retired, you find another one. A law creates exposure, you negotiate, configure, encrypt, or challenge. An export control hits a model, you use another model while access is sorted out. Agencies absorb this kind of thing every day. The trouble is what the risks produce in combination.

Imagine a humanitarian agency working in a crisis where the United States has strategic, military, intelligence, sanctions, donor, or alliance interests. The agency wants to register people for assistance: names, ID numbers, phone numbers, locations, household data, vulnerability information, complaints, perhaps biometrics or payment details. The data goes into systems that sync to SharePoint, back up to OneDrive, coordinate through Teams, exchange through Outlook, analyse in cloud tools, and increasingly summarise or classify with AI features.

Now take the host authority's perspective. You want to put our population's data into systems run by companies subject to the legal process of a state with interests in this crisis? You say the data is in Europe, but the provider is American. You say the provider will challenge requests, but the legal pathway exists. You say we will be notified — maybe. You say the data is protected: show me the keys, the logs, the support model, the sub-processors, the fallback. This is not paranoia. It is governance. The CLOUD Act is public law, Section 702 is public law, export controls are public policy, transparency reports are public, and a competent legal adviser to a host authority can read all of them. The host authority does not need to prove that humanitarian data has been requested. It only needs to decide that the infrastructure creates an unacceptable exposure. That decision can delay registration, trigger demands for local hosting or direct database access, block a platform, or become a condition of permission to operate. And the host authority's preferred answer may be worse: local hosting can be more dangerous, direct state access can be more dangerous, and putting beneficiary data under the control of a de facto authority can be catastrophic. That is why the answer is not to localise everything. It is to understand the exposure before the access negotiation begins.

The closest precedent is not a US-platform case. In 2019, WFP and the Houthi authorities deadlocked over biometric registration and control of beneficiary data, and WFP partially suspended assistance in Sanaa for around two months before a deal was reached. That dispute was not about Microsoft, Google, or the CLOUD Act; it was about who controlled beneficiary data systems, and that is why it matters. It shows the mechanism. A dispute over control of data systems can interrupt assistance, and jurisdictional dependency gives host authorities a new, public, legally legible reason to open that kind of dispute.

A fair critic will push back here, and they should. If the CLOUD Act has been public since 2018, why is there no public case of a host authority denying humanitarian access because an agency runs on Microsoft or Google? True, and it limits the claim. I am not arguing that these disputes are already happening in the open. I am arguing that the legal basis is public, that disputes over beneficiary-data control have already stopped assistance, and that host authorities are becoming more legally sophisticated, not less. Concerns may already surface privately as demands for local hosting, local copies, national platforms, or direct database access, rather than in CLOUD Act vocabulary. Or they may not be surfacing yet. The absence of a public precedent is a limitation, not a refutation.

There is one more asymmetry worth naming. The sector has spent years debating whether WFP's partnership with Palantir compromises humanitarian data governance, and that debate matters. But it has allowed everyone to miss the boring version of the same question. WFP has said that DOTS is an enterprise data platform powered by Palantir Foundry and that Palantir does not have access to beneficiary information, which is held in WFP's own systems. The structural question is wider than one vendor's access to one dataset. Microsoft, Google, AWS, Oracle, and Palantir are different platforms with different architectures, contracts, sub-processors, support models, key-management options, and transparency practices, and the answers will differ, but the question still has to be asked of all of them. Palantir is controversial and visible. Microsoft is everywhere and invisible. Nobody questions running a humanitarian response on Outlook. At the jurisdictional layer, they should.

The sovereignty objection

The standard reply is that this is what security teams are for, and it misunderstands the problem. Security asks who can break in. Sovereignty asks who can lawfully compel, restrict, or interfere. A system can be secure but legally exposed, sovereign but insecure, encrypted but still leaking metadata, hosted locally and still vulnerable to host-state coercion, or EU-hosted with US parent, support, sub-processor, or key-custody exposure. These are different problems, and passing an audit on one says nothing about the other.

The ICRC is the closest comparator, because it has treated data, cyber infrastructure, and data-centre protection as questions of inviolability, privileges and immunities, confidentiality, and neutral humanitarian action, and its Luxembourg agreement contains specific protections for ICRC data and infrastructure. That did not eliminate security risk: the ICRC's 2022 breach exposed data on more than 515,000 people. But the breach was a security failure, not evidence that sovereignty architecture is irrelevant. It proves that if you control more of the infrastructure, you also own more of the security burden. If other agencies have done the sovereignty analysis, they have not made it visible.

And this is where neutrality stops being abstract. An agency can be neutral in mandate, staffing, programming, and intent, but if the infrastructure creates a perceived alignment problem, that may not matter. The theory says neutral; the checkpoint says no. The problem is not that Microsoft or Google make you non-neutral, or that US software is automatically unacceptable. The problem is dependency without governance: relying on infrastructure you have not mapped, in jurisdictions you have not assessed, under laws you have not read, for data you cannot afford to lose, in conflicts where perception decides access.

What good would look like

None of this means abandoning US technology tomorrow. The tools work, the alternatives are limited, and a rushed migration would cause more harm than it prevents. This is not a panic argument. It is a governance argument, and the fixes are organisational rather than technical.

Start with legal exposure. Every data-protection officer should read the CLOUD Act — not skim a summary, read it — and then map what it means for the agency's actual platforms. "Our data is in an EU data centre" is not an answer if the provider is a US-jurisdiction company with possession, custody, or control. A useful review asks boring questions: who is the contracting entity, who is the parent company, where is the data stored, where are backups, who are the sub-processors, where is support delivered from, can the provider access plaintext, who holds the keys, what metadata and logs exist, what is the government-request policy, can notice be delayed, do privileges and immunities apply, are AI features enabled, can they be disabled, and what is the fallback? That is the minimum. If a host authority asks where the data sits and who can reach it, "we use Microsoft" is not an answer. A companion checklist translating this review into a twenty-question operational screening tool is in preparation and will be published separately.

Then diversify deliberately. The sector diversifies funding so that no programme depends on a single donor; the same logic applies to infrastructure. Do not put every critical workflow behind one provider, one jurisdiction, one identity layer, one cloud environment, one AI assistant, and one connectivity route. But do not romanticise the alternatives either. EU providers reduce some US exposure without removing lawful-access risk, local hosting may reduce foreign legal exposure while increasing host-state coercion risk, and self-hosting increases control along with the security burden. Nor is the argument that US jurisdiction is uniquely dangerous; a Chinese, Russian, or EU platform would support a parallel analysis. The problem is that so many of the sector's common dependencies run through providers exposed to the same jurisdiction, and that concentration is itself the governance failure. Sovereignty is a trade-off, not a destination. The right question is not "US or non-US?" but which jurisdiction, provider, key arrangement, support model, and fallback plan match the sensitivity of this operation.

Separate the sensitive. A headquarters budget spreadsheet is not a beneficiary registration database in an active conflict, a public report is not a protection case file, and a logistics tracker is not a biometric record. The highest-risk data should sit in the most controlled environment the organisation can realistically govern. Same principle as the nuclear fuel piece: the most dangerous material needs the most controlled environment.

Train methodology, not products. When agencies adopt AI, they should not train staff into dependency on one interface. They should train methods that transfer across models and providers: verification discipline, source checking, structured workflows, adversarial review, model comparison, fallback practice, and human sign-off. A workflow anchored to one product inherits that product's political and commercial exposure; a workflow anchored to method can move. Full disclosure: I run AidGPT, a responsible AI training programme built on exactly this premise, so I have a commercial interest in this argument and readers should weigh it. The point stands anyway. Product training builds dependency. Method training builds capability.

Plan for degradation, not just shutdown. Most continuity planning imagines the system going down, and that is not the only scenario. An AI feature disappears but email remains, a provider account is frozen during compliance review, a country office is blocked by sanctions screening, a model is available in one country but not another, a host authority demands a local copy, connectivity fails but local devices still work. Donors funding digital transformation could sharpen this with three standard questions: what platforms are you on and who has jurisdiction over them, what happens if access is restricted or degraded, and have you tested the fallback? Not architecture diagrams. Actual fallback.

One fallback is more realistic than it was even a year ago. In a separate benchmark published last month (MarketImpact WP-2026-02), I measured open-weight AI models running locally on a desktop costing under USD 3,000, handling bounded coding and technical-analysis tasks at usable speed and quality. Local models are not a substitute for hosted frontier systems, and that paper makes no parity claim. But they change what degradation looks like. An export control can switch off a hosted service overnight; it does not remove model weights already running on hardware you own.

Finally, prepare for the access conversation. If you work in politically sensitive contexts, assume someone will eventually ask where the data sits and who can reach it, and have the answer before the negotiation. A good-faith authority may be reassured by a clear account of provider jurisdiction, encryption, key custody, data minimisation, and fallback arrangements. A bad-faith authority may not be reassured by anything, and architecture will not stop a pretextual dispute, an armed actor who wants your database, or the need for diplomacy. A jurisdictional review is not a shield. It is preparation, and it gives the agency a stronger basis to refuse dangerous demands for local control, direct database access, or unsafe data-sharing.

The sector treated beneficiary data as an asset until breaches proved it was a liability. It treated communication tools as permanent until commercial decisions proved they were products. It treated AI access as a capability question until export controls proved it was a jurisdiction question. Each time, the sector absorbs the shock, adjusts, and moves on, while the structural condition remains: critical infrastructure on tools the sector does not govern, in jurisdictions it cannot control, under laws it has often not mapped. The nuclear fuel piece asked who controls the data after it has served its purpose. This piece asks who controls everything else. For many common components of the operational stack, meaningful override capacity sits with a short list of providers exposed to the same jurisdiction. That is not a technology problem. It is a governance failure, and it is the sector's to fix — this quarter, while the June outage is still a lesson rather than a rehearsal.

Tom

Thomas Byrnes is the founder of MarketImpact Digital Solutions Ltd, a practitioner-led consultancy working on humanitarian crisis analysis, AI adoption, and digital systems. He runs the AidGPT responsible AI training programme, which trains humanitarian professionals in verification discipline and structured AI workflows across models and providers. This is a governance analysis, not legal advice. If I have got a material fact wrong, I will correct it publicly.

Read the full working paper

This essay is the public-facing version of MarketImpact Working Paper WP-2026-03: Infrastructure Sovereignty and Humanitarian Neutrality: Commercial, Legal, and Political Risks of Jurisdictional Dependency in Humanitarian Digital Infrastructure, which carries the full references, legal discussion, objections, limitations, and practical framework.

ResearchGate: https://www.researchgate.net/publication/408456291_Infrastructure_Sovereignty_and_Humanitarian_Neutrality_Commercial_Legal_and_Political_Risks_of_Jurisdictional_Dependency_in_Humanitarian_Digital_Infrastructure DOI: 10.13140/RG.2.2.29134.63044