Where it runs is not who decides
"Runs on your infrastructure" is about to become a claim almost every AI vendor can make, and it will mean four different things. The question that separates them is not where the work executes. It is which plane still belongs to the vendor.
In August 2026 Anthropic shipped self-hosted environments for Claude Code: cloud sessions that execute on your own runners, inside your own network.
This is a good thing and it validates a direction we have been arguing for two years. The model vendor itself concluded that enterprises need agents running inside their own perimeter.
It is also the clearest illustration available of a distinction that is about to matter to every AI purchase you make, and Anthropic deserves credit for stating it plainly in their own documentation rather than letting the marketing blur it:
a self-hosted environment moves session execution into your network, not the control plane
Read that twice. It is the most useful sentence published in this category this year.
Two planes#
Every agent system has two of them, and they can live in different places.
The execution plane is where the work happens. The checkout, the file writes, the shell commands, the compute.
The control plane is where the decisions live. What tools exist, what the agent is permitted to do, what the queue looks like, what gets recorded.
Moving execution is a real and valuable engineering achievement: your source no longer needs to be copied to a vendor's disk to be worked on. But the two planes are separable, and when a vendor says "it runs on your infrastructure," only one of them has necessarily moved.
In Anthropic's case they are explicit about what stayed: the queue, the stored transcript, and the permission rules. Their docs say the control plane sends each session's tool list and permission rules along with the work payload. Inference stays pinned to their API and is explicitly not routable through Bedrock, Vertex, Foundry or a gateway of your own. Prompts, responses and tool results still travel.
So the checkout and the on-disk artifacts are yours. The decision about what the agent may do is still theirs, and anything the agent reads out of an internal system leaves anyway.
Why this is about to get confusing#
"Self-hosted" is becoming table stakes as a phrase, and it is going to be used for at least four different architectures:
- Execution on your infra, control and record with the vendor. The above. Your compute, their decisions.
- A vendor's software on your infra, phoning home. Runs in your VPC, still requires their cloud to make a decision or to store the record.
- A single-tenant instance the vendor operates. Your data is isolated, and the operator is still someone else.
- The whole thing on your infra, including the decisions and the record. Nothing needs to reach the vendor for the product to work.
All four will be described with the same two words. The difference between one and four is not a detail. It is whether you can answer a regulator without a third party's cooperation.
The three questions that separate them#
Skip "is it self-hosted" and ask these instead.
Where is the decision made? When the agent tries something consequential, which machine evaluates whether it is allowed, and who wrote the rule it evaluated? If that machine is the vendor's, your policy is a request you send to somebody else's system.
Where does the record live, and who can alter it? The audit trail is the artifact you eventually hand to an auditor. If it lives with the vendor, you are renting your own evidence, and you should know what happens to two years of it the day you leave or the day they are acquired.
What still has to leave for the product to work at all? Not what can be configured off. What is required. If prompts, responses or tool results must travel for the thing to function, they travel, and your DPO will need to know.
The part a vendor structurally cannot give you#
Here is the asymmetry, and it is not a criticism of anyone.
A vendor cannot hand over its own control plane. The control plane is the product. Anthropic's decisions about what Claude Code may do are the thing that makes Claude Code Claude Code, and the same is true for every agent vendor. Giving that away is not a roadmap item that has been deprioritized. It is the business.
And a vendor will never govern a rival's agent. Anthropic will not decide what Codex may do on your systems. OpenAI will not gate Claude Code. Your CRM vendor will not govern either of them. Each one governs its own, and every one of them is a silo with its own idea of what "approved" means.
Which leaves exactly one place a single trust model can live: with the company that owns the systems all of them are trying to reach.
That is not a competitive claim, it is arithmetic. Only one party in the arrangement has a relationship with every agent, and it is you.
What we would say about our own answer#
We are the fourth architecture. The decision happens on your machine, the record is a hash chain on your disk, and nothing has to reach us for any of it to work. That is the whole design, and it is why the product installs on your server rather than offering your data a nice room in ours.
Where we stop is documented as carefully as where we reach: a cooperative hook inside somebody else's tool is best effort and fails open, and we are not going to describe that as containment.
The next time a vendor tells you it runs on your infrastructure, do not argue. Just ask the three questions.
They moved where it runs. The question is who decides.