Who can read your repository secrets in GitHub Actions?

Anyone with write access to a repository can read the secrets configured there, because they can write a workflow that uses them. GitHub states this directly. So write access is effectively secret access, and limiting who has it is as important as limiting the secrets themselves.

What GitHub says

GitHub's secure use reference says any user with write access to your repository has read access to all secrets configured in your repository. It follows that credentials used in workflows should have the least privileges required.

This is not a bug. A workflow needs secrets to do its job, and a person who can edit the workflow decides what the job runs. If a person can change the workflow, they can make the job reveal or send the secret.

Why this matters for supply chain attacks

A taken-over contributor account with write access is therefore a secret-theft account. The same applies to a bot token with write permission, and to any compromised third party action running in a job.

Ways to narrow it

1. Reduce write access. Give most people read access and let changes arrive through pull requests.
2. Protect branches and require review, so a workflow change cannot go straight into the default branch. GitHub's protected branch settings include required pull request reviews and required status checks.
3. Use code owners on the workflows directory and release files. GitHub's code owner feature can require approval from designated owners before a pull request merges.
4. Use environments with required reviewers for production secrets, so the secret is released only to approved jobs.
5. Prefer short-lived credentials from an identity exchange over stored secrets. GitHub describes OpenID Connect as letting workflows request short-lived tokens from the cloud provider, which removes the need to duplicate cloud credentials as long-lived secrets.
6. Scope secrets to the narrowest level. Use environment or repository secrets instead of organization wide ones where possible.

Audit steps

1. List everyone with write or higher access to repositories that hold release secrets.
2. For each, ask whether they still need it.
3. List secrets and their last use. Delete unused ones.
4. Check which workflows can run on events triggered by outsiders.
5. Rotate any secret that may have been visible to someone who has left.

A note on logs

Do not print secrets. GitHub notes that automatic redaction is not guaranteed since values can be transformed, so treat the log as readable by anyone who can see the run.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a gate holds a change until it passes checks, which is the idea behind protecting workflow files.

Where Safeguard fits

Safeguard's policies and gates, and its compliance and evidence automation, help you show who can approve what. Secret storage and rotation stay with your CI platform.

Quick check

Sources

• GitHub Docs: Secure use reference
• GitHub Docs: About protected branches
• GitHub Docs: About code owners
• GitHub Docs: OpenID Connect

Last reviewed: 19 October 2026.