Seu agente de código escolheu a biblioteca certa. Sua empresa pode não ter permissão para usá-la

Pede-se a um agente de código que adicione exportação em PDF a uma ferramenta interna. Ele encontra uma biblioteca bem mantida que faz exatamente isso, escreve um código limpo em volta dela e abre um pull request. Os testes passam. A licença da biblioteca é de um tipo que o time jurídico da sua empresa decidiu, anos atrás, que não usaria em software que ela distribui.

Ninguém fez nada errado nessa história, e é aí que está o problema. O agente otimizou para a tarefa, o revisor olhou o código, e a política de licenças morava em uma página de wiki que nenhum dos dois leu. Desenvolvedores humanos aprendem essa política devagar, no onboarding e em um merge recusado de vez em quando. Agentes adicionam dependências na velocidade da máquina e não aprendem nada entre sessões, a menos que alguém escreva isso para eles.

O que o GitHub entregou

Em 16 de outubro, o GitHub colocou o compliance de licenças open source em disponibilidade geral (GA) para o GitHub Enterprise Cloud, incluindo o Enterprise Cloud com dados residentes, em repositórios com o GitHub Code Security habilitado. Três partes importam:

• Uma política para o enterprise. As regras de licença são definidas uma vez e aplicadas via rulesets, em vez de repositório por repositório.
• Um gate no merge. Uma condição de ruleset, “Require license compliance results before merging,” bloqueia pull requests que adicionam ou alteram dependências em violação da política, com uma anotação para cada dependência não conforme. O GitHub descreve isso como uma expansão do dependency review.
• Uma API para agentes. Um novo endpoint verifica se os pacotes estão em conformidade com a política, o que, segundo o GitHub, permite que agentes evitem recomendar ou adicionar pacotes não conformes. Outros endpoints baixam, atualizam e substituem a própria política.

Um pull request bloqueado pode ser resolvido de três formas: substituir a dependência, mudar a política ou pedir uma exceção de pacote. As exceções vão para um novo papel, Enterprise Open-Source License Manager, e as mudanças de política aparecem no log de auditoria. Os dados de licença, em preview desde junho, também alimentam o dependency graph e as exportações de SBOM.

O gate é a rede de segurança; a API é o controle

Um gate no merge pega a violação no momento mais caro: depois que o agente já escreveu código em volta da biblioteca e um revisor já gastou tempo nisso. A API é o que leva a checagem para o começo, quando o agente está escolhendo entre candidatas.

Mas um endpoint existir não significa que um agente o chame. Nada em um modelo faz com que ele consulte a sua política de licenças antes de escrever um npm install. Se a checagem importa, coloque-a no workflow do agente: uma ferramenta exposta ao agente, uma linha nas instruções de agente do repositório exigindo a checagem antes de adicionar qualquer dependência, ou um passo no harness que a execute automaticamente a cada mudança de manifesto proposta. Depois meça: com que frequência os pull requests de agentes ainda batem no gate do merge diz se a checagem antecipada está funcionando. Fizemos esse mesmo ponto sobre política de segurança que nunca chega ao agente de código.

Quem aprova a exceção

O novo papel é a parte mais subestimada do lançamento. As exceções são onde a governança de licenças de fato acontece, e elas não deveriam ser aprovadas pela pessoa, ou pelo agente, que quer a dependência. Concentrar as solicitações de exceção em um license manager nomeado, com trilha de auditoria, separa o autor da mudança do aprovador do risco. É a segregação que defendemos que agentes precisam em gestão de mudanças.

O que uma checagem de licença não resolve

Três limites merecem ser ditos com clareza para líderes de engenharia:

• Permitido não é seguro. Uma licença permissiva não diz nada sobre manutenção, vulnerabilidades ou uma release comprometida. A política de licenças fica ao lado da segurança da cadeia de suprimentos, não no lugar dela, como fazem as próprias ferramentas de segurança do GitHub.
• A aceitabilidade depende do uso. Se uma licença é aceitável muitas vezes depende de como o software é distribuído ou oferecido a terceiros. Uma única allowlist pode ser rígida demais para ferramentas internas e frouxa demais para um produto que você entrega. As políticas podem precisar variar por classe de repositório, o que os rulesets conseguem mirar.
• A cobertura depende da configuração. O gate se aplica onde o ruleset do enterprise está configurado e o Code Security está habilitado. Repositórios fora desse escopo ficam fora do controle.

A lição mais ampla vai além do GitHub. Agentes seguem as regras que conseguem ler e chamar. Toda política que hoje mora em uma wiki, em um slide ou na memória de um engenheiro sênior é uma política que os seus agentes vão quebrar em escala, não por maldade, mas porque ninguém a transformou em algo que uma máquina consiga checar.