Su agente de programación eligió la biblioteca correcta. Puede que su empresa no tenga permitido usarla

Se le pide a un agente de programación que añada exportación a PDF a una herramienta interna. Encuentra una biblioteca bien mantenida que hace exactamente eso, escribe código limpio a su alrededor y abre un pull request. Las pruebas pasan. La licencia de la biblioteca es una que el equipo legal de su empresa decidió hace años que la compañía no usaría en software que distribuye.

Nadie hizo nada mal en esa historia, y ese es el problema. El agente optimizó para la tarea, el revisor miró el código, y la política de licencias vivía en una página wiki que ninguno de los dos leyó. Los desarrolladores humanos aprendieron esa política despacio, mediante onboarding y alguna fusión rechazada ocasional. Los agentes añaden dependencias a velocidad de máquina y no aprenden nada entre sesiones a menos que alguien se lo escriba.

Qué lanzó GitHub

El 16 de octubre GitHub puso open source license compliance en disponibilidad general (GA) para GitHub Enterprise Cloud, incluida la modalidad de Enterprise Cloud con residencia de datos, en repositorios con GitHub Code Security habilitado. Esa modalidad tiene una opción en la UE, relevante para empresas de España y del resto de la UE que eligieron mantener sus datos de GitHub en Europa. Tres partes importan:

• Una política para toda la empresa. Las reglas de licencias se definen una vez y se aplican mediante rulesets, no repositorio por repositorio.
• Una barrera en la fusión. Una condición de ruleset, “Require license compliance results before merging”, bloquea los pull requests que añaden o cambian dependencias incumpliendo la política, con una anotación por cada dependencia no conforme. GitHub lo describe como una ampliación de dependency review.
• Una API para agentes. Un nuevo endpoint comprueba si los paquetes cumplen la política, lo que según GitHub permite que los agentes eviten recomendar o añadir paquetes no conformes. Otros endpoints descargan, actualizan y reemplazan la propia política.

Un pull request bloqueado se puede resolver de tres formas: sustituir la dependencia, cambiar la política o solicitar una excepción de paquete. Las excepciones pasan a un nuevo rol, Enterprise Open-Source License Manager, y los cambios de política aparecen en el registro de auditoría. Los datos de licencias, en preview desde junio, también alimentan el gráfico de dependencias y las exportaciones SBOM.

La barrera es la red de seguridad; la API es el control

Una barrera en la fusión detecta la infracción en el momento más caro: después de que el agente ha escrito código en torno a la biblioteca y un revisor ha dedicado tiempo. La API es lo que traslada la comprobación al inicio, cuando el agente elige entre candidatas.

Pero que exista un endpoint no significa que un agente lo llame. Nada en un modelo hace que consulte su política de licencias antes de escribir un npm install. Si la comprobación importa, intégrela en el flujo de trabajo del agente: una herramienta expuesta al agente, una línea en las instrucciones del agente del repositorio que exija la comprobación antes de añadir cualquier dependencia, o un paso en el harness que la ejecute automáticamente en cada cambio propuesto de manifiesto. Después mídalo: con qué frecuencia los pull requests de agentes siguen llegando a la barrera de fusión le dice si la comprobación temprana funciona. Hicimos el mismo planteamiento sobre políticas de seguridad que nunca llegan al agente de programación.

Quién aprueba la excepción

El nuevo rol es la parte más subestimada del lanzamiento. Las excepciones son donde realmente ocurre la gobernanza de licencias, y no deberían aprobarlas la persona, o el agente, que quiere la dependencia. Poner las solicitudes de cierre en manos de un responsable de licencias designado, con un registro de auditoría, separa al autor del cambio del aprobador del riesgo. Esa es la segregación que defendimos que necesitan los agentes en gestión del cambio.

Qué no resuelve una comprobación de licencias

Tres límites merecen decirse sin rodeos a los líderes de ingeniería:

• Permitido no es seguro. Una licencia permisiva no dice nada sobre mantenimiento, vulnerabilidades o una versión comprometida. La política de licencias se sitúa junto a la seguridad de la cadena de suministro, no en su lugar, como hace el propio conjunto de herramientas de seguridad de GitHub.
• La aceptabilidad depende del uso. Que una licencia sea aceptable a menudo depende de cómo se distribuye o se ofrece el software a otros. Una única lista de permitidos puede ser demasiado estricta para herramientas internas y demasiado laxa para un producto que usted distribuye. Puede que las políticas deban variar según la clase de repositorio, algo a lo que los rulesets pueden apuntar.
• La cobertura depende de la configuración. La barrera se aplica donde está configurado el ruleset de empresa y GitHub Code Security está habilitado. Los repositorios fuera de ese ámbito quedan fuera del control.

La lección más amplia va más allá de GitHub. Los agentes siguen las reglas que pueden leer y llamar. Toda política que hoy vive en un wiki, una diapositiva o la memoria de un ingeniero sénior es una política que sus agentes incumplirán a escala, no por malicia, sino porque nadie la convirtió en algo que una máquina pueda comprobar.