By the Shadow AI Policy team
**Engineering teams are already using AI coding assistants — with or without your permission — and the default settings on most of these tools send your source code to third-party servers.** This post covers the five policy decisions every company needs to make before an engineer pastes proprietary code into Cursor, GitHub Copilot, or Claude Code: how to tier source code by sensitivity, what open source license contamination actually means for your codebase, why secrets scanning belongs before the AI step, how customer data ends up in test fixtures and why that's a compliance problem, and how to build an approved tool list that engineering will actually follow.The biggest risk isn't a rogue engineer — it's a well-meaning one who doesn't know that pasting a database schema into an AI chat window may constitute a data disclosure under your customer contracts. Get the input restrictions written down and trained before one of your engineers finds out the hard way.
By the Shadow AI Policy team
Not all code carries the same risk if it leaves your network. A policy that treats a public-facing marketing microservice the same as your core authentication library or billing engine will either be ignored (too restrictive) or create real exposure (too permissive). Tier your source code before you write a single rule.
A workable three-tier model looks like this:
Put this tier classification in your repository documentation, not just your policy wiki. Engineers need to see it at the point of decision, not after a compliance training they took six months ago. A simple comment block or README section that labels a repo's tier takes less than five minutes and removes ambiguity.
This is the policy area engineering teams most often wave away — and it's the one that can quietly create intellectual property problems in a production codebase. AI coding assistants are trained on public code repositories, including code released under GPL, LGPL, AGPL, and other copyleft licenses. When a model produces output that closely resembles that training data, the license status of the generated code is legally unsettled.
The practical risk: if an AI assistant reproduces a non-trivial block of GPL-licensed code and that code ends up in a proprietary product, you may have an obligation to open-source the surrounding work — or face an infringement claim. Neither GitHub Copilot, Cursor, nor Anthropic's Claude Code currently provides a legal indemnification guarantee that covers all license exposure scenarios in their standard commercial terms. GitHub Copilot's enterprise tier offers a limited copyright commitment for certain outputs, but it comes with conditions and doesn't cover all use cases.
Your policy should require:
This isn't about distrusting your engineers. It's about the fact that AI code completion is fast enough that nobody is carefully reading every suggestion — they're accepting and moving on. The SCA tool is the safety net.
Engineers working quickly will paste entire files into an AI chat window to get help debugging. If that file contains an API key, a database connection string, an OAuth token, or a hardcoded password — even one left in the code "temporarily" — that credential has now been transmitted to a third-party server. Depending on the tool and tier, it may be logged, reviewed by humans for trust and safety purposes, or retained for a period defined in the vendor's privacy policy.
This is not a hypothetical edge case. Hardcoded credentials in source code are one of the most common findings in application security audits. The policy fix is simple: require pre-commit secret scanning in every repository, using a tool like git-secrets, truffleHog, detect-secrets, or the GitHub native secret scanning feature for enterprise accounts. If a secret can't make it past a commit hook, it can't end up in an AI prompt.
Your engineering policy should state this explicitly:
No file containing credentials, secrets, API keys, tokens, or environment variables — whether hardcoded, commented out, or stored in .env files — may be submitted to any AI coding assistant, regardless of tool tier. Pre-commit scanning is mandatory on all repositories containing Tier 2 or Tier 3 code.
Make enforcement automatic, not honor-system. A pre-commit hook that blocks the commit if a secret pattern is detected is more reliable than a policy paragraph. Both are needed: the policy creates the legal obligation; the technical control makes it real.
Here's a pattern that causes real compliance problems: an engineer is writing tests for a data processing feature and grabs a slice of real production data to use as a fixture because it's faster than synthesizing realistic fake data. That fixture file — now sitting in the repo or in a local working directory — contains actual customer records: names, email addresses, transaction histories, or in some industries, health or financial data.
When that engineer pastes the test file into an AI coding assistant to ask for help writing the test assertions, they've just exposed customer data to a third-party AI provider. Under GDPR Article 28, that transmission may constitute processing by a sub-processor, requiring a data processing agreement with the AI vendor that most companies haven't executed for free or standard-tier tools. Under HIPAA, transmitting PHI to a business associate without a signed Business Associate Agreement (BAA) — 45 CFR § 164.502(e) — is a violation regardless of intent.
The policy requirement here has two parts:
This is an area where engineering teams genuinely don't know they're creating a compliance problem — they're just trying to write good tests. The policy needs to explain the why, not just issue a prohibition. For a broader look at how unmanaged AI tool use creates data exposure risks across departments, see our overview of what shadow AI is and why it matters.
An engineering AI policy without a specific approved tool list is a suggestion, not a policy. Engineers will use whatever tool solves their problem fastest. Your job is to make the approved path the easy path — which means the approved list needs to actually include useful tools, not just restrict everything.
Here's how to structure the approved tool list:
| Tool | Approved Tier | Data Input Restriction | Notes |
|---|---|---|---|
| GitHub Copilot (Business/Enterprise) | Tier 1 & 2 | No Tier 3; no credentials; no customer data | Enable duplication filter; Business tier does not train on your code by default |
| Cursor (Business) | Tier 1 & 2 | No Tier 3; no credentials; no customer data | Cursor Business offers a zero-data-retention mode; confirm it's enabled org-wide |
| Claude (via Anthropic API or Claude for Work) | Tier 1 & 2 | No Tier 3; no credentials; no customer data | API and Claude for Work plans do not use inputs for training; verify current terms at anthropic.com/legal/privacy |
| Claude Code (Anthropic API) | Tier 1 & 2 | No Tier 3; no credentials; no customer data | Agentic tool — review which directories it has access to before enabling in CI/CD |
| Free/consumer tiers of any tool | Tier 1 only | Public code only; no internal code of any kind | Consumer tiers often train on inputs; treat as public disclosure |
The key distinction in this table is enterprise vs. consumer tier. Free versions of every major AI coding tool should be treated as public disclosure channels for anything you put into them — because their terms of service often reserve the right to use inputs for model improvement. Your engineers need to know this isn't about distrust; it's about what the vendor's contract actually says.
To build a complete policy that covers engineering alongside your other departments, you can generate a tailored policy kit that includes role-specific input rules, approved tool lists, and data classification guidance. For more on structuring the broader acceptable use framework, see our AI acceptable use policy template guide.
About Shadow AI Policy: We build AI acceptable use policy tools for HR and operations teams at 50–500 person companies. We publish guides on shadow AI, acceptable use policies, and AI governance, updated as regulations and AI tools change.
Copilot Individual (the personal subscription) does send code snippets to GitHub's servers and, depending on settings, may use them for product improvement — meaning your proprietary code could be used as training signal. Copilot Business and Enterprise explicitly exclude customer code from model training by default and include a data processing agreement. For any code beyond Tier 1 (public or low-sensitivity), only the Business or Enterprise tier should be on your approved list.
Yes, significantly. Standard chat-based coding assistants receive whatever you paste. Claude Code in agentic mode can read files, list directories, and execute commands — which means it may access files you didn't consciously choose to share, including configuration files, .env files, or test fixtures with real data. Before enabling Claude Code in any automated or CI/CD context, audit exactly which directories and environment variables it can access, and apply the same Tier 2/Tier 3 restrictions to those paths that you'd apply to manual inputs.
If the code itself processes, stores, or transmits protected health information (PHI) — or if any test fixtures contain PHI — then yes, using an AI coding assistant on that code without a signed Business Associate Agreement with the vendor likely violates HIPAA's BAA requirement under 45 CFR § 164.502(e). Most AI coding tool vendors do not offer BAAs on standard commercial tiers. In that situation, either obtain a BAA (some enterprise programs will negotiate this) or classify that code as Tier 3 and prohibit AI assistant input entirely.
Treat personal-tier subscriptions on work devices as a shadow AI risk and address them explicitly in policy. The policy should state that only company-provisioned or company-approved tool accounts may be used for work code, regardless of device. Technical controls — network-level blocking of consumer endpoints, endpoint DLP, or IDE extension allowlists via MDM — are more reliable than policy alone. If you allow BYOD, the policy needs to explicitly extend to personal devices used for any work-related coding, not just company-issued hardware.
Tailored to your industry and the AI tools your team uses. Free preview, then $149/mo to keep it current as the rules and vendor terms change — or $79 for a one-time snapshot.
Generate my policy kit →Writing policies for several clients? MSPs, IT consultancies and fractional CISOs keep a roster of client kits that refresh monthly, under their own branding. See partner plans →