Article 記事

The global battle for sovereign agent infrastructure: narratives, capital and standards

author Jonathan Conway
timestamp 1 June 2026
classification sovereignty / sovereign-ai / agent-infrastructure / eu-ai-act / open-standards / oamp / regulated / geopolitics

A government minister from a mid-sized European nation told a conference audience in early 2026 that her country’s most sensitive administrative decisions were, at that moment, routed through inference endpoints hosted on servers physically located outside her jurisdiction, operated under a legal regime that made their contents accessible to a foreign government on request (source: European Parliament Committee on Civil Liberties hearing, February 2026). She was not describing an edge case. She was describing the default configuration of most enterprise AI deployments running anywhere in 2026.

That is the problem in one sentence. The moment you build a production system on top of an API you do not own, in a data centre you cannot enter, under a legal framework you cannot override, you have not built sovereign infrastructure. You have built a very expensive dependency. The social media era taught this lesson slowly and at great cost: convenience plus centralisation produces infrastructure that eventually serves the platform’s interests, not yours. AI is going to teach it faster, because the stakes are higher and the surface area is much larger.

The global conversation about sovereign agent infrastructure is not one conversation. It is three, running in parallel, sometimes talking past each other, but converging on the same destination. Understanding all three, and where they agree and disagree, is prerequisite knowledge for any organisation making infrastructure decisions in 2026.

The three narratives

The first narrative is national. It is the one ministers talk about. Large economies are making explicit bets on owning the compute stack: the data centres, the chips, and increasingly the models. India’s trajectory is illustrative. Reliance’s commitment to domestic AI infrastructure, combined with the government’s national data centre programme, reflects a calculation that strategic dependency on foreign inference pipelines is a geopolitical liability (source: Reliance Industries investor communications, 2026; India MeitY national AI strategy documents). The same logic is being played out with different vocabulary in the Gulf states, in South Korea, in Brazil. The common thread is a recognition that AI is critical national infrastructure, and critical national infrastructure should not route through someone else’s billing API.

The second narrative is regulatory. Europe is the clearest example because it has moved furthest from aspiration to law. The EU AI Act, which comes into full enforcement for high-risk systems in August 2026 (source: EUR-Lex, Regulation EU 2024/1689, Article 6 and Annex III), requires that logs be maintained over the entire operational lifetime of a high-risk AI system, covering risk situations, substantial modifications, and post-market monitoring. DORA (Digital Operational Resilience Act) adds requirements around ICT third-party concentration risk, which in practice means that a regulated financial entity with a single-vendor AI dependency now has an explicit regulatory problem. These requirements do not mandate sovereignty in so many words. They mandate auditability, traceability, and resilience in ways that are structurally very difficult to satisfy if your inference stack is someone else’s black box. The result is the same.

The EuroStack movement, not yet a formal institution but a growing coalition of European technology policy voices and vendors, is pushing towards a federated, open, EU-hosted alternative to hyperscaler dependence (source: EuroStack initiative, eurostack.eu, 2025-2026 position papers). Its influence on procurement language is already visible in public tender documents across France, Germany, and the Netherlands. Phrases like “data residency within EU borders” and “auditability of model inference” are appearing in sections that used to say nothing about AI at all.

The third narrative is harder to characterise. Call it the digital sovereignty movement, which encompasses a range of positions from cryptographic user ownership of data and agents through to token-powered inference and memory networks. Projects like NEAR’s work on user-owned AI agents are experiments in a different kind of sovereignty: not national sovereignty over infrastructure, but individual sovereignty over the agents that act on your behalf (source: NEAR Foundation, “User-Owned AI” position paper, 2026). This thread matters for enterprise infrastructure conversations less as a direct model and more as a leading indicator of where expectations about data ownership, portability, and auditability are going to land in the mainstream within a few years.

These three narratives are not the same thing. A national government building a sovereign inference cluster does not share all its motivations with a crypto collective building user-owned agent protocols. But they share a thesis. The substrate that runs the agents must be ownable, auditable, and controllable by the people it serves.

Interactive: hover or click legend entries to show and hide series. Toggle the regulated-enterprise lens to see how governance axes shift in weight for a high-risk EU/UK buyer. The radar makes the structural gap between Substrate and each class of comparator visible as a shape.

The narrative war in the infrastructure market

The centralised frontier lab model has obvious advantages. The models are better (for now) on many benchmarks. The APIs are easy. The time to first working prototype is short. For a team that needs a demo in two weeks, it is the rational choice.

The problem is that a demo is not production for a regulated buyer. The journey from “impressive demo” to “the CISO, CRO, and Head of Audit have all signed off and this is running against real data” is where centralised frontier stacks start to accumulate structural problems that cannot be patched after the fact.

The first problem is data residency. If the inference happens on a server in Virginia, your EU personal data has left the EU. The standard legal mechanisms (SCCs, adequacy decisions) are not comfortable to rely on for sensitive regulated data, particularly in a political climate where they are contested (source: European Data Protection Board guidance on data transfers, 2025). You can work around this with data preprocessing, tokenisation, and various scrubbing approaches, but each workaround is a layer of complexity and a new attack surface.

The second problem is auditability. Under EU AI Act Article 12, the operator of a high-risk AI system is responsible for maintaining logs that cover the lifetime of the system. If the inference happens in a black box, what exactly do those logs cover? The inputs and outputs, perhaps. Not the model state, the context window at inference time, the routing decision, or the version of the model that was running. The audit trail you can construct around an external API is thin.

The third problem is concentration risk. DORA Article 28 requires financial entities to manage ICT third-party concentration risk. An architecture where your production AI pipeline has a single critical dependency on one hyperscaler’s inference API is, by the letter of the regulation, something your risk function needs to have an opinion on. The answer “we have a contract” is not the same as the answer “we have resilience.”

The open-standards and sovereign-stack movement offers a different architecture. The inference runs on hardware you control. The models are weights you own or can reproduce. The audit log is generated by your own system and is tamper-evident by construction. The supply chain is signed and you can reconstruct any historical state exactly. The tradeoff is that building and operating this is harder than calling an API, which is why the “governed by construction” framing matters: the complexity has to be owned somewhere, and the claim of purpose-built infrastructure is that it absorbs the hard parts so the regulated enterprise does not have to build them from scratch.

This is not a call for autarky. The frontier labs produce genuinely excellent models and there are many workloads for which using their APIs is the right choice. The correct architecture for a sophisticated regulated enterprise is one where owned open-weight models handle the bulk of production inference, and frontier API access is reserved for tasks that genuinely require it, used as opt-in failover rather than dependency. The Substrate sovereign section on the homepage describes this precisely: “no data leaves the walls; no single provider outage can take the factory offline.”

Standards and soft power

Standards battles are slow and unglamorous. They are also where the long game is won.

HTTP did not just define how web pages were transferred. It defined who could participate in the web, what you could build on top of it, and ultimately who had power over the ecosystem. The agent infrastructure layer is at a similar inflection point. Whoever defines the protocols for how agents communicate memory, how they declare capabilities, how their actions are signed and verified, will have substantial influence over what is interoperable and what is not.

OAMP (the Open Agent Memory Protocol) is one attempt at this. Its goal is to define a standard interface for agent memory that allows different memory backends to interoperate: bitemporal queries, provenance fields, capability discovery, and cryptographic delete operations. The significance of this for a regulated buyer is that it breaks the coupling between “the memory backend I can audit” and “the memory backend I am locked into.” An organisation that has built its compliance workflows around bitemporal queries and signed provenance chains can, in principle, swap out the underlying memory implementation without losing its audit properties. That portability is valuable and is the kind of thing that makes a standard worth adopting even before everyone else has adopted it.

MCP (Model Context Protocol) is a parallel effort, more focused on tool and context access. Kizuna’s MCP policy gateway implements a deny-by-default policy enforcement point for tool access: agents can only use tools that are explicitly permitted, and every use is logged. This kind of policy layer at the protocol level is what turns “agents can use tools” from a security concern into something a CISO can sign off on.

Signed artifacts are a third axis. When a Kizuna commit is signed by a cryptographic agent identity (Ultra-issued Ed25519 key), the provenance of that artifact is verifiable regardless of which system later consumes it. This is supply-chain integrity at the agent layer, and it is the kind of property that is much easier to demand in an RFP if there is an open standard describing what a signed artifact looks like.

The soft power angle is this: a regulated buyer who builds their workflows on top of OAMP-compliant memory, MCP-gated tools, and signed artifacts from a Kizuna-compatible forge has, in practice, created a migration path away from any single vendor, because the compliance properties travel with the standard, not the implementation. This is the boring-but-critical layer. Nobody wins a conference talk explaining it. Several regulated enterprises lose a great deal of money not understanding it.

Interactive: click “simulate provider outage” to see the factory continue running on owned models inside the walls. Toggle air-gap mode for fully disconnected operation. This is the deployment topology that satisfies DORA concentration-risk requirements and EU data residency rules simultaneously.

Capital flows: where the money is going

The sovereign AI investment thesis is maturing from narrative to capital allocation. A few patterns are visible from public information.

Sovereign wealth funds and national development banks in several jurisdictions have started treating domestic AI infrastructure as a strategic asset class, not unlike energy infrastructure. This means patient, long-horizon capital with a tolerance for complexity and a preference for depth over breadth, which is a different investor profile from the growth-at-all-costs venture rounds that shaped the first wave of AI startups.

Defence and intelligence procurement, particularly in NATO-aligned countries, has been pulling hard on sovereign, air-gappable AI infrastructure since before the current public conversation caught up. The requirement is simple: the system has to work when the network is gone, the models have to be auditable without relying on a vendor’s word, and the action log has to be tamper-evident without relying on a third-party logging service. These requirements, which sound exotic in a startup context, are simply table stakes for the markets that need them most.

Regulated enterprise procurement (financial services, healthcare, government) is the third major capital pool. This is the market that the Substrate dark factory is built for. The pattern here is that the procurement cycle is slow and the requirements are specific: EU AI Act compliance documentation, DORA evidence packs, FedRAMP or IL-4/5 equivalents for US federal buyers, Crown Commercial Service alignment for UK public sector. The organisations that can credibly speak to these requirements, with owned infrastructure and a governance-by-construction architecture, are rare. The organisations that are already in those procurement conversations are building a moat that takes years to build.

What these three capital pools share is a preference for depth over convenience. They are not looking for the fastest path to a working demo. They are looking for the infrastructure that is still running, still auditable, and still sovereign five years from now when the regulatory environment has tightened and the geopolitical situation has changed in ways that are hard to predict today.

Sector walkthroughs

Government and critical infrastructure. A central bank or intelligence agency running production AI workloads has, broadly, two options. Option one is to run everything on domestic infrastructure with owned models, which is fully sovereign but limits model quality and requires significant operational capability. Option two is to use frontier APIs, which gives excellent model quality but creates the data residency, auditability, and concentration-risk problems described above. The architecture that Substrate provides is a third option: owned open-weight models on sovereign infrastructure as the production baseline, with frontier API access available as an explicit opt-in for specific tasks where the data sensitivity permits and the model quality differential justifies it. The EU AI Act compliance mapping is built into the system by construction. The DORA concentration-risk answer is structural, not contractual.

For a government agency evaluating alternatives to closed proprietary platforms: the head-to-head comparison on openness, auditability, and sovereignty is the relevant lens, and the sovereign alternative to Palantir-style platforms post goes through that comparison in detail.

Financial services. A tier-one bank with significant cross-border operations has data residency obligations in multiple jurisdictions, DORA requirements that apply to its AI pipelines from the start of 2025, and EU AI Act obligations coming into force for its high-risk systems in August 2026. The correct infrastructure answer is not the same in each jurisdiction, which is exactly why deployable-anywhere, owned infrastructure with jurisdiction-configurable data residency settings is structurally different from a single global API endpoint. Ninmu’s per-mission budget ledger solves the cost-governance problem that the Gartner cancellation-wave prediction is pointing at. Kizuna-mem’s bitemporal memory with signed provenance satisfies the “what did the agent know and when” question that will come up in any serious EU AI Act audit. The EU AI Act Article 12 post covers the specific logging requirements in detail.

Healthcare. Clinical coding, claims processing, and prior authorisation appeals are all workflows where AI can dramatically reduce cost and cycle time, and where the auditability and sovereignty requirements are as demanding as anywhere in the regulated world. The specific wrinkle in healthcare is patient data: personal health information (PHI) under HIPAA, special-category data under GDPR, and increasingly national data localisation requirements in non-Anglophone markets. An inference pipeline that sends PHI to a foreign cloud endpoint for processing is, in most of these frameworks, not compliant by design. Owned models, on sovereign infrastructure, with hard-delete capability for GDPR erasure requests, is the only architecture that satisfies the full set of requirements without creative legal interpretation.

The long moat of boring infrastructure

There is a romantic version of this story in which the winner of the sovereign AI infrastructure battle is whoever builds the best model or runs the most dramatic public demonstration. That is not how infrastructure markets work.

Infrastructure markets reward reliability, auditability, and interoperability. They reward organisations that show up in the boring parts of procurement processes with the right documentation and the right compliance mappings. They reward software that does not have surprises in production at three in the morning. The 790,000 lines of owned Rust and Elixir code across Ninmu, Cosmictron, Kizuna-mem, Ultra, Kizuna, and Voxeltron are not a marketing number. They are a description of the surface area of a system that has been designed from the ground up for the hard properties, rather than retrofitting them onto a foundation that was built for speed and convenience.

Voxeltron’s sub-50-millisecond cell boot time and support for approximately ten thousand idle cells per host is relevant not because it is an impressive benchmark but because it is the economic foundation that makes sovereign, on-premises agent deployment viable. If your compute fabric cannot handle the density that agent workloads require, the unit economics of sovereign deployment are too expensive. Once you can land ten thousand idle cells on a single host, the cost equation changes. The infrastructure that seemed impractical becomes practical.

Cosmictron’s 2,326 agent actions per second at 0.43 milliseconds on a single node matters for the same reason. Sovereign infrastructure that cannot keep up with the throughput demands of production agent workloads is not really a choice. It is a constraint. The throughput number combined with the density number means that a regulated enterprise can run a production-scale governed agent factory on hardware it owns, without needing to scale to hyperscaler proportions to get there.

This is the boring-but-critical infrastructure layer. It does not make conference talks easy. It does make regulated enterprises willing to sign procurement contracts.

The composable agents and open standards post covers the protocol layer in depth. The hardware implications of the agentic wave covers how the compute density story plays out against the broader hardware market. The six systems as one factory covers why the governance properties of the factory are emergent from the whole system rather than features of individual components.

What to demand in an RFP

If you are writing or evaluating a procurement for agentic AI infrastructure in a regulated context, the sovereignty and auditability questions separate architectures that can satisfy the requirements from ones that will need creative workarounds.

Ask whether the system can run with no external dependencies at all, including for inference. The answer should be yes, today, not “we are working on an on-premises offering.” Ask to see the deployment topology for an air-gapped environment. Ask what changes in the governance guarantees when the frontier failover is switched off. Nothing should change, because the governance properties should be a function of the factory architecture, not the inference endpoint.

Ask what data residency guarantees the system provides by design, not by contract. A contractual promise from a foreign provider that your data will not leave a specific jurisdiction is not the same as an architectural guarantee that the inference happens on hardware in your building. In 2026, a growing number of regulators and procurement offices understand this distinction.

Ask to see the EU AI Act Article 12 compliance mapping for the specific system they are proposing. Ask whether it covers the operational lifetime of the system, not just the run of a single query. Ask what the tamper-evidence mechanism is for the audit log and whether it depends on a third-party service. A system where the audit log’s integrity can only be verified by calling a vendor API is not audit-ready in the sense that a regulator will care about.

Ask about the standards the system implements for interoperability. A system that has no support for open protocols for memory, tool access, or artifact signing is a system that is building lock-in into every layer of your compliance architecture. That is a problem that compounds.

A 90-day pilot design

You do not need to commit to sovereign infrastructure before you have tested it. The right 90-day pilot has three phases.

In the first thirty days, deploy the factory on infrastructure you control with its full sovereign configuration: owned models, air-gap mode enabled, frontier access switched off. Run one high-pain regulated workflow that you already have a cost and cycle-time baseline for. A quarterly control test, an AML evidence pack, or a claims processing backlog all work. Establish that the factory produces signed, auditable output that your internal audit function can read and evaluate.

In the second thirty days, run the EU AI Act Article 12 mapping exercise. Take the audit log produced by the factory in the first phase and map each event to the specific logging requirement it satisfies. Identify any gaps. In a well-governed factory, this exercise should take days, not months, because the log structure was designed for exactly this purpose.

In the third thirty days, run the concentration-risk analysis for DORA. Document the third-party dependencies of the infrastructure and the failover behaviour when each one is removed. If the factory continues operating without degradation when the frontier API is switched off, you have your answer to the DORA question. If it does not, you have identified an architectural dependency that needs to be resolved before production.

Three numbers tell the story at the end of ninety days. The cycle time reduction on the pilot workflow. The cost of the signed, audit-ready output relative to the manual baseline. And the number of third-party dependencies that can be removed without losing governance properties.

The thesis, stated plainly

The battle for sovereign agent infrastructure is not primarily a technology competition. The technology exists. The open-weight models are good enough for most production workloads. The infrastructure to run them at the density and throughput that agent systems require has been built. The cryptographic identity and audit log machinery that makes “signed and auditable by construction” a real property rather than a marketing phrase is available.

The competition is for the trust and the procurement cycles of the regulated buyers who need this infrastructure most. That competition is won by organisations that show up with the right compliance documentation, the right architecture, and the right understanding of the regulatory environment. It is won slowly, in procurement rooms, not quickly, in product announcements.

The open-standards layer matters because it is where the regulated buyer gets protection against the infrastructure layer becoming its own centralised control point. A factory that speaks OAMP and MCP and produces Kizuna-compatible signed artifacts is a factory that the buyer can, in principle, extend, modify, and eventually migrate, without losing the compliance properties they built their workflows around. That portability is the long moat.

AI without sovereignty is a centralised control point. The social media lesson, applied to infrastructure that runs your compliance workflows and moves your capital and governs your casework, is one that nobody in a regulated vertical should need to learn the hard way. The infrastructure that sits at the intersection of serious regulated buyers and the open-standards movement is the infrastructure that survives the next political and regulatory cycle, whatever form that cycle takes.

The mission is clear. The factory is ready. Request the investor brief at /substrate to see the deployment architecture, the compliance mappings, and the head-to-head against the incumbent alternatives.


This post synthesises themes developed across the dark factory wave. For the technical depth on specific components: sovereign AI, air-gapped by default for the deployment architecture; sovereign alternative to Palantir-style platforms for the head-to-head procurement comparison; composable agents and open standards for the protocol layer; hardware implications of the agentic wave for the compute density economics; six systems as one factory, not a stack for why the governance properties are emergent from the whole.