GitHub License Compliance Moves the Dependency Check in Front of Your Coding Agent

The merge gate catches a bad license after the work is done. The new part is a check your agent can ask first.

Nobody reads the license of the package their coding agent just installed.

That used to be fine, because a human typed npm install and at least glanced at the package page first. Now an agent adds the dependency, writes forty lines that call it, runs the tests, and opens a pull request. If the package turns out to be AGPL in a closed-source product, the problem lands at the very end, after the agent has built on top of it.

GitHub's open source license compliance became generally available on October 16, and most of the coverage will focus on the merge gate. The more interesting line in the changelog comes near the end: "There is also a new API endpoint for checking whether packages comply with policy." GitHub says the point is to let coding agents avoid recommending or pulling in packages that break a company's license policy.

That sentence admits something. When an agent picks your dependencies, a check that only fires at the pull request is a cleanup tool. The rule has to reach the agent before it writes the import.

Here's what shipped, what it can't do yet, and how to get most of the benefit this week even if you're nowhere near GitHub Enterprise.

What GitHub shipped on October 16

The feature checks the licenses of your dependencies against a policy your company sets once.

A license, if you haven't had to think about it, is the legal permission slip that comes with open source code. Some (MIT, Apache-2.0) let you do nearly anything. Others (GPL, AGPL) require you to share your own source code under certain conditions. A legal team usually keeps a list of the ones it's comfortable with.

GitHub's version works in three parts, according to the changelog and the setup guide:

1. A policy. An enterprise admin picks the allowed licenses from a list, or pastes in SPDX identifiers (SPDX, short for Software Package Data Exchange, is the standard set of short license codes like MIT or Apache-2.0), one per line.
2. A gate. A branch ruleset (GitHub's name for branch protection rules that can apply across many repos) turns on a condition called "Require license compliance results before merging." When a pull request changes a package manifest, like package.json or requirements.txt, GitHub compares the dependencies before and after, including indirect ones it can detect, and flags anything outside the policy. The dependency graph has to be turned on for each repo it checks.
3. An exception path. A developer who needs a flagged package can request an exception. A new role, the Enterprise Open-Source License Manager, approves or denies it, scoped to one package, one license, or a package pattern.

The gate has two modes. In Evaluate mode, it annotates the pull request but lets it merge. In Active mode, the concept docs say pull requests with violations are blocked until someone resolves them.

Since the June preview, GitHub also added license data for data-residency customers, audit log events when the policy changes, API endpoints to download, update, and replace the policy, and that package-check endpoint aimed at agents.

Why a merge gate is the wrong place to catch an agent

Picture the difference between a bouncer at the door and a bouncer at the exit.

A merge gate is the exit. Everything has already happened inside. The agent chose the package, wrote code shaped around its API, maybe pulled in three transitive dependencies (packages your package depends on), and wrote tests. The gate says no. Now someone has to find a replacement, and the agent has to redo work it already finished.

With a human developer, that cost is small, because humans add dependencies rarely and on purpose. Agents add them casually. Ask for a date picker and you might get a new package before you finish reading the plan. The faster an agent works, the more expensive a late "no" becomes, because more work stacks on top of the bad choice.

A check the agent calls before it installs is the door. It costs one request and changes the agent's first choice instead of its fifth draft.

Put the policy before the code and the gate after it. That's the whole model.

So the API is the real story. The merge gate stays useful as the backstop, the thing that catches what the agent forgot to ask about. But the expensive part of a license mistake is the rework, and only the early check prevents that.

The catch: the agent-facing part isn't documented yet

Here's the awkward part. GitHub's docs were still catching up on October 17. One version of the setup guide we read still carried a "public preview" note, and we couldn't find the package-check endpoint's path, parameters, or required permissions anywhere in the REST reference. The dependency graph REST reference that the changelog links to covers dependency review, dependency submission, and SBOM (software bill of materials, a full inventory of what's in your software) endpoints, and no license-policy or package-compliance endpoint.

So the piece of this launch built for agents is announced, but you can't yet build against it from the docs alone. Expect that to change soon. Until it does, the practical work is the policy, the gate, and getting the allow list in front of your agent another way.

There's also an audience problem. The feature is for GitHub Enterprise Cloud customers with GitHub Code Security turned on. If you're a solo developer or a small team on a regular plan, none of this applies to you directly.

You can still get most of the benefit.

Put this into practice

Pick the track that fits your setup. Both end in the same place: the agent knows the rules before it adds anything, and something checks after.

If you're on GitHub Enterprise Cloud

Roll it out in Evaluate mode first. The setup guide suggests a custom repository property so you can switch repos over one at a time:

1. In your enterprise, go to Policies, then License compliance, then Default policy, and add the licenses you allow. If you're moving from another tool, use Manual input and paste your SPDX list.
2. Assign the Enterprise Open Source License Manager role to whoever should approve exceptions.
3. In each organization, create a single-select custom property (the guide's example is open_source_license_compliance) with the values inactive, evaluate, and active, defaulting to inactive.
4. Create two branch rulesets, one with enforcement status Evaluate targeting repos marked evaluate, and one set to Active targeting repos marked active. Enable Require license compliance results before merging on both.
5. Open a test pull request that adds a dependency and check the annotation.

What to expect: in Evaluate mode, pull requests that add a disallowed license get an annotation and still merge. Run it for a couple of weeks, look at how often it fires, and fix the policy before you flip anyone to Active.

If you're not on Enterprise

GitHub's dependency-review-action does a similar license check in a regular GitHub Actions workflow. It runs on public repositories, and on private repositories with a GitHub Advanced Security license. Add a workflow like this:

name: 'Dependency Review'
on: [pull_request]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v6
      - name: 'Dependency Review'
        uses: actions/dependency-review-action@v5
        with:
          allow-licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC

Use allow-licenses, not deny-licenses. The README marks deny-licenses as deprecated, and the two options can't be combined.

What to expect: a pull request that adds a dependency with a license outside your list fails the check. A failing check only stops a merge if a branch protection rule or ruleset marks it as required, so turn that on too. Read the limitations, though, because there's a gap.

For everyone: tell the agent the rules up front

Until GitHub documents the package-check API, the cheapest way to move the check in front of the agent is to write the rule where the agent reads its instructions. That means AGENTS.md, CLAUDE.md, or whatever file your tool loads at the start of a session. Something like:

## Dependencies
- Allowed licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC.
- Before adding any package, state its name, version, and license in your plan.
- If the license is not on the list, or you can't find it, stop and ask.
- Prefer the standard library or an existing dependency over a new one.

This won't make the agent perfect. It will make it say the license out loud, which turns a silent choice into one you can catch in the plan, before any code exists.

Honest limitations

Unknown licenses can slip through. The dependency-review-action README says that if it can't detect a dependency's license, "we will inform you, but the action won't fail." A package with no license file or a weird custom one passes the check unless someone reads the warning. GitHub's docs for the Enterprise feature don't say how they handle undetected licenses at all.

A license is not a safety check. A package can be MIT-licensed and still be abandoned, malicious, or a typo-squat of a real package. Keep vulnerability and supply-chain checks running separately.

The agent-facing API isn't documented well enough to call yet. As of this writing, we couldn't find its endpoint path, request format, or permissions in GitHub's REST reference.

Instructions are a request, not a lock. An agent can ignore a line in AGENTS.md, especially deep in a long session. That's why the gate after still matters.

Legal judgment isn't automated. GitHub's own guide says the license risk categories are informational and to "always check with your organization's legal team."

The part worth deciding this week

Agents are going to pick more of your dependencies than you do. That's already true on a lot of teams. The question is where your license rules live: in a gate that cleans up after the work, or in front of the agent before it starts.

GitHub just announced it's building toward the second one. You don't have to wait for the docs to catch up. Write your allow list into the file your agent reads, add a check on pull requests, and look at the next plan your agent hands you. If it names a license you've never heard of, you caught it at the cheapest possible moment.

Sources: GitHub changelog, October 16, 2026 · GitHub Docs: open source license compliance · GitHub Docs: configure license policies · GitHub REST API: dependency graph · actions/dependency-review-action README. Docs read October 17, 2026.