Your AI coding assistant sees your entire codebase. Here's what that means

You use a coding assistant. Copilot, Cursor, Claude Code, Windsurf, or Cody. It autocompletes your code, answers questions about your codebase, writes tests, reviews pull requests. To do this, it reads your files: not just the file you are editing, but context from related files, imports, type definitions, configuration, sometimes your terminal output. That context goes to a server for inference. Your codebase contains more than code. Database connection strings, API keys in config files, customer email addresses in test fixtures, internal usernames in deployment scripts, PII in log samples. The assistant sees all of it, and on 31 March 2026 we got the clearest demonstration in the short history of these tools that the data flow goes both ways: the assistant sees your code, and on a bad day you see the assistant's code, including the parts its vendor did not intend to ship.

This article walks the asymmetric threat the tools create: what they see of you, what they ship to you, what they do with the data in the middle, and the specific operational fixes that work in 2026. If your team uses Copilot with client code, the Copilot-specific piece is the companion. If the concern is data leaving your codebase through any channel, the codebase leak audit article is the audit framework. What follows is the security-and-privacy angle specific to AI coding assistants.

What the Claude Code source leak revealed

On 31 March 2026 Anthropic accidentally published the full source of Claude Code inside an npm package. A missing *.map entry in .npmignore, combined with the fact that Claude Code is built on Bun (which Anthropic acquired in late 2025 and which generates source maps by default), shipped a 59.8 MB source map containing roughly 512,000 lines of unobfuscated TypeScript across about 1,900 files. Security researcher Chaofan Shou spotted the exposure at approximately 4:23 AM ET and posted a download link on X; the tweet accumulated over 21 million views within hours, and the codebase was mirrored across GitHub and analysed by thousands of developers before Anthropic pulled the package. Layer5 has the most detailed reconstruction of the timeline. Alex Kim's post catalogues the specific findings, including 44 hidden feature flags, an always-on background agent called KAIROS, and a "stealth mode" designed to hide Anthropic employee contributions to open-source projects.

The more serious problem is what landed in development environments during the exposure window. Between 00:21 and 03:29 UTC on 31 March, users who installed or updated Claude Code via npm may have pulled in a malicious version of axios (1.14.1 or 0.30.4) containing a remote access trojan. The attack used the Claude Code leak as cover to typosquat internal package names that became briefly guessable from the leaked source. If you installed or updated Claude Code in that window, you need to audit your workstation for the axios RAT before treating the incident as background.

The pattern is the part to internalise. AI coding assistants ship into the most trust-sensitive surface in a developer's workflow: a tool that auto-runs code, reads files, opens sockets, and has access to the same credentials the developer has. A supply chain compromise in that surface gets root-equivalent access to the machine and everything reachable from it. The Check Point research team separately disclosed CVE-2025-59536 (CVSS 8.7), an RCE via malicious entries in Claude Code project config files, and CVE-2026-21852, an API key exfiltration vulnerability via settings files that redirected requests to an attacker-controlled server. Both are patched. Both demonstrate that cloning a malicious repository and opening it in an AI coding tool is an attack vector, which was not true of any editor before AI assistants shipped.

The secret leakage problem that ignore files do not solve

The GitGuardian State of Secrets Sprawl 2025 report sampled approximately 20,000 public repositories where GitHub Copilot is active. Over 1,200 of them leaked at least one secret, a 6.4% incidence rate versus a 4.6% baseline across all public repositories. That is a 40% relative increase. GitGuardian's credential scanner also extracted 2,702 valid hard-coded credentials from Copilot suggestions themselves, of which about 7.4% were real operational credentials in production systems. Copilot is not the only tool with this pattern; it is the one that was measured.

The deeper problem is that the AI coding assistants read files the .gitignore and the version control pipeline were never asked to protect. Research by Knostic found that Claude Code, Cursor, Copilot, Windsurf, and Cline all auto-load .env files into model context without explicit consent. Your API keys, database passwords, and service tokens get sent to the provider's servers the moment the assistant decides the file is useful context. .cursorignore and .claudeignore are supposed to block this, but Cursor describes its own implementation as "best effort" and Claude Code has been documented reading .env files despite ignore rules.

What actually works is not configuration but separation.

Keep secrets out of the project directory entirely. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, 1Password CLI, Doppler). Store only .env.example with placeholder values in the repository, and load real values at runtime from the secrets manager.

Run AI tools in isolated environments. A container, a VM, or a dev container with a scoped credential profile prevents the assistant from touching SSH keys, cloud credentials, and other host-level secrets that live outside your project directory but are reachable from the shell the assistant has access to.

Use pre-commit secret detection as a backstop. Gitleaks, TruffleHog, and detect-secrets all work as pre-commit hooks and catch credentials before they enter version control, which is also before they enter any future training set built from public repositories.

Maintain ignore files as defence in depth. They are imperfect, but they are better than nothing. Add .cursorignore, .claudeignore, and (for Claude Code) deny rules in ~/.claude/settings.json for sensitive paths. Just do not rely on them as the only layer.

What each major tool actually sends and stores (April 2026)

The differences between tools are not marketing talking points. They are fundamental decisions about data handling, and they vary dramatically by tier within the same product.

GitHub Copilot. Sends code snippets, surrounding context from open files, repository metadata, and file paths. On the Free, Pro, and Pro+ plans, your interaction data is used for model training unless you explicitly opt out. GitHub updated its privacy statement on 25 March 2026 to confirm this. Business and Enterprise plans exclude your code from training and offer shorter retention windows. If you are a paying individual on Pro or Pro+ and you do not explicitly opt out, your private code is training GitHub's next model.

Cursor. Sends codebase data, prompts, and code snippets. Privacy Mode (available on all plans) enables zero data retention with model providers and excludes your data from training. Without Privacy Mode, data may be stored and used. For accounts created after October 2025, Privacy Mode defaults to off, so new users are opted in to data collection unless they change the setting. If you installed Cursor after October 2025 and have not touched the privacy settings, assume the worst.

Claude Code. Sends entire files that it reads to Anthropic servers. The March 2026 source leak revealed the full scope of what is captured and retained: session transcripts, activity logs, working directory paths, and system information. On free and consumer plans, data may be used for training with opt-out available. Commercial and API plans exclude training and offer 30-day or zero retention depending on tier. If you are using Claude Code on a consumer plan with proprietary code, check the training opt-out before the next session.

Windsurf (Codeium). Sends minimal code snippets with context, never entire repositories. Zero data retention by default for paid seats. No training on private code. SOC 2 Type II certified. Self-hosted and air-gapped deployment available for teams with stricter requirements. This is the strongest default privacy posture of any commercial coding assistant as of April 2026.

Sourcegraph Cody. Enterprise plans provide full data isolation, zero retention, and self-hosted deployment where the code never leaves your network. If "the code cannot leave our network" is the compliance requirement (regulated industries, government, defence contractors, financial institutions with strict data handling rules), Cody Enterprise and Windsurf air-gapped are the two tools that answer it.

The pattern across all five is the same. Enterprise tiers protect your code. Free and individual tiers often do not. If you are using a free tier with proprietary code, you need to know what you have agreed to, and "I did not read the ToS" is not a defence the regulator or the client will accept.

The security regression that is not improving

This is the angle most developers underestimate. AI-generated code is measurably less secure than human-written code, and the gap is not closing.

Veracode's Spring 2026 GenAI Code Security Update tested more than 100 LLMs on security-relevant coding tasks. The security pass rate sits at approximately 55%, which means 45% of AI-generated code samples introduce OWASP Top 10 vulnerabilities. The per-vulnerability-class breakdown is worse than the headline. 86% of cross-site-scripting (CWE-80) test cases fail. 88% of log-injection test cases fail. Java is the riskiest language in the sample at a 72% security failure rate. These are not subtle statistical differences; they are load-bearing defects in the kind of code that ships to production.

The most concerning finding in the Spring 2026 update is that the security pass rate is flat over the testing period even as coding performance benchmarks improved. Models are getting better at writing functional code and they are not getting better at writing secure code. I think this is the most underrated data point in the 2026 AI-coding conversation. It means the "wait for the next model" strategy that many teams are implicitly running is not going to pay off on security, because the improvements are going somewhere else.

The older Veracode 2025 finding that AI-generated code contained 2.74x more vulnerabilities than human-written code is the historical baseline. The 2026 update suggests the gap is not closing. Cross-site scripting is 2.74x more likely, insecure direct object references 1.91x, improper password handling 1.88x, insecure deserialisation 1.82x. The Cloud Security Alliance has tracked the resulting CVE surge in a 2026 research note on vibe coding's security debt. Georgia Tech researchers identified 74 CVEs directly attributable to AI-authored code as of March 2026, with the real count estimated at 400 to 700.

The mitigation is not exotic. Run SAST tools in your CI pipeline. Semgrep, CodeQL, and Snyk Code all catch the common patterns. Treat every AI-generated pull request with the scrutiny you would apply to a junior developer's first week on the team. The vulnerabilities are real, they ship to production, and the SAST tools are faster than the manual review the AI-generated code will not get otherwise.

The confidence illusion

The Stanford study by Perry et al. from 2023 ("Do Users Write More Insecure Code with AI Assistants?") found something worse than the raw vulnerability rate. Developers with access to AI assistants wrote significantly less secure code than developers without AI assistance, and they were also more likely to believe their code was secure. The AI assistance produced a confidence boost that masked a security regression.

This is the failure mode that the 2026 Veracode data makes measurable at scale. If 45% of AI-generated code introduces an OWASP Top 10 vulnerability and the developer feels more confident about it than they would about their own code, the review bar drops at the exact moment it needs to rise. Pull request reviews that used to catch these defects now wave them through because the AI output looks polished, and the tests the AI wrote pass because the AI wrote both the code and the tests to the same specification.

The operational answer is to separate the confidence signal from the security review. The security review stays manual or stays automated, but it does not rely on the developer's subjective assessment of "this looks right." Tools like Semgrep and CodeQL in CI are the floor. Mandatory human review for any security-adjacent change (authentication, authorisation, input handling, crypto, deserialisation, SQL, XSS-vulnerable surfaces) is the ceiling. Between those two, the confidence illusion has less room to cause damage.

The GDPR cross-border transfer hiding in your editor

Your codebase contains personal data even when you do not think of it that way. Developer names and emails in git commits. Customer email addresses in test fixtures. Real user IDs in database seeds. Internal usernames in deployment configs. Log samples with PII that someone copied into a fixture "just to test something." When your AI coding assistant processes these files, it is processing personal data under GDPR.

If the processing happens on servers outside the EEA, which it does for most US-based tools including Copilot, Cursor, Claude Code, Windsurf, and Cody by default, that is a cross-border transfer requiring a legal mechanism. The EU-US transfers article walks the current state of DPF, SCCs, and TIAs. For AI coding assistants specifically, the operational consequences are:

You need a Data Processing Agreement under Article 28. The AI coding tool provider is a data processor processing on your instructions. Enterprise tiers typically offer DPAs as a standard part of the contract. Individual and free tiers often do not offer one at all, which means the processing has no contractual basis under GDPR.

You need an Article 46 transfer mechanism. DPF certification is the cheapest path if the provider is certified (OpenAI, Anthropic, Google, Microsoft all are). SCCs Module 2 is the fallback and should be signed alongside the DPF reliance in the belt-and-suspenders pattern the transfers article covers.

If you run a consultancy, agency, or contractor arrangement, your client's data is flowing to your AI provider the moment you use the assistant on the client's code. That flow likely violates the client agreements you signed before AI coding tools existed, because the agreements typically require named sub-processors and the AI provider is not on the list. Update the sub-processor list and tell the client, or stop using the assistant on the client's code.

The EDPB's 2026 Coordinated Enforcement Action focuses on transparency obligations under Articles 12-14 and names AI-adjacent processing as a priority area. No enforcement action has specifically targeted coding tools yet, but the direction is clear and the first case will be expensive for whoever is in it.

The tier gap is not a feature gap

The difference between free and enterprise is not the number of requests per day. It is whether the tool is safe to use on anything that matters.

Data handling	Free / individual	Enterprise
Code excluded from training by default	No (opt-out required)	Yes
Data Processing Agreement available	Usually no	Yes
Retention	Long or indefinite	Zero or 30 days
Admin controls and audit logs	No	Yes
Self-hosted or air-gapped option	No	Cody, Windsurf

If you are a solo developer working on personal projects, a free tier is probably fine. If you work with client code, proprietary systems, or any data that could include PII, the enterprise tier or a self-hosted tool is not an optional upgrade. It is a compliance floor. And if your team is paying for a free tier in time (working around missing admin controls, dealing with training opt-outs, explaining to customers that their data went somewhere the DPA did not cover), the enterprise tier is cheaper than the workarounds.

Before your next coding session

Four things to check before you open the assistant again.

First, the data handling setting. In the tool's settings page, confirm that your code is excluded from training (or that Privacy Mode is enabled in Cursor, or that you are on a tier where the exclusion is the default). If you are on a tier where the default is inclusion and you have not opted out, you have been training somebody's model for the duration.

Second, the secrets posture. Move .env and any credential files out of the project directory. If you cannot, put them behind a secrets manager and use .env.example with placeholders in the repository. Add .cursorignore, .claudeignore, and deny rules in Claude Code's settings for any sensitive paths that remain, with the understanding that the ignore files are defence in depth and not a guarantee.

Third, the CI floor. If Semgrep, CodeQL, or Snyk Code is not running on every PR, add it this week. The 2026 Veracode numbers mean any codebase shipping AI-generated code without SAST in CI is shipping OWASP Top 10 vulnerabilities at scale, and the SAST tools are cheaper than the fix.

Fourth, the vendor contract. Check whether your AI coding tool's plan includes a DPA. If you are in the EEA or you handle EEA personal data, you need one. If the plan does not include it, upgrade to a tier that does, or switch to a tool whose default tier covers it.