Why your source code does not belong in a cloud AI

The idea is obvious: language models are good at reading code, so you let them check your own code for vulnerabilities. Technically this works surprisingly well. Organizationally it fails at the same point in many companies – and for good reasons.

What you actually transmit

A repository is not just source code. As a rule it contains:

• Architecture knowledge. How your product works, where the bottlenecks are, which shortcuts were taken.
• Business logic. Pricing models, discount rules, contract logic – for many companies the core of their competitive advantage.
• Configuration and infrastructure description. Which services talk to each other, which networks exist.
• History. The git history contains what was once committed and later removed. Credentials, for example.
• Third-party content. Code under licenses you may not pass on freely and, occasionally, personal data in test fixtures.

Whoever uploads a repository "just quickly" transmits all of that.

The legal department's four questions

In almost every company the review comes down to the same four points.

1. Where is it processed? If processing takes place outside the EU, a sound basis for the third-country transfer is required. A tick box in a web interface is not enough.

2. Is my data used for training? Most providers rule this out in their business terms – in the free tiers often not. The difference between the plan a developer uses privately and the one the company has bought is considerable here.

3. How long is it stored? Almost all providers keep inputs for a while for abuse detection. That is legitimate, but it extends the period during which your code sits on someone else's systems.

4. Who has access in case of doubt? As part of abuse review, provider staff can look at inputs. That is in the terms, but it is rarely considered at the moment of upload.

None of these points is a scandal. Taken together they explain why a careful legal department says "no" – and why that "no" is not a sign of hostility to progress.

The special case: client code

It becomes particularly delicate for agencies and service providers who develop code on behalf of third parties. A confidentiality agreement with the client almost always applies here. Whoever hands this code to an AI service without consulting them will, as a rule, breach their own contract – regardless of how secure the provider is.

The way out: local inference

The technical answer is unspectacular: you run the models yourself. Open models have come far enough in code analysis that the quality gap to the large commercial models is acceptable for this purpose – especially when a human checks every result anyway.

What matters is less the model than the environment around it:

• A network segment without outbound internet access, so that transmission is technically impossible – not just contractually prohibited.
• Personal accounts with multi-factor authentication instead of shared accounts.
• Defined retention periods with logged deletion.
• Documented data flow that the other side can review.

The question to ask every provider

When a service provider offers AI-assisted code analysis, the decisive question is not which model they use, but:

"Is there an outbound internet connection in your analysis environment?"

If the answer is "no", ask for the network configuration as a contract annex. If it is "yes, but we don't send anything", that is an organizational promise, not a technical property. Both can be acceptable – but you should know what you are buying.