Not Actions secrets. GitHub treats workflows triggered by Dependabot pull requests as though they come from a forked repository, so they receive a read-only GITHUB_TOKEN and the secrets available are Dependabot secrets. If a workflow needs a credential, store it as a Dependabot secret with the minimum scope.
Why bots are treated like forks
A dependency update bot opens pull requests with content derived from the outside world: package versions, release notes, changelogs. If that content could trigger a privileged workflow with full secrets, a poisoned upstream package could reach your credentials. GitHub's events documentation states plainly that Dependabot pull request workflows are subject to the same restrictions as forks.
What breaks
Teams usually notice when a workflow that comments, labels, auto merges or pushes begins failing on bot pull requests. A read-only token cannot write. A missing secret leaves a step with an empty value.
GitHub's troubleshooting page offers three ways to resolve write failures:
- Stop the workflow from triggering on Dependabot, for example with a condition on the actor name.
- Use a two step process involving pull_request_target, which does not have these limits.
- Increase the token permissions with a permissions block, with care.
Each option has a trade off, so choose the one with the least exposure.
A decision table
| Need | Suggested approach |
|---|---|
| Run tests on update pull requests | Keep pull_request, no secrets needed |
| Pull private packages during install | Dependabot secret, read-only registry credential |
| Auto approve or merge patch updates | Separate privileged workflow that checks the actor and update type, never runs the PR code |
| Post results as comments | Reporter workflow using workflow_run, reading data alone |
Dependabot secrets
GitHub documents that secrets used by a workflow triggered by Dependabot events must be stored as Dependabot secrets. They appear in the secrets context with the same syntax as Actions secrets. If one workflow serves both Dependabot and humans, GitHub suggests storing the token in both places under identical names.
Give a Dependabot secret the least access: a read-only package registry credential, never a deploy key.
Risky shortcuts
- Switching a whole workflow to pull_request_target and checking out the head, so everything works again. That undoes the protection.
- Granting write permissions at the top of the workflow for one job's benefit.
- Auto merging every bot pull request because tests passed. A green test is not an assessment of a new dependency version.
Merge policy still matters
A bot pull request still changes your dependency tree. Apply the same dependency checks as for outside contributors, and consider grouping updates to reduce noise. See how many open dependency update pull requests is healthy.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a fix is proposed as a reviewable change rather than applied silently.
Where Safeguard fits
Safeguard can open fix pull requests through autonomous remediation, which is off by default with every category set to Manual. The free scan shows what fixes exist.
Quick check
Can a Dependabot workflow read my Actions secrets?
No. When Dependabot triggers a workflow, Dependabot secrets are available.
Is the token writable for Dependabot pull requests?
By default it is read-only, like fork pull requests.
Sources
- Events that trigger workflows, GitHub Docs
- Troubleshooting Dependabot on GitHub Actions, GitHub Docs
Last reviewed: 19 October 2026.
