Copilot puede aprobar una acción sin cambiar quién le dio acceso

GitHub anunció el 26 de octubre la disponibilidad general de permisos asistidos en CLI, app y VS Code: un modelo evalúa solicitudes elegibles de comandos, archivos y URLs. Los administradores pueden restringir Assisted y Allow All por separado y definir el modo predeterminado. (GitHub)

Un encargo necesita un límite comprensible

«Arregla esta incidencia» identifica un objetivo, pero puede dejar abiertas decisiones sobre datos, entornos y efectos. Describe el resultado que buscas, los recursos autorizados y qué acciones necesitan otra decisión. Ese alcance ayuda tanto a la revisión de una solicitud como a la persona que evalúa la entrega.

Una lectura puede alcanzar un archivo confidencial; un comando breve puede modificar muchos registros. Clasificar por el nombre de la herramienta resulta insuficiente. Revisa el objetivo concreto, la ruta, el entorno y el efecto esperado. El criterio debería poder explicarse sin depender de una puntuación opaca.

Las reglas y el cliente importan

En CLI, ask empresarial puede resolverlo el modelo; deny sigue vigente. En ejecución desatendida, lo pendiente de aprobación se deniega. Las sesiones cloud de la app no tienen esos controles. Si Assisted no está disponible, --allow-all-tools puede seguir vigente: no atribuyas protección a una revisión ausente. (GitHub)

Por eso, no registres «pide confirmación» como una garantía general. Comprueba el modo efectivo de la sesión y la política aplicable al cliente y host concretos. Una preferencia guardada para sesiones nuevas tampoco demuestra cómo opera una sesión ya abierta.

Prueba también la acción que debe detenerse

Prepara un repositorio de ejemplo sin secretos y define por escrito una acción permitida y otra fuera de alcance. En un ensayo interactivo, comprueba cómo se presenta o resuelve la solicitud. En uno desatendido, revisa qué ocurre cuando queda una decisión pendiente y qué estado recibe el proceso que lo inició.

La matriz es un plan de comprobación, no una prueba realizada por KIURO. No hace falta conceder acceso a producción para comprobar un límite. El resultado útil incluye lo que el agente intentó, la decisión aplicada y la evidencia de que el recurso quedó dentro o fuera del alcance acordado.

• Anota cliente, host, versión, modo efectivo y política que gobierna la sesión.
• Distingue una petición detenida de un trabajo terminado correctamente.
• Comprueba que una denegación se conserva cuando cambias de modo o reanudas una sesión.
• Investiga advertencias de configuración antes de atribuir el resultado a la revisión asistida.
• Revisa la entrega y sus efectos aunque no haya aparecido una pregunta en pantalla.

La aprobación y el aislamiento tienen trabajos distintos

La aprobación es una decisión sobre una acción solicitada. Las restricciones del proceso delimitan qué puede alcanzar, mientras que la revisión del resultado comprueba qué terminó ocurriendo. Diseña las tres de forma que puedas observar sus límites por separado. Reducir preguntas no debería convertir una operación incierta en una operación aceptada.

Si un flujo se detiene, guarda la causa antes de ampliar permisos. Quizá falte una autorización concreta, una capacidad del entorno o una ruta de trabajo que respete el alcance. La respuesta útil es resolver esa dependencia, con evidencia, y volver a revisar lo que cambió.

Qué significa haber evaluado esta función

Cierra con una relación de acciones, reglas, estados observados y limitaciones. Identifica el trabajo que seguirá necesitando una persona y quién revisará cambios de política. Disponibilidad general no demuestra que una función esté habilitada en tu organización ni que todos los clientes se comporten igual.

Los planes del proveedor y el tiempo de operación deben valorarse para el uso concreto; este análisis no publica una tarifa ni calcula productividad. Tampoco convierte una revisión de permisos en una certificación de seguridad. El siguiente paso es una evaluación pequeña con datos ficticios y restricciones que puedas inspeccionar.