Sovereign AI

One of our agent workflows stopped working after a vendor changed its permission policy. We hadn't touched the workflow.

The agent extracted text from internal images and carried out the instructions it found there. It ran in Claude Code's auto mode, which decides whether an action can proceed without asking the user. After Anthropic changed what that mode allowed, the same task no longer ran reliably.

The vendor's definition of safe had moved, and our workflow moved with it.

It was a small disruption, but it exposed a bigger dependency. Agents now read email, run commands, spend money and start other agents. Companies give them real work and real access. They need to be able to set the rules that come with both.

No company would ask a staffing agency to write its security policy. Yet buying an AI product can amount to buying the intelligence, the workplace and the rules together.

At Apoco, we think sovereign AI comes down to two rights.

• The right to decide. You choose where your data goes, what your agents may do and how much they can spend.
• The right to change your mind. You can move to another model, tool or vendor without leaving your work behind.

Neither requires a company to train its own models or own every GPU. The question is which decisions it keeps. A product can carry the label "sovereign" and still make it difficult to leave [1].

Three ways to lose control

Buy a product that decides for you. Using a vendor's model is often a sensible choice. The problem starts when its harness, permissions, billing and data policies come as an inseparable package. Decisions made for the vendor's entire customer base become decisions about how your company works.

Build on it until leaving costs too much. Skills, workflows, memory and evaluations accumulate with every month of use. They contain the company's know-how. When all of it lives inside one product, a better model or a price increase may no longer be enough reason to move. The migration itself costs too much.

Offer nothing. People still need to get their work done. If the company gives them no useful AI tools, they bring their own and paste company data into consumer products. The company loses control without ever making a purchasing decision.

Building everything yourself won't solve all of this. We use seven checks to work out which decisions a company needs to retain. The first four concern how agents operate today. The last three concern what happens when the company wants to change its approach.

The right to decide

Before giving an agent more autonomy, a team needs to know what it can reach, what it may do, how to inspect its work and how to limit its spending.

1. Boundaries you set

An agent may have access to private data while reading untrusted emails or web pages. It may also be able to act on what it reads. A malicious message can exploit that combination to get information out of the company. Guardrails help, but as Simon Willison puts it, "in application security, 99% is a failing grade" [2].

Boundaries limit the damage when a guardrail fails. Companies already do this for people. Employees get the access their work requires, and sensitive information comes with restrictions on how it can be used. Agents need the same discipline.

It helps to picture the agent's environment as a room with doors.

The room is its workspace, where it reads files and runs tools. Hosting that workspace inside the company doesn't automatically keep the data there. Each model call may include instructions, file contents and tool results. If the model runs outside the company, that information leaves the workspace. Some cloud products also copy code onto the vendor's machines before they begin work.

For sensitive workloads, both the workspace and the model may need to run inside the company's environment. Other work can use external services. The company needs to be able to make that choice for each workload.

The doors are connections to other systems. Some permit reading, some permit changes, and some require a person's approval. An agent might read company email but need permission to send a reply. It might read internal documents while being blocked from passing their contents to an outside model.

Those rules can depend on which connections are active. Connecting an agent to company email could block outside models and web search, and require approval before sending messages. The platform enforces the restriction even if the agent tries to do something else.

With these boundaries in place, a company can give an agent a whole computer to build and test on while limiting what a mistake can affect. Without them, teams often have to keep agents away from the work where they would be most useful.

2. Security policy you write

Access alone doesn't settle what an agent should be allowed to do. Can a coding agent delete a branch, merge a pull request or deploy to production without asking? Should it act on a request found in a customer email?

These decisions often sit inside the vendor's tools. A software update can change them, as it did in our workflow.

Different jobs need different policies. A documentation agent may browse freely. A coding agent may create branches and open pull requests but need approval to merge. A production agent may inspect deployment systems without permission to change them.

The company should define these rules and keep them outside any one harness. A policy for reviewing code should apply to every agent doing that job, regardless of which model or tool runs it. Switching tools shouldn't mean writing the same policy again.

3. Records you can inspect

Before expanding an agent's permissions, its owner needs to see what it did with the access it already had. Records make that judgment possible. They also provide evidence when an auditor or regulator asks how a decision was made.

For each agent, the company should be able to identify its owner, the systems it accessed, the actions it took and the information it relied on. Owners need access to traces and spending without having to become infrastructure administrators.

Debug logs rarely tell the whole story. Records available only through a vendor's console can also disappear when the company moves elsewhere. Keeping a usable history should be part of operating the system from the start.

4. Costs you can see, cap and optimize

An agent can call several models, start subagents and keep running after its owner has gone home. A single monthly bill won't tell you which of that work was worth paying for.

Teams need spending broken down by agent, model and workflow, with limits that stop work when a budget is reached. A dashboard can show a runaway bill. It can't prevent one.

IBM's CEO Arvind Krishna has argued that a supplier-owned AI operating layer can leave customers buying metered consumption while the supplier retains control [6].

We've also seen how much an agent can do to reduce its own costs. One of our hourly agents was spending about $6.25 per run, roughly $150 a day. When someone flagged the bill, the agent traced the cost to an instruction that loaded a 1 MB dashboard file into every session. It removed that instruction. The next run cost $0.53.

A person noticed the bill. The agent found the cause.

We now run an agent that watches for spending spikes and recommends what to review. We're also building agents that monitor security advisories and help choose models and harnesses for different jobs.

There are further savings in scheduling work during cheaper periods, using available models more efficiently and caching information that would otherwise be sent repeatedly. Agents can help find those opportunities when they can inspect their own costs.

The right to change your mind

The first four checks concern today's operations. The next three ask whether the company can change the system without losing what it has built.

5. Models and harnesses you can swap

The best model for a task can change quickly. In its July 2026 coding benchmark, Databricks reported that the open model GLM 5.2 matched Opus 4.8 on quality at $1.28 per task rather than $1.94. Changing the harness more than halved costs in some comparisons while maintaining quality [3].

Krishna described a similar choice in an IBM test. An open-weight model sped up a quantum hardware design 52-fold for $26 in inference. A leading proprietary model achieved a 204-fold improvement but cost $299. Which result is worth paying for depends on the job [6].

Plenty of agent work involves narrower decisions, such as classifying tickets or routing cases. Jev's maker reports speeds 40 to 200 times faster than frontier models on certain structured decision tasks [4]. Open alternatives are being developed too [5]. These results don't make one model right for everything. They give companies more options to test against their own workloads.

The harness matters as well. It controls how the agent manages context, uses tools and applies permissions. Replacing a model while staying tied to the same harness leaves much of the dependency intact.

Skills, policies and workflows should survive a change of either. Otherwise, trying a new model becomes a migration project instead of an evaluation.

An advisor agent could help with that evaluation. It could run the company's own tasks against available models and harnesses, compare quality and cost, and repeat the exercise when a new option becomes available. The decision would rest on the company's work rather than a vendor's benchmark.

6. Building blocks you own

Running an agent is only part of the job. Running many agents across a company requires infrastructure that teams can manage and change. Four building blocks account for much of it.

• Persistent agents keep their workspaces between runs and pick up where they left off.
• Schedules let agents run periodically, with a lightweight check for new work before a full run starts.
• Connections give agents access to company systems without handing them the credentials.
• Subagents let an agent delegate a task with only the permissions that task needs.

When these building blocks are tied to one vendor, the workflows built from them inherit that dependency. Keeping control of them lets a team assemble different systems for different jobs. One model might plan, another implement, and a third review. Routine work can use a cheaper combination while harder tasks use a more capable one.

Connections have been the most difficult part of our own work. Researchers ask us to connect agents to internal license servers, compute clusters and lab machines. These systems sit behind deliberate access restrictions. Making an agent useful there requires more than opening a port.

Access may need to follow the identity of the person who owns the agent. Credentials may need to expire quickly. Some tasks may need a worker inside the protected network rather than a connection reaching into it. Single sign-on, temporary credentials and workers in the right environment all have a place. Which combination works depends on the systems and the people responsible for them.

7. Knowledge you can take with you

An agent that works with a team for months accumulates more than files. It learns what a useful code review looks like, what a customer means by "urgent" and which reports leadership actually reads.

People carry much of this knowledge in their heads. For agents, much of it lives outside the model, in memory, skills, instructions and evaluations. That makes it possible to copy it, share it across teams and reuse it with a different model. Agents as Teammates explores this in more detail.

But the company needs a reliable way to get that knowledge out. In one migration between AI assistants, the export amounted to asking the old assistant to "tell me everything you know about me" and pasting the answer into the new one. It partly worked. It was hardly a migration guarantee.

Before committing to a product, a company should check whether it can export memory, skills and evaluations in a form another system can use. A skill should remain useful after its author changes teams. A new hire should be able to use the team's accumulated experience. And when a model changes, the company's evaluations should show whether it still does the job well.

Changing tools shouldn't erase what the team has learned.

How much control do you need?

Running your own platform takes people and resources. Open models aren't the best choice for every task. A team using AI to brainstorm has different needs from one giving agents access to customer records or permission to act on the company's behalf. A vendor product may be a good fit for much of that work.

Start with the workloads where a mistake would matter most. Look at the data involved, the actions an agent can take and the decisions delegated to the provider. Then ask what it would take to change that arrangement.

Put it to the test

Pick one workflow your company relies on and work through these questions. You don't need seven perfect answers. You need to know where control sits and whether you're comfortable leaving it there.

Each "no" identifies a dependency to examine. Some will be acceptable. Others may be a reason to change the design before the workflow grows harder to move.

We're still working through these questions ourselves. Connections remain difficult, and we don't yet know how much of our current work smaller, specialized models will be able to handle.

Our work on DAM (Deploy Agents Massively) with IBM Research puts these ideas into practice. The open-source repository provides an implementation to inspect, and the project discussion is open for questions and other approaches.

At Apoco, we help teams work out which parts of an AI system need to stay in their hands. The answer will differ by workload and will change as the tools improve. Keeping the ability to make that decision again is the point.

References

1. Stanford HAI, “The Commercial Landscape of AI Sovereignty Offerings”, issue brief by C. Meinhardt, J. N. Pava, C. Yee and J. A. Landay, July 2026.
2. Simon Willison, “Prompt injection explained, with video, slides, and a transcript”, May 2023.
3. Databricks, “Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase”, July 2026.
4. TypeSafe AI, “Introducing System One Models & Jev”, September 15, 2026.
5. Kev, “Jev-like family of decision models built on top of Qwen3.5/3.8 you can train and run on your own”, Apache-2.0.
6. Arvind Krishna, “Rationing AI is a slow way to lose”, Fortune, November 5, 2026.