It depends on the platform, but often no. In the documentation of one major code host, workflows triggered by its update bot run as if the pull request came from a fork: a read-only token and none of your normal secrets. That protects you, and it explains many red builds on bot pull requests.
Why bot pull requests are treated like forks
An update bot opens pull requests automatically, with content pulled from a public package registry. If a compromised package could change a build step and that build had your deploy keys, the bot would become an attack path. Treating the pull request like an outside contribution limits the damage.
According to the host's troubleshooting guide, runs triggered by the bot from push and pull request events get a read-only token and cannot read the secrets you normally use. A workflow that tries to write to the repository, comment on the pull request, or publish a build will fail on those runs.
What the documentation says you can do
The guide lists three ways to resolve failures:
- Stop the workflow from running for the bot, using a condition on the actor name.
- Use a two-step workflow built on the pull request target event, which does not have the same limits.
- Give the bot's runs access to specific secrets and raise the token permissions.
The third option comes with a rule worth remembering. When the bot triggers a workflow, only secrets stored in the bot's own secret store are available. Your regular secrets are not. So if a build needs a registry credential, you store a separate, read-only copy for the bot.
A safe way to choose
| Situation | Reasonable choice |
|---|---|
| Build only needs to compile and test | Leave defaults, no secrets needed |
| Build pulls from a private registry | Store a read-only credential in the bot's secret store |
| Workflow comments or labels on pull requests | Raise token scope for just those permissions |
| Workflow deploys or publishes | Do not run it on bot pull requests at all |
The last row matters most. A deploy should happen after a human or a gated process merges the change, not on the pull request that a bot opened from a package it has just fetched.
Mistakes to avoid
Do not copy your production secrets into the bot's store to make a build turn green. Use credentials that can only read what the build must download.
Do not switch to a more permissive event type without understanding it. The documentation points to the pull request target event as a workaround because it does not have the same limits. Those limits exist for a reason, so if you use that event, do not also check out and run code from the pull request without thinking through the risk.
Check what happens on re-runs too. The same page notes that a manual re-run of a bot workflow keeps the privileges it had before, even if the person who clicked has different permissions.
Try it yourself
Click through it at your own pace, or open it full screen.
Step through the pull request gate and watch which checks run before a merge is allowed, then ask which of your own checks should need secrets at all.
Quick check
Why does my build fail only on bot pull requests?
Most likely because the run has a read-only token and no access to your normal secrets, so a step that writes or authenticates fails.
Should the bot's builds be able to deploy?
No. Keep deploys behind a merge and your own gates, and give bot runs only read-only credentials.
Safeguard adds policy gates and guardrails on pull requests, scans manifests and lockfiles into an SBOM, and uses reachability analysis to show which flagged dependencies your code actually calls. Fix pull requests are off by default, with every category on Manual. A free scan is available for a public repository.
Sources
Last reviewed: 19 October 2026.
