Anyone with write access to your repository effectively has read access to all secrets configured there. GitHub's security guidance says so directly. They cannot see the values in the settings page, but they can write a workflow that uses them. So the real question is who has write access.
Definition
A GitHub Actions secret is an encrypted value that workflows can use. The settings page never shows the value again after you save it. That sounds like a vault, but the protection ends at the interface. A workflow that runs in the repository receives the value as input, and workflow files are code that people with write access can change.
GitHub's secure use guidance states: "Any user with write access to your repository has read access to all secrets configured in your repository." The practical lesson is to treat write access as secret access.
Who needs what
| Action | Access GitHub requires |
|---|---|
| Create repository secrets, organization repositories | Write access |
| Create repository secrets, personal repositories | Collaborator |
| Create environment secrets, organization repositories | Admin access |
| Create organization secrets | Organization owner, with an access policy per secret |
One more detail: organization level secrets are not accessible by private repositories on GitHub Free.
Why this surprises teams
Teams grant write access freely because it feels like "can push code". But in a repository with Actions, pushing a branch can mean running code with secrets. Branch protection limits what gets merged, not what runs on a branch in the same repository. Workflows triggered by pushes to a branch can use repository secrets unless something withholds them.
Forks are different. GitHub's docs say secrets are not passed to the runner when a workflow is triggered from a forked repository, except GITHUB_TOKEN. And secrets are not available to workflows triggered by Dependabot events; Dependabot has its own secrets store.
How to shrink the group
- List who has write or higher access. Remove people who only need to read or file issues.
- Move production credentials into environments. GitHub says environment secrets are only available to jobs that use the environment, and only after the configured rules, such as required reviewers, pass.
- Add a deployment branch or tag rule to those environments so only chosen refs can use them.
- Use organization secrets with a policy that names the repositories allowed to use them, rather than all repositories.
- Replace stored cloud keys with OIDC, which GitHub notes lets you stop keeping long-lived credentials as secrets.
- Review the list of secrets and delete ones nobody uses.
- Rotate any secret a departing person could have read through a workflow.
What about the secret's name versus its value
Listing secrets shows names and metadata. The command line tool's list command exposes fields such as name, visibility, and updated time, not values, so inventory work does not itself leak anything. Treat the inventory as sensitive anyway; it maps your attack surface.
Quick check
Can a collaborator with write access print a secret in a log?
They can try. GitHub redacts known secret values in logs, but redaction depends on exact matches, so encoded or transformed values can slip through. Do not rely on masking as protection against an insider.
Do environment secrets fix this?
They narrow it. Jobs only reach them after rules pass, so combine them with reviewers and branch rules.
Safeguard policies and gates can flag pull requests that change workflow files, and asset discovery helps map which repositories hold credentials. A free scan is at gold.safeguard.sh/scan.
Sources
- GitHub Docs: Secure use reference
- GitHub Docs: Using secrets in GitHub Actions
- GitHub Docs: Managing environments for deployment
- GitHub CLI manual: gh secret list
Last reviewed: 19 October 2026.
