A normal PR can change a GitHub Actions workflow that receives secrets, publishes a package, signs an artifact, or deploys. Review the PR, workflow trigger, job permissions, credential source, environment approval, and target as one path. Use Actions and deployment logs to confirm what ran.
GitHub surfaces to check
- Workflow files under `.github/workflows` and reusable workflow references.
- Repository, organization, and environment secrets available to the job.
- Workflow permissions, token scopes, environments, and required reviewers.
- `pull_request` and `pull_request_target` triggers, especially where untrusted code can influence privileged jobs.
- Package publishing, release, artifact signing, deployment, and cloud jobs.
- Third-party actions, pinned SHAs, setup steps, package scripts, self-hosted runners, and generated commands.
Review walkthrough for one workflow
- Open the workflow and check `on:`, `permissions:`, environments, reusable workflows, and runner labels.
- Identify which secrets, package tokens, cloud roles, or signing keys the job can use.
- Check whether AI-assisted work can change the workflow file, package scripts, action versions, or job conditions.
- Confirm whether approval happens before merge, before workflow run, before environment access, or only after the action.
- Record the owner, credential, target, approval reason, validation, and outcome evidence.
Action-control checklist for GitHub Actions
Trigger
Check whether AI-assisted work can influence `pull_request`, `pull_request_target`, scheduled, manual, release, or reusable workflow paths.
Permission
Review `permissions:`, environment rules, required reviewers, branch protection, runner labels, and reusable workflow trust.
Credential
List repository, organization, environment, package, cloud, signing, and deployment secrets reachable from the job.
Outcome
Record whether the job can publish, deploy, sign, migrate, call cloud APIs, or affect production.
Questions for platform and security review
Can the workflow change?
Can AI-assisted work modify workflow files, action versions, job conditions, runner labels, permissions, or environment rules?
What can the job use?
Which `GITHUB_TOKEN` permissions, secrets, cloud credentials, package tokens, signing keys, or deployment credentials are reachable?
What can the job affect?
Can it deploy, publish, sign, migrate, delete, call internal APIs, or affect production?
What proof remains?
Can the team reconstruct requester, PR, workflow, job, credential, approval, validation, target, and outcome?
Example path
A normal-looking AI-assisted PR can alter a job that receives credentials or deploys. Review the workflow change and the credentialed job together.
Source notes
- GitHub Advanced Security with AI coding agents describes using GitHub security features while working with AI coding agents.
- GitHub Copilot cloud agent docs describe a pull-request workflow and a GitHub Actions-powered development environment.
- GitHub responsible-use guidance describes workflow approval, runtime permissions, secrets handling, signed commits, and traceability for Copilot cloud agent.
- Research on agentic workflow injection in GitHub Actions describes how untrusted GitHub event context can influence agentic workflow behavior through tools or workflow logic.
- Clyra's AI Agents in CI/CD guide expands the same review model beyond GitHub Actions.
Map a GitHub Actions path.
Clyra maps selected GitHub workflows into action path, credential reach, approval gap, and evidence packet.
Map one workflow