Your coding agent picked the right library. Your company may not be allowed to use it

A coding agent is asked to add PDF export to an internal tool. It finds a well-maintained library that does exactly that, writes clean code around it and opens a pull request. The tests pass. The library’s license is one your legal team decided years ago the company would not use in software it distributes.

Nobody did anything wrong in that story, which is the problem. The agent optimized for the task, the reviewer looked at the code, and the license policy lived in a wiki page neither of them read. Human developers learned that policy slowly, through onboarding and the occasional rejected merge. Agents add dependencies at machine speed and learn nothing between sessions unless someone writes it down for them.

What GitHub shipped

On October 16 GitHub made open source license compliance generally available for GitHub Enterprise Cloud, including data-resident Enterprise Cloud, on repositories with GitHub Code Security enabled. Three parts matter:

• One policy for the enterprise. License rules are defined once and applied through rulesets, rather than repository by repository.
• A merge gate. A ruleset condition, “Require license compliance results before merging,” blocks pull requests that add or change dependencies in violation of the policy, with an annotation for each noncompliant dependency. GitHub describes it as an expansion of dependency review.
• An API for agents. A new endpoint checks whether packages comply with the policy, which GitHub says lets agents avoid recommending or adding noncompliant packages. Other endpoints download, update and replace the policy itself.

A blocked pull request can be resolved in three ways: replace the dependency, change the policy, or request a package exception. Exceptions go to a new role, Enterprise Open-Source License Manager, and policy changes appear in the audit log. License data, in preview since June, also populates the dependency graph and SBOM exports.

The gate is the backstop; the API is the control

A merge gate catches the violation at the most expensive moment: after the agent has written code around the library and a reviewer has spent time on it. The API is what moves the check to the start, when the agent is choosing between candidates.

But an endpoint existing does not mean an agent calls it. Nothing in a model makes it consult your license policy before writing an npm install. If the check matters, make it part of the agent’s workflow: a tool exposed to the agent, a line in the repository’s agent instructions that requires the check before adding any dependency, or a step in the harness that runs it automatically on every proposed manifest change. Then measure it: how often agent pull requests still hit the merge gate tells you whether the early check is working. We made the same point about security policy that never reaches the coding agent.

Who approves the exception

The new role is the most underrated part of the release. Exceptions are where license governance actually happens, and they should not be approved by the person, or the agent, who wants the dependency. Putting closure requests with a named license manager, with an audit trail, separates the author of the change from the approver of the risk. That is the segregation we argued agents need in change management.

What a license check does not settle

Three limits are worth stating plainly to engineering leaders:

• Allowed is not safe. A permissive license says nothing about maintenance, vulnerabilities or a compromised release. License policy sits beside supply chain security, not in place of it, as GitHub’s own security tooling does.
• Acceptability depends on use. Whether a license is acceptable often depends on how the software is distributed or offered to others. A single allowlist may be too strict for internal tools and too loose for a product you ship. Policies may need to differ by repository class, which rulesets can target.
• Coverage depends on configuration. The gate applies where the enterprise ruleset is configured and Code Security is enabled. Repositories outside that scope are outside the control.

The broader lesson goes beyond GitHub. Agents follow the rules they can read and call. Every policy that today lives in a wiki, a slide or a senior engineer’s memory is a policy your agents will break at scale, not out of malice, but because nobody turned it into something a machine can check.