What AI Coding Tools Actually Read
Last updated: 2026-07-174 min read
AI coding tools read more than the file you are editing - and the relevant boundary is the complete data path: input, provider processing, retention, telemetry, logs, subprocesses, local storage and access. Layered controls can reduce exposure, but a vendor term, scanner or local deployment model does not guarantee confidentiality.
Contents
The data flow, described precisely
Context is the product. A modern assistant is useful precisely because it reads beyond the cursor: neighboring files, imports, configuration, test fixtures, the ticket you pasted, the stack trace from production. Reputable vendors document these flows and offer real controls - exclusions, no-training commitments, retention settings - and the BSI/ANSSI recommendations treat exactly this flow as a first-class risk to manage, not a reason to ban tools. The precision that matters: what leaves depends on tool and configuration, so the honest unit of analysis is your setup, not the category.
The measured numbers
The secrets problem predates AI. A 2026 vendor report provides one observed public-GitHub dataset: GitGuardian counted 28.65 million new hardcoded secrets in its 2025 sample and reported associations with AI-assisted activity. A related vendor article discusses repositories with Copilot active showed 6.4% leak incidence versus 4.6% in the observed sample and a bounded extraction setup. These figures depend on vendor detection, attribution and sampling; they neither establish causality nor estimate a particular private repository. Treat them as risk signals and establish a documented local baseline.
What leaves, what hides in it, what stops it
| Path | What hides in it | Countermeasure |
|---|---|---|
| Prompt / pasted material | Logs, stack traces, config snippets with credentials | Secret scanner on paste; staff rule: sanitize before pasting |
| Selected file context | .env files, key files, fixtures with real data | Exclusion patterns; secrets out of the repo entirely |
| Codebase index / embeddings | Everything - the whole repo, searchable | Scope the index; local processing for sensitive repos |
| Generated output | Hardcoded credentials the model reproduces or invents | Pre-commit secret scanning - catches human and AI alike |
| Telemetry / learnings | Usage patterns, retained review context | Business-tier controls; opt-outs documented in writing |
The pattern across rows: the highest-leverage fix is upstream. A secret that lives in a secret manager and reaches the app as an injected environment variable cannot be pasted, indexed, or reproduced - the leak rate cannot amplify what is not there. Everything else is defense in depth around that.
The trade-secret angle, described soberly
Legal status: July 2, 2026. Descriptive only - not legal advice; the assessment belongs to your counsel. Trade-secret regimes protect information only while its holder takes reasonable secrecy measures - in Germany under the GeschGehG, EU-wide under the Trade Secrets Directive. Source code is often exactly such a secret.
Whether routine transmission to third-party services is compatible with “reasonable measures” depends on contracts, configuration and controls in your specific case - which is precisely why the data-flow mapping above belongs in writing. For the broader data-boundary architecture, see local AI code review and, where personal data is in play, the GDPR checklist.
Where Reality Graph fits
Reality Graph’s contribution here is architectural: it is designed local-first, so the verification layer itself adds no new transmission path - the checks against the written task, including boundary checks that catch out-of-scope file access, run in your environment, and the evidence report documents per run what was touched. Where it does assemble material for an agent, that material goes through a scoped pack designed to strip recognised secret patterns before the prompt is built, which addresses the second row of the table and nothing beyond it. It is not a secret scanner and does not replace one - it makes the workflow around your tools inspectable without adding another cloud to trust.
This page gives you
- The five transmission paths, mapped to countermeasures
- Measured numbers with sources, not vibes
- The upstream-first fix order that actually reduces risk
- The trade-secret angle, described without alarmism
It does not give you
- A verdict on any vendor's data practices - check yours
- Legal advice on secrecy measures - counsel owns that
- A reason to ban tools - mechanisms beat prohibition
- A pass on secret hygiene just because processing is local
If these boundaries fit how your team wants to ship:
FAQ
- What data do AI coding tools send to their providers?
- More than the prompt. Map the exact tool, version, configuration, plugins and subprocesses: user input, selected files, indexes, logs, telemetry, caches, retention, backups and local storage, plus every provider or downstream service. Vendor no-training or zero-retention terms cover only the stated service boundary; they do not prove the complete data path.
- How bad is the secrets problem, measured?
- GitGuardian's 2026 vendor report counted 28.65 million new hardcoded secrets in its observed public-GitHub dataset for 2025 and reported associations involving AI-assisted activity. Those figures depend on its detection, attribution and sample methodology; they do not establish causality or predict a private repository. Use them as a risk signal, then measure a local baseline with documented scanners and review sampling.
- Can secrets come back out of the models?
- A GitGuardian vendor article reported an extraction experiment using constructed prompts and public GitHub snippets. That bounded setup is evidence of a possible attack path, not a current prevalence estimate or proof about every model. Filters and contractual controls can reduce specified exposure, but their coverage and bypass limits must be tested for the actual configuration.
- Do trade secrets have a legal angle here?
- Descriptively, yes: the EU Trade Secrets Directive and Germany's GeschGehG use concepts including reasonable secrecy measures. Whether information qualifies and whether a particular data path changes its treatment are fact- and jurisdiction-specific legal determinations. Contracts, configurations and controls are evidence for counsel to assess, not an automatic outcome. Legal status July 2026; not legal advice.
- What are the countermeasures that actually work?
- Use layered controls: inventory the data path, remove secrets from repositories and prompts, constrain context, scan at several gates, review provider and retention terms, restrict access and monitor exceptions. Each control has coverage and bypass limits, so test and record them against the actual workflow. The combination reduces exposure; it does not guarantee confidentiality.
- Does local processing solve the secrets problem?
- No. Local execution, offline operation, network isolation and local storage are separate properties. A local model can still read a .env file; plugins or subprocesses can make network calls; telemetry, logs, caches and backups can copy material; and local users may retain access. Verify each boundary and its residual risk. A deployment model alone is not a confidentiality guarantee.
Keep reading
Sources
- GitGuardian vendor report - observed public-GitHub secrets dataset (2026); methods and sample limit generalization and causality
- GitGuardian vendor article - reported Copilot association and extraction setup (updated through 2026); not a current prevalence estimate
- BSI/ANSSI - official recommendations on AI coding assistants and confidential data (2024, German); controls do not guarantee confidentiality