Usually no. A pull request runs code that has not been reviewed yet, so any cloud role it can assume should be read only and narrow. Keep write access for jobs that run after merge, behind a protected environment with its own role.
Why pull request code is different
A workflow triggered by a pull request executes the contents of that pull request. If the author is a teammate, that is a normal part of review. If the author is a contributor you do not know, or a teammate whose account was taken over, the same workflow becomes a way to run attacker code with whatever the job can reach.
GitHub's secure use guidance is blunt about the risky trigger. It says to avoid pull_request_target if it is not necessary, describes those workflows as privileged because they may have write access and access to secrets, and says they must not explicitly check out untrusted code. That is the combination that hurts: privileged context plus code from a stranger.
What the OIDC subject tells you
With OIDC, your cloud account can see how a job was triggered before it issues credentials. GitHub documents that the subject for a pull request event, when no environment is referenced, takes the form repo:ORG/REPO:pull_request. A deploy job that references an environment carries the environment name instead.
That gives you a clean way to split roles:
| Job | Typical subject | Role should be |
|---|---|---|
| Test and plan on pull request | pull_request form | Read only, or no cloud role at all |
| Deploy after merge | environment form | Write, scoped to one stack |
AWS's own guide for GitHub warns that a trust pattern ending in a repository wildcard lets any branch, pull request merge branch or environment assume the role. If your write role uses that pattern, a pull request can reach it.
A safer setup, step by step
- List what each workflow really needs from the cloud. Many test jobs need nothing.
- Create a separate read only role for checks that must look at cloud state, such as a plan or a diff.
- Trust that role for the pull request subject, and give it no write actions.
- Create a deploy role trusted only for a named environment.
- Put protection rules on that environment. GitHub notes that a job cannot access environment secrets until a required reviewer approves.
- Set the default workflow token to read access and raise it per job, as GitHub's guidance suggests.
- Pin third party actions to a full commit SHA and confirm the SHA belongs to the action's repository, not a fork.
What about forks?
The documentation pages we read do not spell out how every platform treats fork pull requests for token requests, so check the current behavior for your platform and test it with a harmless workflow. Do not assume a fork is blocked. Design the trust policy so that even if a fork job did obtain a token, the role it could assume is harmless.
Try it yourself
Pull request gates are the same idea applied to code: let the cheap, safe checks run on every change, and hold the sensitive step until a reviewed condition is met. Click through the gate demo and watch where the pipeline stops a risky change.
Click through it at your own pace, or open it full screen.
Quick check
Can a pull request job use OIDC safely?
Yes, if the role it can assume is read only and trusted only for the pull request subject. Keep write roles on environment subjects with protection rules.
Is pull_request_target always unsafe?
No, but GitHub advises avoiding it unless needed, and never checking out untrusted code inside it.
Safeguard does not manage your cloud accounts. It does apply policies and gates to pull requests, scan dependencies, and automate compliance evidence. A free scan is at gold.safeguard.sh/scan.
Sources
- GitHub Docs: Secure use reference
- GitHub Docs: OpenID Connect reference
- GitHub Docs: OIDC in Amazon Web Services
Last reviewed: 19 October 2026.
