Una política que no llega al agente de código no es un control. GitHub ya permite que Copilot falle cerrado

Un administrador endurece las reglas del agente de código de Copilot el lunes por la mañana: sandbox activado, una opción arriesgada desactivada. El lunes por la tarde, un desarrollador abre un portátil que ha pasado el fin de semana sin conexión. ¿Con qué política funciona el agente?

Hasta ahora, a menudo con la antigua. Los clientes de Copilot guardan en caché la configuración gestionada, lo que agiliza el arranque y permite seguir trabajando durante una caída breve del servicio. También significa que un cambio de política llega a cada equipo solo cuando ese equipo vuelve a actualizarse. Para el autocompletado, el desfase apenas importaba. Para un agente que ejecuta comandos, edita archivos y llama a herramientas, es la distancia entre la política que el administrador cree vigente y la que realmente se aplica.

Lo que ha lanzado GitHub

El 13 de octubre, GitHub añadió dos controles de aplicación a la configuración gestionada de Copilot para empresas.

Actualización forzada al arrancar. Poner forceRemoteSettingsRefresh en true, mediante configuración gestionada en el servidor, por MDM o por archivo, obliga a los clientes compatibles a obtener la configuración vigente del servidor al arrancar en lugar de fiarse de la caché. “Si el cliente no puede confirmar la política vigente, falla cerrado en lugar de funcionar con una política obsoleta o sin confirmar.” Los clientes compatibles son Copilot CLI, VS Code y la app GitHub Copilot. Un requisito previo: para los valores gestionados en el servidor, la actualización forzada se aplica en los arranques siguientes solo después de que el cliente haya recibido el valor una vez. La entrega por MDM o por archivo puede exigir una obtención nueva antes del primer inicio de sesión.

Versión mínima del cliente para el sandbox. Cuando la clave sandbox está en la configuración gestionada, quienes fijaron versiones antiguas del cliente “tendrán que actualizar para volver a usar Copilot”. El sandbox en sí es una capacidad local con disponibilidad general (GA); GitHub dice que la exigencia de versión mínima llegará con el tiempo a otras claves de gobierno. Por ahora, solo afecta a la clave sandbox.

Fallar cerrado es una decisión, no un valor por defecto

Fallar cerrado es el comportamiento correcto para un control de seguridad. También es una elección con costo: si el cliente no llega al servicio de políticas, por un problema de red, un proxy que bloquea la llamada o una caída, el desarrollador no puede usar Copilot hasta que llegue. Por eso GitHub mantiene la caché como comportamiento por defecto.

La decisión debe tomarse por colectivos, no para toda la empresa:

• Falle cerrado donde el agente llega a código sensible, credenciales de producción o datos regulados, y donde una política sin confirmar es peor que una hora sin asistente.
• Mantenga la caché donde los desarrolladores trabajan a menudo sin conexión y las acciones permitidas al agente ya son limitadas.
• Planifique la primera entrega. Como la primera entrega de la configuración gestionada en el servidor tiene que salir bien antes de que empiece la aplicación, un equipo nuevo queda brevemente bajo lo que tuviera antes. La entrega por MDM o por archivo cierra esa ventana.

La lección general para el gobierno de agentes

Los controles de los agentes de código viven cada vez más en el cliente: qué modelos se permiten, si el sandbox está activo, qué servidores MCP pueden arrancar. Señalamos en una actualización reciente que un valor por defecto en Copilot no es una política. Este lanzamiento responde a la pregunta siguiente: si la política que sí es política llegó de verdad.

Todo control aplicado en un endpoint tiene tres modos de fallo: la política es errónea, la política está desactualizada o el cliente es demasiado antiguo para entenderla. Las consolas centrales muestran el primero. Este lanzamiento permite cerrar el segundo y empieza a cerrar el tercero. Las mismas preguntas valen para cualquier agente que se ejecute en equipos de desarrolladores, de cualquier proveedor:

1. ¿Cuánto tiempo puede funcionar un cliente con una política en caché?
2. ¿Qué hace cuando no puede confirmar la vigente?
3. ¿Puede un cliente antiguo ignorar una configuración que no reconoce?

Si las respuestas son “indefinidamente”, “sigue funcionando” y “sí”, las políticas de la consola describen intenciones, no controles efectivos. El argumento de contención que planteamos en fronteras del agente fuera del modelo solo se sostiene si la configuración de esa frontera llega al equipo que debe proteger.