Where Does Your Code Actually Go When You Use AI Tools?

Encryption describes how data is protected in transit. It says nothing about whether the data goes anywhere. The three deployment shapes, and the questions that settle a security review.

Written by Vladimir Miroshnichenko·Published August 29, 2026·Updated September 4, 2026·4 min read

Every security review of an AI development tool arrives at the same question, and most vendor documentation answers a slightly different one. The question is: what, exactly, crosses which boundary? The answer you usually get is a paragraph about encryption and a SOC 2 logo.

Those are not the same thing. Encryption describes how data is protected in transit. It says nothing about whether the data goes anywhere.

Three shapes, and the honest description of each

Almost every AI code tool falls into one of three deployment shapes. The differences between them are not features — they are boundaries.

Cloud. You authorise a repository and the vendor's service reads it. Your source code is processed on infrastructure you do not control. This is the fastest to start and entirely reasonable when the code already sits with a third party you trust; if you are on hosted GitHub, a vendor reading that repository is not a new category of exposure.

Local processing with synchronised results. A component runs inside your infrastructure, processes only the sources you permit, and sends derived results to the vendor's service. Source code does not leave. Something else does.

That last sentence is where most vendor copy gets slippery. "Your code never leaves your machine" is technically true and materially incomplete if summaries, structure or extracted knowledge are transmitted. A derived artefact is still information about your system, and a reviewer is entitled to know what is in it, how much of the original could be reconstructed from it, and where it is stored.

If a vendor tells you nothing leaves, ask what synchronises. If the answer is "nothing at all", ask how the web interface shows you anything.

Fully inside your boundary. A private deployment in your own VPC, on-premises or in an isolated environment. Nothing traverses a vendor-operated service. This is what regulated environments generally require and what most vendors will sell you at enterprise pricing.

The questions that actually settle it

Take these to a vendor and the vague ones become obvious quickly.

Which of the three is this, precisely? Not "we support on-prem" — which deployment am I buying, on the plan I am buying?

What leaves my environment, in each mode? Enumerate it. Source code, derived artefacts, telemetry, prompts, the answers themselves. "Metadata" is not an answer; it is a category that has hidden a great deal over the years.

Where is it stored and for how long? Region matters for regulation. Retention matters for breach exposure — data you have deleted cannot leak.

Is any of it used for training? Get this in the contract rather than on the marketing page. Marketing pages change without notice; contracts do not.

Who inside the vendor can reach it, under what approval, and is that logged? Most breaches are not exotic. They are an employee with broader access than the situation warranted.

What is the sub-processor list, and how am I told when it changes? Your vendor's vendors are your exposure too.

Reading certifications correctly

A SOC 2 Type II report means an auditor tested controls over a period and issued an opinion. It is meaningful and it is not a security guarantee — it says the controls the company described were operating, not that the architecture suits your risk.

More usefully: a young company that says "we are not certified yet, here is our actual architecture and here are the boundaries" is easier to evaluate than one that leads with a badge and answers the boundary question with adjectives. The badge is a floor, not a description.

For any AI tool specifically, three things are worth more than a certificate:

Which deployment shape you are actually on.
Whether derived data leaves, and what it contains.
Whether the training commitment is contractual.

Why derived data deserves its own conversation

This is the part that is genuinely new, and most security questionnaires have not caught up.

Traditional review asks whether data left. AI tools produce a second class of asset: information about your system, extracted from it. Structure, behaviour, relationships, summaries. It is not your source code and it is not nothing.

The right questions are how much of the original could be reconstructed from it, whether it is isolated per customer, and whether it is covered by the same deletion commitments as your source. A vendor who has thought about this will answer immediately. A vendor who has not will pause, and that pause is the most useful signal in the whole review.

A practical position

For most teams, a sensible posture is:

Cloud for repositories already hosted with a third party you trust, where speed matters more than isolation.
Local processing where source cannot leave but you accept derived results synchronising — and where you have read what is in them.
Private deployment where policy or regulation says nothing may traverse a vendor's service, and you have budgeted for it, because it costs more for real reasons.

Pick the boundary first and let the tooling follow. Teams that pick the tool first end up arguing for an exception to their own policy, which is a conversation nobody enjoys and which usually ends with the tool being removed six months later.

Put a number on your own workflow

Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.

Build My Business Case → Start free →

Frequently asked questions

Does "your code never leaves your machine" mean nothing is transmitted?

Usually not. In most local-processing deployments the source stays put but derived results — structure, summaries, extracted knowledge — are synchronised to the vendor's service so their interface can show you anything. That is a real transfer. Ask specifically what synchronises and what it contains.

What is derived data in AI development tools?

Information about your system extracted from your source: structure, behaviour, relationships, summaries. It is not your code and it is not nothing. Ask how much of the original could be reconstructed from it, whether it is isolated per customer, and whether your deletion rights cover it.

Is SOC 2 enough to approve an AI coding tool?

It is a floor, not a description. SOC 2 says an auditor tested the controls a company described over a period; it does not say the architecture suits your risk. For AI tools, which deployment shape you are on, what derived data leaves, and whether the no-training commitment is contractual all matter more.

Which deployment model should we choose?

Pick the boundary your policy requires, then choose tooling that offers it. Cloud is fine when the code already sits with a hosted provider you trust. Local processing suits teams whose source cannot leave but who accept derived results synchronising. Private deployment is for environments where nothing may traverse a vendor service — and it costs more for real reasons.

Vladimir Miroshnichenko

Founder, GitMir

Founder of GitMir, the intelligence layer that gives AI real context about a company's software. I write about AI agents, context engineering, workflow economics and keeping AI-generated work under control.

LinkedIn →

← More articles