Usually not. A pipeline runs code with repository tokens and sometimes secrets, so an agent authored change can reach them before anyone reads the diff. Holding workflows until a person with write access approves them puts a human between untrusted output and your build environment, at the cost of a short delay.
The documented default
GitHub's risk page for its cloud agent describes this as the default: workflows triggered by agent generated code do not run until a user with write access clicks to approve and run them, after reviewing the code. Administrators can optionally allow automatic runs, which trades safety for speed. The same page states that the user who requested the pull request cannot approve it, and that the agent cannot approve or merge.
GitHub's token documentation adds a related rule: events triggered by the workflow token generally do not start new workflow runs, with exceptions for workflow_dispatch and repository_dispatch, and pull requests the token opens or updates create runs that need approval first. These are guard rails against loops and privilege chaining.
What an unreviewed pipeline run can reach
| Resource | Why it matters |
|---|---|
| Repository token | Can read and sometimes write to the repository |
| Environment secrets | Deploy keys, registry tokens, API keys |
| Self-hosted runners | Network position inside your environment |
| Build cache | Poisoned output can persist |
| Release steps | Automatic publishing on merge or tag |
The token's permissions are limited to the repository containing the workflow and expire when the job finishes, which helps. Set permissions to the minimum each job needs.
How to set it up
- Require approval for workflow runs from agent identities or first time contributors, depending on your host's options.
- Keep deployment secrets in environments that need a named reviewer, not in repository wide secrets.
- Separate a fast, secret-free check, such as lint and unit tests, from jobs that use credentials.
- Use code owner review for workflow files, build scripts, and dependency manifests.
- Make sure a changed workflow file in a pull request does not run with elevated privileges before review.
- Record who approved each run.
The review itself
When you approve, you are approving execution, not just the diff. Read the changes to build scripts, test configuration, and dependency files first, since those execute code. Then check whether the pull request adds packages, and what they are.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a gate decides whether a pull request may proceed, based on what it changes.
Worked example: a pull request that edits a workflow
An illustrative scenario. An agent is asked to speed up a slow test job. In its pull request it changes a workflow file so that the test job also runs a helper script, and it adds that script to the repository.
If workflows run automatically, the new workflow definition may run with the job's token as soon as the pull request opens, and the helper script runs with whatever the job can reach. A malicious line in that script, perhaps inserted because the agent followed an instruction hidden in a dependency file, would run before anyone reviewed the diff.
If workflows are held, the run waits. A reviewer reads the changed files list, notices that a workflow file and an unfamiliar script changed together, opens both, and rejects or asks questions. The cost was a short delay.
The lesson: the files that execute are the ones to read first.
What to hold and what to allow
| Check type | Run automatically? | Why |
|---|---|---|
| Static checks that need no secrets and run in an isolated runner | Often yes | Low exposure |
| Unit tests with no secrets | Maybe, in an ephemeral runner | Execute repository code |
| Integration tests with credentials | No, hold | Credentials are in reach |
| Jobs on self-hosted runners | No, hold | Network position inside your environment |
| Deployment or publish steps | No, hold and require environment reviewers | Highest impact |
Decide per check, and write the rule down.
Setting up the approval path
- Make agent pull requests require an approval to run workflows, where your host supports that option.
- Assign owners who can approve runs, and give them a checklist.
- Use environments with required reviewers for any job that uses deployment credentials.
- Set default workflow token permissions to read only, and raise them per job.
- Prevent workflow files from using secrets in jobs triggered by untrusted changes.
- Use ephemeral runners so nothing persists between runs.
An approver checklist
- Did the pull request change workflow files, scripts they call, or build configuration?
- Does it add or change dependencies, and do the new packages look right?
- Does any step download and run something from a URL?
- Does any step print environment variables or secrets?
- Does the change make sense for the stated task?
Avoiding rubber stamps
Approvals lose value when reviewers click through. Keep the volume manageable by limiting how many agent tasks run at once, by making pull requests small, and by rotating approvers. Count how often approvers reject or request changes. A rate of zero over a long period is a signal to look at review quality.
Token behavior worth knowing
The token documentation notes that events triggered by the workflow token generally do not create new workflow runs, with exceptions, and that pull requests the token opens create runs that need approval first. These behaviors reduce chain reactions, but do not replace your own approval rule.
Where Safeguard fits
Safeguard's policies and gates can evaluate a pull request, for example for risky dependency changes, before it merges. Its autonomous remediation opens fix pull requests and is off by default, with every category on Manual.
Quick check
Does holding workflows slow teams down too much?
A short approval is usually small next to the risk, and a secret-free fast check can still run early.
Can I let routine agent changes run automatically?
You can, for narrow cases with no secrets and limited paths. Decide that by policy, not by default.
Do held workflows delay urgent fixes?
They add a short wait. For genuine urgency, keep a documented path where a named approver can release a run quickly, and record who did it.
Sources
Last reviewed: 19 October 2026.
