Tracking Unattributed Code Injected by AI Coding Agents

A pull request arrives with 400 lines of pristine, working TypeScript. It implements an exact-match Aho-Corasick automaton for fast token scanning. The unit tests pass, edge cases are covered, and variable naming adheres strictly to your style guide. A coding agent generated the entire block in three seconds.

Nobody on your team wrote it, and nobody can verify where the logic originated.

The code works, but you have introduced a blind spot into your repository. If that implementation was drawn from an AGPL-3.0 or source-available repository, your project has just absorbed downstream obligations without recording them. Treating agent output as purely original code creates the same risk profile as vendoring code without a paper trail: you inherit the operational liability of third-party software while discarding the metadata needed to defend it.

The Stripped-Header Problem

Generative models ingest vast corpora of open-source software, internalising algorithmic structures, specific data structures, and edge-case workarounds. When an agent outputs non-trivial algorithms, it frequently reproduces these structures closely—sometimes verbatim—while omitting the copyright notices, license headers, and attribution files that accompanied the source.

This failure mode directly undermines license compliance. An MIT or Apache-2.0 license permits reuse, but almost universally requires retaining the original copyright notice and license grant. When an agent drops those lines, the resulting file violates the upstream license terms the moment it is committed and distributed.

// What the agent generated:
export class AhoCorasick {
  private gotoFn: Map<number, Map<string, number>> = new Map();
  private output: Map<number, Set<string>> = new Map();
  private fail: Map<number, number> = new Map();
  // ... 400 lines of uncredited traversal logic
}

The issue is not whether models are allowed to learn from open code; the issue is that your organisation now ships software with severed code lineage. Without an audit trail connecting generated logic to its origin, you cannot verify whether the code requires attribution, copyleft disclosures, or patent grants.

Why Code Review Does Not Catch It

Human code review is designed to catch logic errors, architectural misfits, and style deviations. It fails predictably at identifying missing provenance.

When a reviewer inspects an agent's pull request, they look for:

1. Correctness against the acceptance criteria.
2. Adequate test coverage.
3. Clean abstractions and type safety.

A reviewer cannot visually distinguish an original implementation of an interval tree from one lifted directly from an uncredited copyleft project. If the code compiles and passes CI, it looks like high-velocity engineering.

By the time the code reaches production, the context of its creation is lost. Six months later, during a due-diligence audit or an internal compliance review, tracing 400 lines of uncredited logic back to its training origin is practically impossible.

Establishing Pre-Merge Software Provenance

Fixing this requires shifting verification upstream into the pipeline before an agent's branch merges into trunk.

First, enforce explicit origin boundaries for automated contributions. If an agent writes or modifies code, the commit metadata must record the agent's identity, the model checkpoint, and the exact prompt inputs that produced the diff. This forms the baseline for software provenance, ensuring that every automated line can be isolated during an audit.

Second, integrate snippet-level matching into your CI pipeline. Standard dependency scanners check package manifests (such as package.json or Cargo.toml), but they miss unattributed snippets pasted into first-party source files. Snippet indexers match structural abstract syntax trees (ASTs) against public source corpora to flag uncredited blocks before merge.

Third, maintain an auditable ledger for generated components. Coupling these additions with automated SBOM generation ensures that even non-packaged, inline implementations retain their provenance records alongside standard third-party dependencies.

[Agent Proposal] -> [AST Snippet Scan] -> [License Resolution] -> [Signed Merge]
                                                   |
                                            (Flagged / Blocked)

Snippet matching is not perfect. It can produce false positives on trivial boilerplate, and it cannot detect heavily modified logic where the AST structure has been scrambled. However, for dense, non-trivial algorithmic code—where license exposure is highest—it provides a verifiable paper trail that manual review cannot match.

What to Do on Monday

To regain control over untracked agent contributions:

1. Tag automated commits at the gate. Add a commit-hook policy or CI rule requiring all agent-generated pull requests to carry a machine-readable trailer (for example, Co-authored-by: AgentName <agent@local>). Do not let agent code masquerade as developer-written commits.
2. Scan the largest recent agent PRs. Run a snippet-matching or clone-detection tool across the five largest agent-authored pull requests merged in the last quarter. Look specifically for complex algorithms, parsers, or mathematical routines.
3. Establish an attribution fallback policy. When an agent introduces a complex algorithm that cannot be verified against a clean root of trust, require developers to either link to an approved, fully-attributed upstream dependency or replace the generated block with an auditable implementation.

AI code attribution cannot be solved after code is mixed into production. Capture the lineage before the pull request merges, or do not accept the diff.