Coding Assistants: Where Your Repo Context Goes

Q: Where does my code actually go when I use a coding assistant?

It leaves your machine. Every completion an assistant generates is produced by a model, and to produce it the plugin sends context across the IDE-to-vendor boundary: the file you have open, neighbouring and retrieved files from the repository, sometimes terminal output, and whatever secrets happen to be sitting in those files. That context travels to inference infrastructure the vendor runs, not to your laptop. The security question is therefore not whether the code leaves — it does, on every keystroke that triggers a suggestion — but what specifically leaves, to which vendor, whether it is retained, whether it is used to train a model, and whether the original code could be reconstructed from what was sent. Most teams have rolled out an assistant without ever drawing that boundary, which is why they cannot answer any of those questions. The context window the model sees is, in security terms, your attack surface, and it is as wide as the files the assistant is allowed to read.

Q: Does GitHub Copilot or Cursor train on my private code?

It depends entirely on the plan tier, and the difference is stark. On the enterprise tiers the guarantees are genuinely strong: GitHub Copilot Business and Enterprise contractually exclude your prompts and suggestions from training, and that exclusion extends to the third-party models they route to such as Anthropic and Google; prompts are not retained for IDE-based access, with a short retention window (around 28 days) only for the web interface. Cursor offers a Privacy Mode that enforces zero data retention, and on its Business and Enterprise plans that mode is on by default and cannot be silently disabled by an individual. The weak case is the personal tiers, where retention is longer and training opt-out may not be the default. The single most dangerous configuration is a developer using a personal account inside a work repository, because then the contract governing your source code is with an individual, the retention terms are whatever that person accepted, and your security team has no visibility at all. The guarantee you get is conditional on the tier you bought and on an administrator actually enforcing the privacy mode.

Q: Should we just ban coding assistants to be safe?

No — a ban is usually the worst option, because it does not remove the risk, it removes your visibility of it. The productivity pull of these tools is strong enough that developers who cannot use the sanctioned, enterprise-tier assistant will use an unsanctioned one on a personal account instead, which is precisely the highest-risk state: an individual’s contract governing your code, unknown retention terms, and traffic your security team cannot see on the network. A ban therefore tends to convert visible, governable, enterprise-tier usage into invisible shadow usage. The defensible strategy is the opposite: give developers a fast, sanctioned assistant on enterprise terms with privacy mode enforced, so that using the approved tool is easier than smuggling in an unapproved one. You keep the productivity, and you keep the boundary inside your control where you can enforce retention terms, monitor egress and redact secrets. Governance beats prohibition because prohibition of a tool this useful simply relocates the tool out of your sight.

Q: What is the IDE-to-vendor boundary and why does it matter?

The IDE-to-vendor boundary is the point at which code leaves the developer’s environment and crosses onto the assistant vendor’s inference infrastructure. It matters because it is the single event that determines your entire data-exposure posture: everything on your side of the boundary is governed by your controls, and everything on the far side is governed by whatever the vendor’s contract says. Once a prompt has crossed, your policy is reduced to the terms of that agreement — the retention window, the training exclusion, the logging. That is why the plan tier and the retention mode are architecture decisions rather than procurement footnotes: they define the rules on the far side of a boundary you cannot otherwise reach. Treating the boundary as an explicit, monitored control point — knowing which endpoints are approved, routing traffic through a gateway you own, and redacting sensitive content before it crosses — is what turns "we trust the vendor" into "we chose and enforce the terms." The exposure is also two-directional: code and secrets flow out, and generated code that may carry licence-encumbered snippets or fabricated credentials flows back in.

Q: How do I stop secrets leaking through a coding assistant?

Fix the source and control the boundary, in that order. The root cause is that secrets are hardcoded in the files the assistant reads, so they end up in the prompt — GitGuardian measured a 6.4% secret-leak rate in repositories with Copilot enabled, and its 2026 report found leaks of AI-service credentials surged 81% year on year. The assistant did not create those secrets; it is a new, high-bandwidth path for files that already contain them to leave. So the first and most durable fix is proper secrets management: the key should never have been in the file, but rather in a vault or KMS injected at runtime, which removes it from the context window entirely. The second layer is DLP and secret-scanning redaction applied at the IDE-to-vendor boundary, so that if a secret is present in the context it is stripped from the prompt before it is transmitted. The third layer is scanning the assistant’s output, because a plausible but fabricated credential the model suggests is a new way for a bad secret to arrive in your repo. Redaction after a leak is worthless; the controls have to sit upstream of the boundary crossing.

Q: Is code generated by an assistant safe to merge?

Not by default — generated code should be treated as untrusted input and scanned like any other commit, not waved through because a model produced it. There are three specific risks in returned output. First, licence contamination: the model may reproduce a snippet that is close to license-encumbered training data, creating an obligation or a legal exposure you did not intend to take on. Second, fabricated credentials and dependencies: an assistant may suggest a plausible-looking hardcoded key or import a package name that does not exist or was squatted, which is the same supply-chain risk that makes AI coding agents a dependency problem. Third, ordinary vulnerabilities: generated code can contain injection flaws, weak crypto or logic errors just as human code can. The correct posture is to run the same secret-scanning, dependency-provenance and static-analysis gates on AI-authored diffs that you run on human ones. Un-scanned assistant output is simply un-reviewed input flowing straight into your codebase, and the fact that it looks polished makes it more likely, not less, to pass a casual review.

Q: What does an egress gateway do for coding assistants?

An egress gateway gives you visibility and control over the traffic that assistant plugins send to vendor endpoints, which is otherwise a blind spot on your network. Assistant plugins communicate with a fixed, known set of vendor destinations, so routing that traffic through a forward proxy or egress gateway lets you do three things you cannot do otherwise. First, allowlist the approved endpoints and block the personal-account and unapproved-vendor endpoints, which technically enforces the policy that would otherwise be a mere request. Second, obtain a log that assistant traffic left, to which destination, and at what volume, so you can distinguish sanctioned enterprise-tier use from shadow use on the same network — turning "we only use approved tools" from an unfalsifiable assertion into a monitored fact. Third, provide the natural insertion point for DLP and secret redaction, since the gateway sees the traffic before it crosses the boundary. This is the same egress-control discipline that agent runtimes require, applied to the IDE. Without it, your inventory of approved assistants is a spreadsheet with no enforcement behind it, and you have no way to detect the developer quietly using a personal account.

Q: What is the single highest-risk way to use a coding assistant at work?

A developer using a personal assistant account inside a work repository. This configuration is the worst of every dimension at once. The contract governing your source code is between the vendor and an individual employee, not your company, so you have no enterprise data-processing terms, no negotiated retention exclusion, and no training exclusion beyond whatever that person happened to accept when they signed up. The retention window is unknown to you and may be long. The traffic is invisible to your security team because it does not go through any sanctioned path, so you cannot even detect that it is happening, let alone govern it. And it is exactly the state that a well-intentioned ban tends to create: forbid the approved enterprise tool and the motivated developer reaches for a free personal account to keep their productivity, moving the activity from inside your visibility to outside it. The remedy is not stricter prohibition, which drives it further underground, but a sanctioned enterprise-tier alternative that is easier to use than the shadow path, combined with egress visibility that surfaces personal-account use when it does occur.

Satyam Kumar

Retour au blog

ai-architecture

Your Coding Assistant Has Read the Whole Repo. Where Does That Context Go?

By Satyam KumarAugust 13, 202610 min read

coding assistant security github copilot cursor ai coding tools code exfiltration data loss prevention secrets management ide security source code protection egress control shadow ai appsec llm security enterprise ai governance supply chain security 2026

Your Coding Assistant Has Read the Whole Repo. Where Does That Context Go?

Frequently Asked Questions

Partager l'article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Architecte AI & Cloud. J'aide les équipes à construire des systèmes qui scalent pour des millions.

LinkedIn GitHub

Your Coding Assistant Has Read the Whole Repo. Where Does That Context Go?

Frequently Asked Questions

Partager l'article

Comments

Leave a comment