Who Owns the Code Your AI Wrote? Licensing and IP for Assisted Teams

The security team gets pulled into IP questions more than you'd expect, because "can we legally ship this" lives in the same review gate as "is this safe to ship." AI-written code has made both harder. Here's what a working engineer actually needs to know in 2026, minus the parts only a lawyer can decide.

Standard disclaimer that is not boilerplate: I'm an engineer, not counsel, and this is jurisdiction-dependent. Use this to ask better questions internally, not as legal advice.

Does anyone own AI-generated code at all?

Start with the uncomfortable base case. In the United States, the Copyright Office has held consistently that purely machine-generated output isn't copyrightable because it lacks human authorship. The 2023–2025 guidance and the cases around it point the same way: copyright attaches to human creative contribution, not to the raw model output.

For most application code this is a non-issue, because your engineers heavily edit, arrange, and integrate the output. The human authorship in selection and arrangement is usually enough to make the resulting codebase protectable as your work. The risk sharpens for verbatim, unedited generation of substantial chunks. If a competitor lifted a function your model wrote and nobody touched, your ability to claim infringement is genuinely weaker than for hand-written code. Practical takeaway: the more your team treats AI output as a first draft they own and reshape, the stronger your position, on top of it just being better engineering.

The real exposure: license contamination from training data

The bigger operational risk isn't ownership of new code, it's the model reproducing someone else's licensed code into your repo. Models trained on GitHub have memorized GPL, AGPL, and other copyleft snippets, and they will occasionally emit them close to verbatim, stripped of the license header that would have warned you.

Why this matters concretely: if AGPL-licensed code lands in your proprietary service, a strict reading of that license can obligate you to release your own source. That's a business-ending clause for some products. The header that carried the obligation is exactly what the model dropped.

Copilot, Cursor, and the other major assistants ship a duplication-detection or public-code filter. Turn it on org-wide and verify it's enforced, not just defaulted.

# GitHub Copilot org policy to enforce
Policies > Suggestions matching public code: Blocked

The filter matches roughly 150 characters against public code and suppresses the suggestion. It's necessary and not sufficient. It won't catch reworded-but-substantially-similar output, and it does nothing for code pasted in from a chat UI outside the IDE.

Scan for license problems the way you scan for vulnerabilities

Treat license provenance as part of your supply chain. The same SCA tooling that flags CVEs will flag license conflicts, and it should run in CI on AI-assisted branches too.

# Generate an SPDX SBOM and check declared licenses
syft dir:. -o spdx-json > sbom.json
grype sbom:sbom.json          # vulns
# license policy gate
license-checker --failOn 'GPL-3.0;AGPL-3.0;SSPL-1.0'

For the code the model wrote directly, dependency scanners won't help — there's no package manifest entry. This is where a scanner like scancode-toolkit earns its place; it fingerprints source files against known license text and flags suspiciously familiar blocks.

scancode --license --copyright --json-pretty-print out.json ./src

If a reviewer sees a function that's unusually complete, idiomatic in a style unlike the rest of the file, or carries a distinctive algorithm, that's a prompt to search the exact string on public code before merging. Uncanny fluency is a tell.

Read your vendor's indemnity, then read the exceptions

By 2026 the major vendors offer IP indemnification: Microsoft's Copilot Copyright Commitment, Anthropic's and others' customer indemnity for their paid/enterprise tiers. This is real protection, but it comes with conditions that engineering controls, not lawyers, have to satisfy. Typical carve-outs:

• The duplication/public-code filter must be enabled. Disable it and you often void coverage.
• You must not have modified the output in a way that introduces the infringement, and sometimes must not knowingly prompt for infringing content.
• Coverage is usually tied to the paid enterprise tier, not free or personal accounts.
• Consumer chat products frequently have weaker or no indemnity than the API/enterprise SKUs from the same vendor.

The failure mode I see: a team relies on "we're indemnified" while half the developers use personal free-tier accounts with the filter off. The indemnity is worthless there. Make the enterprise tier and the filter a hard requirement, and log which tool produced significant generated code.

Your own inputs: don't leak IP the other direction

Licensing risk runs both ways. When engineers paste proprietary source, secrets, or customer data into a chat assistant, you may be granting the vendor rights to that content or simply exfiltrating it. Check the data-use terms for the specific tier. Enterprise agreements generally promise no training on your inputs and zero-retention options; consumer tiers often reserve training rights unless you opt out.

Concretely, set this at the account and network layer, not by asking people nicely:

• Enterprise/business tiers with a signed DPA and training opted out for anything touching source.
• Zero-data-retention endpoints where the vendor offers them for regulated data.
• Pre-commit and DLP hooks that block secrets from leaving, since people paste code with credentials in it.

A policy that fits on one page

The teams that stay out of trouble write down a short, enforceable standard. Mine looks roughly like this:

1. Only approved enterprise-tier tools, public-code filter mandatory, verified by admin policy.
2. AI-assisted code is reviewed and materially edited before merge; no dumping large verbatim blocks.
3. CI runs SBOM + license gate + a source-license scan; copyleft licenses fail the build unless pre-approved.
4. No proprietary source, secrets, or regulated data into any tool without a DPA and training opt-out.
5. Record when a substantial component was AI-generated, so provenance is answerable later.

None of this slows a competent team down once it's wired into CI. It converts a fuzzy legal anxiety into a few pass/fail checks. That's the whole trick: make provenance and licensing a gate the pipeline enforces, so shipping AI-assisted code is a decision you've already made, not a risk you're rediscovering per pull request.