La idea clave
Una automatización necesita definir quién puede iniciarla, por qué evento y con qué alcance.
Revisar el código de una automatización es solo una parte del trabajo. También importa quién puede ponerla en marcha. GitHub anunció el 17 de septiembre la disponibilidad general de las protecciones de ejecución de Actions, con reglas por actor, evento y archivo de workflow.
El anuncio oficial incluye un cambio futuro: una regla predeterminada para pull_request_target en repositorios públicos sin una política de eventos aplicable. Comienza en evaluación; GitHub prevé aplicarla el 2 de noviembre de 2026 a los repositorios afectados que usaban la política predeterminada antes de la disponibilidad general. No es un bloqueo inmediato de todos los workflows.
Comprueba el alcance antes de tocar la configuración
Según la documentación oficial, las protecciones están disponibles para repositorios públicos y para privados en GitHub Team o Enterprise. Las administran responsables del repositorio, de la organización o de la empresa. La creación de políticas en modo Evaluate se limita a Enterprise Cloud.
Ese límite merece atención: que el anuncio mencione evaluación no significa que cualquier cuenta pueda ensayar una política propia de esa forma. Consulta las opciones de tu plan y distingue esa función del despliegue de la regla predeterminada anunciado por GitHub.
Haz un inventario que puedas revisar de verdad
Propuesta de Texploto: empieza con una lista de los workflows que utilizas. Para cada uno, anota su finalidad, qué evento lo inicia, qué identidad actúa y qué recursos necesita. Separa las tareas de comprobar código, generar un artefacto y desplegar un servicio.
Ejemplo ficticio propuesto por Texploto
Un proyecto recibe contribuciones externas y construye una vista previa de documentación. Otro flujo publica la versión definitiva. La revisión debe decidir quién puede iniciar cada proceso y qué acceso necesita, aunque ambos se guarden en el mismo repositorio.
No copies una política de otro proyecto sin identificar esas diferencias. Una regla demasiado amplia puede permitir más de lo necesario; una demasiado estrecha puede impedir una tarea legítima y provocar que alguien improvise una excepción.
Un actor permitido no garantiza que el código sea fiable
El aviso explica que pull_request_target trabaja en el contexto del repositorio base y puede tener acceso a secretos. Ejecutar desde ahí código no confiable de un fork puede comprometerlos. Conviene revisar ese recorrido antes de permitir el evento como respuesta a un fallo.
Piensa en dos preguntas separadas: quién inicia el proceso y qué acaba ejecutando. Una identidad conocida puede lanzar una operación que consume archivos aportados por otra persona. Dar permiso al iniciador no sustituye la revisión de los datos y del código que entra después.
En tu inventario, documenta cualquier paso que descargue o ejecute contenido externo. La finalidad de esa nota es que la siguiente persona entienda dónde cambia el nivel de confianza, sin tener que reconstruir toda la automatización.
Prepara una revisión pequeña y comprobable
Elige primero un flujo bien entendido. Define una ejecución que debería admitirse y otra que debería quedar fuera; conserva el resultado esperado y la razón. Si tienes evaluación disponible, consulta su resultado antes de activar la política. Si no, prepara un entorno de prueba apropiado antes de afectar una publicación real.
Deja registrada la configuración anterior y quién revisará los fallos. No conviertas un error de permisos en una autorización general para cualquier evento. Para la etapa posterior de distribución, nuestra guía sobre tokens stage-only de npm explica cómo separar la preparación de un paquete de su aprobación.
Fuentes consultadas el 22/09/2026. Guía basada en documentación; no hemos activado estas políticas ni probado un repositorio para este artículo.
