Un agente te abre un pull request en tu proyecto público. El workflow que etiqueta, revisa o publica a partir de ese PR usa pull_request_target y hoy parece funcionar. GitHub avisó el 2 de noviembre de 2026 que, desde el 2 de diciembre, bloqueará ese evento por defecto en repositorios públicos salvo que una política de Actions aplicable lo permita expresamente. Habrá ensayos con bloqueo el 9 y el 16 de noviembre. Para quien construye con agentes, el problema práctico es doble: evitar que falle la automatización y no abrir una vía para ejecutar código ajeno con secretos.

Qué cambia exactamente

La regla afecta a repositorios públicos en GitHub Free, Team y Enterprise Cloud. No afecta a repositorios privados o internos, ni a GitHub Enterprise Server según el anuncio. Antes de la fecha permanente, la regla corre en modo evaluate: GitHub muestra qué ejecuciones habría bloqueado. En los ensayos del 9 de noviembre, 16:00–18:00 UTC, y 16 de noviembre, 16:00–18:00 UTC, sí se bloquearán temporalmente los workflows afectados y aparecerá una ejecución fallida con una anotación. Después volverán las advertencias hasta el 2 de diciembre.

pull_request_target ejecuta el workflow en el contexto del repositorio base y puede acceder a permisos o secretos que un PR desde un fork no debería recibir. La guía de seguridad de GitHub explica el patrón peligroso: traer el código del fork y después ejecutarlo, por ejemplo con un build o test, dentro de ese contexto privilegiado. Que el código venga de un agente no lo vuelve confiable; revisa el flujo igual que cualquier contribución externa.

Audita tu repositorio en cinco minutos

En la raíz del proyecto, ejecuta rg -n 'pull_request_target' .github/workflows. Si no tienes rg, usa la búsqueda de archivos de tu editor. El comando encuentra menciones, no demuestra por sí solo que el evento esté activo: revisa cada YAML y los workflows reutilizables. Si no aparece nada y no hay políticas heredadas o automatizaciones externas que dependan de ese evento, este cambio puede no requerir trabajo en ese repositorio.

1. Abre Insights de la política. GitHub documenta los policy insights para ver ejecuciones que el modo evaluate habría bloqueado. Anota el workflow y la tarea que perdería.
2. Pregunta si realmente necesitas privilegios. Si solo haces tests o lint de cambios propuestos, considera cambiar a pull_request y prueba el PR de un fork. Ese evento no debería recibir los secretos del repositorio base en ese escenario.
3. Si sí necesitas el evento, reduce el riesgo antes de permitirlo. Revisa permisos del GITHUB_TOKEN, secretos, checkout y comandos posteriores. Nunca ejecutes código no confiable del fork en el mismo job que posee secretos o un token privilegiado. Una excepción de política puede apuntar a un workflow concreto, pero no arregla un diseño inseguro.
4. Haz una prueba controlada. Revisa Insights, abre un PR de prueba y observa la ejecución durante el ensayo o en modo evaluate. Documenta si elegiste reemplazar el evento, mantener el bloqueo o permitir solo un caso revisado.

No he modificado workflows ni probado una política en la cuenta GitHub de Joseph; esta es una guía basada en el anuncio y la documentación de GitHub. La fecha, los ensayos y el alcance son datos oficiales. La decisión importante hoy es inventariar workflows afectados; la decisión de permitir el evento requiere revisar el código y los permisos concretos de cada repositorio.