Where your code actually goes
There is a sentence that appears on almost every enterprise AI page, including, until recently, ours: nothing ever leaves your tenant.
It is a good sentence. It is also, for any agent doing useful work, not quite true, and a security architect will find the seam in about ninety seconds.
Here is where it breaks. An agent searches the public web. An agent reads Gong or Zendesk. An agent calls a supplier’s API to check a deprecation. An agent opens a pull request on GitHub. An agent uses a model that runs on the model provider’s infrastructure. Each of those is a legitimate thing to want, and each of them is traffic crossing a boundary.
The honest version is longer, and it survives the meeting:
Eido Build’s control plane, workers, source checkout, credentials, work history and audit data run inside your Azure environment. External models, systems and network destinations are only available when your organisation explicitly approves them.
That says what is fixed, what is optional, and who decides.
Models are not one category
The part that gets flattened most often is the model. “We use Foundry” is treated as a single answer, when it covers at least four materially different arrangements.
Azure-hosted. The model is deployed in your own Foundry resource and runs on Azure infrastructure end to end. For models sold by Azure, Microsoft states that prompts and completions are not available to other customers or to the model provider, are not used by providers to improve their models or services, and are not used to train foundation models without your instruction. That is a strong commitment, and it is written down.
Partner-hosted through Foundry. You reach the model through Foundry, but it runs on the provider’s own infrastructure. This is not hypothetical: Microsoft publishes several Claude models in both forms, labelled “Hosted on Azure” and “Hosted on Anthropic infrastructure”, and the terms are not identical. Treating the two as the same thing because they share a model name is exactly the mistake that gets a deployment stopped.
External managed agent. A provider’s own hosted agent, reached over the network. Sometimes it is the right tool. It should be off by default, enabled per project, and recorded, including which destination it talked to.
Open-weight on your own compute. Deployed on infrastructure you control, inside your own network boundary. This is the option for repositories where the answer to “where did this code go” has to be “nowhere”.
Label it in the product, not in the sales deck
A policy document that classifies models correctly and a product that hides the classification are not the same thing. If an engineer cannot see, on the run that produced a change, which class of model touched the code, the classification is decorative.
So the hosting class travels with the run. It sits in the run record next to the worker, the budget and the approver, and it lands in the audit trail. When someone asks which model processed which repository (and eventually someone always asks), the answer is a query rather than an investigation.
The uncomfortable comparison
None of this is an argument that coding agents are unsafe. Anthropic ships permissions, sandboxing, managed settings and enterprise controls for Claude Code, and states that commercial customer data is not used to train its models by default. Taken on its own, it is a well-governed tool.
The problem is not one agent on one laptop. It is a hundred of them, on a hundred workstations, each inheriting a developer’s identity and access, each configured a little differently, each approving commands at the speed of someone who has seen the prompt forty times today. That fleet is hard to inventory, attribute or bill, and no vendor’s per-tool controls fix it, because the gap sits between the tools rather than inside any one of them.
Which is the reason Eido Build exists. Claude Code is excellent at coding. It needs somewhere governed to do it.
What to ask any vendor
Three questions, and the answers should be specific:
- Which components run inside my Azure environment, named individually, not “the platform”.
- For each model I might use, which hosting class is it in, and where is that recorded after the run?
- What leaves my environment when an agent reads a support system or searches the web, and who approved that destination?
If the answer to the first is “everything stays in your tenant”, nobody has thought about the third.