Local Execution Is Not Local Inference: Stating the Boundary Accurately

The code never leaves the machine, except as context in every request. Both halves of that sentence matter.

Local execution and local inference are different claims

The argument for running an agent on your own machine, in compliance terms, usually goes: the code never leaves, nothing is cloned into a third-party virtual machine, so a requirement that source stay on approved infrastructure is satisfied.

The first half is accurate and the conclusion does not follow. An agent running locally still sends your code to a model, and the model runs on somebody else's hardware. Every file it reads becomes context in an API request. The difference between local and cloud execution is real, and it is narrower than the way it is usually sold.

This matters because teams make procurement decisions on the strength of that distinction, and a distinction that is doing more work than it can bear produces a compliance position that does not survive its first serious question.

What actually differs

Three things, and they are worth having straight.

Persistence. A cloud execution environment clones your repository onto storage it controls, for the duration of the task and whatever retention follows. Local execution does not: the working copy stays on your disk. That is a genuine difference in where a complete copy of your source comes to rest.

Scope. A clone is the whole repository, including history. Context is what the agent read — some files, some fragments, some command output. Both go to a third party; they are different volumes and different shapes.

Execution. Cloud execution runs your build and tests on infrastructure you do not control, which brings your build secrets and whatever your tests touch into that environment. Local execution keeps that on your machine.

Where the distinction genuinely holds

It holds strongly for anything about data at rest on third-party infrastructure. If your obligation is that a complete copy of the repository must not be stored outside approved systems, local execution satisfies it and cloud execution needs a contractual answer.

It holds for build-time secrets, which is an underrated point. A cloud runner executing your test suite needs the credentials your tests need, and those credentials are then present in an environment outside your control for the duration. Keeping execution local keeps that surface local.

And it holds for scale. The difference between "fragments of forty files were sent as context" and "the entire repository including every historical commit was cloned" is not rhetorical. If a leak happens, those are very different incidents.

Where it does not hold

It does not hold for the claim that source code is not transmitted. It is, continuously, as context. If your requirement is worded that way, local execution does not satisfy it and the honest answer is that you need a different arrangement — a provider agreement covering the API traffic, a deployment inside your own cloud tenancy, or a model you host.

It also does not hold for prompt content generally. Commit messages, comments, log output, stack traces containing customer identifiers, a .env the agent read while investigating — all of it is transmitted the same way, and none of it feels like "sending source code".

The retention question is the one to ask

For most organisations the practical question is not whether data is transmitted but what happens to it afterwards: is it retained, for how long, is it used for training, who can access it, and in which jurisdiction does it sit.

Those answers come from the provider agreement and the plan, not from where the process runs. An enterprise agreement with zero-retention terms changes your position far more than moving execution to a laptop does. The mechanics of that, including what a gateway can and cannot guarantee, are covered in AI gateways and data retention.

Self-hosting is the only version of the strong claim

If the requirement really is that no repository content reaches a third party, the only arrangement that satisfies it is inference you control — a model running in your own infrastructure, or on the machine itself.

That is a real option and it has real costs: capability below the frontier, hardware, operational burden, and a maintenance commitment. It is the right answer for some environments and it should be chosen with those costs in view, rather than arrived at by discovering that the cheaper answer did not actually meet the requirement. The trade-offs are worked through in local versus hosted models for code.

The middle position most teams land on

In practice the arrangement that satisfies most real obligations is: a provider agreement with retention terms in writing, execution local so no complete clone and no build secrets leave, context minimised so less is transmitted, and secrets excluded from what the agent can read at all.

Each of those is a lever, and they are independent. Treating local execution as the whole answer means pulling one lever and leaving the other three, which is how you end up with a defensible-sounding position and an undefended one.

Minimising context is a compliance control

Underappreciated, because it is usually discussed as a cost measure. Every file the agent does not need to read is a file that does not get transmitted. Excluding build output, vendored dependencies, fixtures containing real data and anything under a directory of customer exports reduces what leaves the machine, and it happens to reduce your bill.

Be careful about how you exclude. Mechanisms that only affect what the agent volunteers to read are not boundaries — an agent that decides a file is relevant can still open it. The controls that hold are the ones enforced below the agent's discretion: permission rules that deny reads outright, and a sandbox that makes the path unreadable. The distinction is the same one made in protected paths and secrets, and it is the difference between a preference and a control.

Secrets are the sharpest case

A credential read into context has been disclosed, regardless of where the process ran. That is worth stating in exactly those terms, because the local execution framing can create a sense that things read locally stay local, and nothing about the architecture supports that.

So the controls are the ordinary ones and they are not optional: secrets outside the workspace, denied by rule and by sandbox, injected at runtime rather than stored in files the agent can open, and rotated if one ever appears in a transcript. Local execution changes none of this.

Writing the position down honestly

If you are the person who has to answer for this, write two or three sentences that state what is true: complete copies of the repository are not stored on third-party infrastructure; file contents and command output are transmitted to the model provider as request context under an agreement with these retention terms; build secrets remain on developer machines; these paths are excluded by enforced policy.

That is a position that survives scrutiny. "We run locally so our code doesn't leave" does not, and the moment it fails is usually in front of somebody whose job is to notice, which is a bad time to discover the distinction was carrying more weight than it could.

Being fair to the local case

None of this is an argument that local execution is compliance theatre. It removes a whole category of exposure — a persistent clone with full history on infrastructure you do not control, plus your build environment and its credentials — and for many teams that category is the one their policy is actually about.

The point is only that it is one control among several, with a specific scope, and that its scope should be stated accurately. A control described precisely is worth more than a control described impressively, because the precise description is the one that still means something when somebody checks it.

The question people are really asking

When someone raises this in a meeting, the concern underneath is usually one of three, and separating them helps because they have different answers.

The first is contractual: does our agreement with the provider permit this, and what are the retention terms. That is a document question with a document answer, and it is the one most likely to be resolved satisfactorily.

The second is jurisdictional: where does the processing physically happen, and does that satisfy a residency requirement. That is a deployment question, and providers generally have an answer in the form of a region-specific endpoint or a cloud-hosted deployment inside your own tenancy.

The third is instinctive: it feels wrong for our source to go anywhere. That one is not a compliance question at all, and treating it as one leads to a technical debate that cannot resolve it. It deserves a direct conversation about risk appetite rather than an architecture diagram.

Cloud execution is not disqualified, it is a different agreement

Worth saying, since the framing so far has been about what local execution buys. Cloud execution environments are used by organisations with serious obligations, on the strength of contractual terms about isolation, retention and access rather than on the strength of where a process runs.

The mistake is not choosing cloud execution. It is choosing it without reading what the agreement says about the clone — how long it persists, who can reach it, what happens to it after the task, whether it is used for anything else. Those questions have answers, and a team that has read them is in a stronger position than one that avoided the whole thing by staying local and never asked what happens to their context.

An asymmetry worth noticing

Teams tend to scrutinise the execution environment heavily and the context channel not at all, because the first is a new thing they had to decide about and the second arrived with the tool. That is backwards relative to volume: over a year of daily use, the context channel carries vastly more of your codebase than any individual task environment ever holds.

If you are going to spend a limited amount of governance attention, spend it on the channel that is continuously active rather than the one that is conspicuous.

What to actually go and check

Three things, none of which takes long. What your provider agreement says about retention and training use for the plan you are actually on — not the plan on the marketing page. Which paths your agent is currently prevented from reading, tested rather than assumed. And whether anyone has ever looked at what a session transmits, which you can approximate by asking the agent to list every file it read during a representative task.

That last one is usually the surprise. The answer is longer than people expect, includes things nobody would have nominated, and is the most concrete possible input to a conversation that otherwise runs entirely on intuition.

None of this argues for or against a particular setup. It argues for describing whichever one you have in terms that match what it does, because a description that overstates its own scope is the kind of thing that holds up fine for two years and then fails all at once, in a room, in front of somebody whose job is to read it carefully.