Resolving License Invariants at the Agent Write Boundary

A pull request lands with 400 lines of clean, idiomatic code. The unit tests pass. The linter is silent. The reviewer scans the diff, sees no obvious regressions, and hits approve.

Two months later, an audit asks where the bespoke token-bucket rate limiter came from. The engineer who prompted the model cannot answer. The model synthesized the logic, but nobody can verify whether those forty lines were constructed from first principles or reproduced near-verbatim from a repository licensed under AGPL-3.0.

This is the provenance void. When teams adopt AI coding agents, they quietly dismantle the license boundaries they spent a decade constructing around their package managers.

The Reviewer Cannot See Provenance

Human code review is designed to evaluate design, style, and correctness. It is not designed to detect copyleft contamination in arbitrary syntax trees.

When an engineer pulls in an open-source library, the dependency manager forces an explicit transaction. There is a package name, a version, and a manifest file containing an SPDX identifier. Automated compliance tooling scans the dependency tree in CI and alerts the team if an incompatible license enters the build.

AI coding agents bypass this entire mechanism. They do not declare dependencies; they emit raw source directly into the working tree. To a human reviewer, 400 lines of synthesized code look identical to 400 lines written by a colleague. You cannot eyeball a licensing conflict in a handwritten parser or an optimization routine.

Treating license compliance as a post-commit linting step in CI is already too late. Once unverified logic enters the git history, the repository is contaminated. Remediation requires rewriting history, proving non-infringement, or ripping out working features under audit pressure.

Enforcing Invariants at the Build Intent Gate

The control point must move upstream. The problem is not what the model generates; the problem is that the agent has write access before policy invariants are resolved.

Effective agent governance requires an intermediary layer between the agent's intent to write and the filesystem. We call this a build gate.

[Agent Emits Proposal]
         │
         ▼
[Build Intent Gate]
   ├── 1. Verify Origin & Attestation
   ├── 2. Resolve License Invariants
   └── 3. Check AST Signatures
         │
    ┌────┴───────────────┐
    ▼                    ▼
[PASS: Commit to Tree]  [FAIL: Terminal State Returned]

Under this model, an agent does not run raw file-system writes or unconstrained git commits. Instead, it submits a proposal to an intent gate. Before a single file on disk is modified, the gate evaluates the proposed change against strict invariants:

1. Explicit Provenance: Code introduced by the agent must have a determinable origin. If the agent is introducing reusable software components, it must pull them from verified, deterministic sources rather than hallucinating implementations of unknown legal provenance.
2. License Compatibility: The gate evaluates the incoming component's license against the target repository's policy. A proprietary commercial application can accept MIT or Apache-2.0 artifacts, but the gate immediately rejects copyleft or ambiguous sources.
3. Immutability of Policy: The agent cannot alter the gate's policy rules. The verification runs in deterministic code, outside the context window of the model.

If the proposal violates policy, the gate does not silently drop the write or leave a half-applied patch. It returns an explicit terminal state—a failure record stating exactly why the write was blocked. We detailed how these states work in our post on preventing blind agent writes with build intent terminal states.

By resolving these checks inside the gate, the working tree remains clean. The contaminated code never touches the branch, never enters the commit log, and never reaches a human reviewer.

What Is Genuinely Hard

A gate cannot magically infer the legal origin of a pure string emitted from an LLM's weights. If a model generates fifty lines of novel logic that happens to mirror a protected codebase, no static analyzer can reliably prove copyright status from the text alone. That is a fundamental limit of probabilistic generation.

What an automated gate can do is enforce structural boundaries:

• It can prevent agents from embedding third-party code without an accompanying provenance manifest.
• It can mandate that complex, high-risk logic (cryptography, parsers, protocols) be imported from verified catalogs with clear roots of trust rather than generated inline.
• It can fail closed whenever an agent attempts to introduce external dependencies or foreign source blocks that lack explicit compliance metadata.

You do not need to solve the entire copyright problem of machine learning to protect your repository. You only need to govern the write boundary. For a comprehensive look at this architecture, see our doctrine on governing code agents at the build intent gate.

What to Do on Monday

If your team is deploying AI coding agents, inspect the write path today.

1. Revoke direct write access. Strip autonomous agents of direct git commit or direct file-overwrite capabilities in shared branches.
2. Require structured proposals. Force agent outputs through an automated tool or harness that validates the payload before writing to disk.
3. Establish a strict allowlist. Define which licenses and artifact sources are acceptable, and write an invariant check that fails the build if an agent introduces code outside those boundaries.

Do not rely on human reviewers to spot foreign licensing terms in a sea of synthetic diffs. Put the check in the gate, run it deterministically, and fail before the write happens.