Put the secret in an environment with required reviewers. A job that references the environment cannot read its secrets until a reviewer approves, so a pull request cannot reach credentials without a human decision. Add a branch rule and prevent self-review to close the common gaps.
What an environment is
On GitHub, an environment is a named target such as staging or production. It can hold its own secrets and variables, and deployment protection rules decide when a job that references it may proceed. Secrets stored in an environment are just available to jobs that reference it. If it requires approval, the job cannot read them until a required reviewer approves.
Why it helps with forks
Fork pull requests already get no repository secrets by default. Environments help in the cases where you do need a secret for an outside change, such as running an integration test against a sandbox after you have read the diff. The approval is a deliberate point where a maintainer says yes.
Steps
- Create an environment, for example integration-sandbox.
- Add required reviewers, up to six people or teams. One approver is enough.
- Turn on prevent self-review so the person who triggered the run cannot approve it.
- Under deployment branches and tags, restrict which refs can deploy to this environment.
- Move the credential from repository secrets to environment secrets.
- Reference the environment from the one job that needs the credential.
- Give that credential the minimum scope, ideally scoped to a sandbox.
Plan limits
GitHub documents that environments and environment secrets are available in public repositories on all current plans. For private or internal repositories you need GitHub Pro, Team or Enterprise. Check the plan page before you design around required reviewers.
What approval does not cover
- It does not make untrusted code safe. If the approved job runs the contributor's code with the secret, the reviewer has approved running that code. Review the diff first.
- It does not isolate self-hosted runners. GitHub notes those are not run in an isolated container even with environments.
- It does not protect a secret that is stored at repository level in addition.
- A reviewer who approves without reading adds little. Give reviewers a short checklist and keep approval requests rare.
A reviewer checklist
| Check | Question |
|---|---|
| Diff | Does it touch workflows, scripts the job runs, or dependency manifests? |
| Scope | Is the credential limited to a sandbox? |
| Source | Is the contributor known, or is this a first time contributor? |
| Alternatives | Could this test run without the secret? |
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the decision point on a pull request, which is where a human approval fits into an automated flow.
Where Safeguard fits
Safeguard policies and guardrails put clear decision points in a pull request flow, and its compliance and evidence automation helps organize review evidence. The free scan is a quick start.
Quick check
Can the pull request author approve their own environment run?
Not if you select prevent self-review in the environment's protection rules.
Do environments replace code review?
No. They add an approval step before secrets are exposed. The diff still needs to be read.
Sources
- Deployments and environments, GitHub Docs
- Managing environments for deployment, GitHub Docs
- Secrets, GitHub Docs
Last reviewed: 19 October 2026.
