Sovereign AI is the right to change your mind

For years, "sovereign AI" has mostly meant geography: where the GPU sits, where the data is stored, and whose jurisdiction applies. Those things matter. But agents make sovereignty a much larger problem. An agent does not just process data. It executes code, uses credentials, spends money, makes decisions, calls tools and other agents, and increasingly acts on behalf of the organization. Once AI can act, sovereignty is no longer only about where intelligence runs. It is about who gets the final say over how that intelligence behaves.

Our definition: an organization is sovereign over its AI when it can decide where agents execute, what they can reach, which models and harnesses they use, what they are allowed to do, how much they may spend, how their actions are observed and audited, and what organizational judgment they encode. And when it can change any of those decisions without rebuilding its AI estate or asking a vendor for permission.

Sovereignty is not the absence of dependencies. It is the ability to govern, observe, replace, and exit them. An organization may deliberately use Anthropic today, OpenAI tomorrow, a private endpoint for one business unit, and an open-weight model on internal GPUs for a classified workload. Sovereignty is the layer that lets the organization keep making those decisions.

We build and run Deploy Agents Massively (DAM), an open-source platform for running agents with any harness and any model on Kubernetes. This note is the view that running it in production has given us. We see eight rights an organization has to hold. Lose one, and a vendor holds it instead.

The right to place

You choose where AI executes and what boundary contains it. Some workloads are fine on public SaaS. Others are not: source code for a sensitive acquisition, incident-response data, production credentials, customer data, the crown jewels. Those need dedicated clusters, private model gateways, region-constrained execution, or environments with no external egress at all.

This is infrastructure, not prompting. A prompt saying "do not exfiltrate this repository" is not a security boundary. A network that physically cannot exfiltrate it is. In DAM, credentials never enter the agent's sandbox: a paired gateway injects them at the network exit, and Kubernetes NetworkPolicy restricts everything else (security and credentials).

The right to replace

Today's AI products bundle several things: a model, an agent loop, tool-use semantics, context management, permissions, memory. When an organization builds directly around one bundle, switching the model does not remove the deeper dependency on the harness.

Claude Code, Codex, Pi, tomorrow's best open-source harness, and your own internal agent should be workloads on your AI infrastructure, not the infrastructure itself. We do not promise a vendor-free world; that promise is not credible. The stronger claim is narrower: we refuse to make any single vendor irreplaceable.

The right to constrain

Two policy layers, and organizations need both. Behavioral policy asks: should this agent perform this action? Human approval before deleting production data, no shell commands triggered by untrusted content, extra approval past a risk threshold. Infrastructure policy asks: can this process physically perform this action even if the model tries? Egress allowlists, credential brokering, filesystem boundaries, workload isolation.

A policy system cannot simply maximize restriction. A "trusted defaults" network preset once blocked routine package-registry access in our own deployments (issue #3818), and we have had to decide whether an instruction from an authenticated owner on Slack counts as trusted input (issue #3846). The point of sovereignty is that your organization chooses the frontier between autonomy and approval, per workload: a marketing research agent with broad internet and no internal credentials, a production agent that inspects everything and mutates nothing without approval, a crown-jewel agent on internal models with no egress. The important word is your. Those rules should outlive whichever model or harness executes the task.

This is the zero-trust argument applied to agents: authorization granted per identity, resource and workflow, never implied by being inside a perimeter (NIST SP 800-207). The agent should be powerful inside a boundary it does not control.

The right to inspect

Sovereignty without visibility is nominal. You cannot claim to control autonomous systems when nobody can reconstruct what happened, how a tool was called, why work failed, or where money went. We learned this the direct way: agent owners described their own agents as a "black box" because traces and spend existed internally but were not owner-accessible, so we made them owner-visible without cluster access (issue #3489). Auditability is not a compliance feature added after autonomy. It is a prerequisite for granting autonomy.

The right to budget

Dependency is also economic. An organization should be able to answer: which teams and workflows consume AI, what a successful outcome costs rather than a token, where a frontier model earns its price, which tasks could move to a smaller or internal model, and what a fan-out to five subagents costs at the margin.

Then it needs to act on the answers: enforced caps, not dashboards. Our own honesty check is public: DAM's budgets initially capped concurrent compute but not actual model spend, which is the difference between reporting cost and bounding it (issue #3428). A sovereign platform lets the organization define its own optimization function: absolute quality, latency, cost, or an escalation ladder where the expensive model is called only when the cheap one is unsure.

The right to encode judgment

Buying an AI product off the shelf increasingly means buying the vendor's opinion about how work should be done: when an agent asks permission, which tools are trusted, how code is reviewed, what a good answer looks like. Organizations have their own opinions. A bank has one about acceptable software changes; a pharma company has one about evidence; your engineering organization has one about review depth and technical debt. Those opinions are institutional IP.

Our concrete lesson: when reviews from our code-review agent got noisy, the fix was not a different agent. The agent itself has no opinion on what a review should look like; the skills we wrote determine the scope and relevance of findings (issue #3568). The model is not your AI strategy. Your skills, policies, evaluations and accumulated operating judgment are. A sovereign organization can swap the model without losing its definition of how work is reviewed. Rent intelligence; own judgment.

The right to compose

Once models and harnesses are interchangeable components, the question stops being "which agent is best" and becomes "what topology produces the best outcome for this task". A planner on one model, an implementer on a code harness, an independent reviewer on another vendor. A cheap worker with an expensive advisor. The same question sent to two models, with a third paid only to adjudicate disagreement.

Sovereign multi-agent infrastructure is not a chat room full of personas. It is governed delegation between isolated workloads with explicit interfaces, permissions, budgets and provenance, so that the whole tree runs under common credentials, limits and audit.

The right to survive and scale

Finally, the boring realities. Persistent agents consume compute, get stuck, fan out, and fail. Sessions get killed under memory pressure; a wedged background task can hold capacity for hours. If those events are visible only to the platform operator, the owner does not actually operate the system; they nominally own it. Capacity, scheduling, hibernation, throttling and recovery are sovereignty concerns for the same reason budgets are: they decide whether the organization is in charge of its own estate.

What to do with this

Sovereign AI does not mean building every model, owning every GPU, or refusing every cloud provider. It means preserving the ability to choose: where an agent runs, which model reasons, which harness acts, what it can reach, what requires a human, what "good" means, how much you will spend, how agents collaborate. And when the market changes, as it certainly will, to choose again.

For your own organization, pick one workload and walk the eight rights against it. Where a right sits with a vendor, ask what exercising it would cost you today; that price is your real lock-in, whatever the contract says. That is sovereignty: not owning every dependency, but owning the decisions that matter.

Notes and references

[1] Deploy Agents Massively, public repository, with documentation for security and approval controls. The deployment examples and the linked issues are our experience of building and running the platform.

[2] NIST, SP 800-207: Zero Trust Architecture. The principle that trust is never implied by network location.