An untrusted pull request is code submitted by an external or not yet vetted contributor that should not be allowed to execute with full pipeline privileges. Treating it as untrusted helps prevent malicious build steps from accessing secrets, writing code, or reaching sensitive infrastructure.
Expanded Definition
An untrusted pull request is a repository contribution that has not yet earned execution trust inside the software delivery pipeline. It may come from an external fork, a new collaborator, or a contributor whose code has not been reviewed against the project’s security boundaries. The key distinction is not whether the code is useful, but whether it is permitted to interact with build runners, secrets, deployment credentials, or other privileged automation.
In secure engineering practice, this concept is narrower than general code review. A pull request can be syntactically valid and still remain untrusted until the organisation verifies the author, inspects the changes, and limits what the pipeline can expose. That usually means separating validation from privileged steps, restricting secret access, and preventing unreviewed code from influencing release artefacts or infrastructure. The concept aligns closely with the governance intent reflected in NIST Cybersecurity Framework 2.0, even though implementation details vary by platform and workflow design.
The most common misapplication is treating a pull request as trusted as soon as automated tests pass, which occurs when teams confuse functional validation with security vetting.
Examples and Use Cases
Implementing untrusted-pull-request handling rigorously often introduces workflow friction, requiring teams to weigh delivery speed against exposure of secrets and build infrastructure.
- A maintainer receives a forked contribution and runs only linting and unit tests until a human review confirms the change is safe to merge.
- A CI system builds code from an external contributor in a sandboxed job, while secrets and deployment tokens remain unavailable to that job.
- A project allows untrusted pull requests to compile artefacts, but blocks any step that can publish packages, access cloud APIs, or modify release assets.
- A security team requires signed approvals before a pull request can trigger privileged pipeline stages that interact with internal registries or production infrastructure.
- A repository with automation hooks treats comments, labels, and workflow files in unreviewed branches as sensitive inputs because they can alter pipeline behaviour.
For teams building policy around these patterns, the NIST Cybersecurity Framework 2.0 is useful as a governance baseline for access control, change management, and resilience objectives, even though it does not prescribe one universal pull-request model. The operational question is always whether the contributor and the code are allowed to influence anything beyond basic validation.
Why It Matters for Security Teams
Security teams care about untrusted pull requests because modern build pipelines are executable environments, not passive review tools. If an attacker can smuggle malicious code into a workflow that has access to secrets, signing keys, or internal services, the repository becomes a supply-chain entry point. The risk is especially sharp in projects that use fork-based contributions, reusable workflows, or auto-generated release processes.
This term also intersects with identity governance in a practical way. The decision to trust a pull request depends on the contributor’s identity, the repository’s access model, and the privileges assigned to automation. That makes least privilege, approval gates, and secret segmentation central controls rather than optional hardening. In NHI-heavy environments, the same discipline applies to non-human identities such as CI runners, bots, and deployment agents that act on behalf of the organisation.
Organisations typically encounter the consequences only after a malicious contribution attempts to read secrets or alter a release path, at which point untrusted pull request handling becomes operationally unavoidable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access controls and least privilege govern whether untrusted code can reach sensitive pipeline actions. |
Restrict pipeline privileges so untrusted PR jobs cannot access secrets or production-capable resources.
Related resources from NHI Mgmt Group
- What breaks when untrusted pull request content is executed in a workflow?
- What breaks when pull_request_target is used to run untrusted code in GitHub Actions?
- What breaks when pull_request_target workflows process untrusted input?
- What breaks when untrusted issue or pull request content is inserted directly into an AI prompt?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
