To build fork pull requests safely in Azure DevOps, keep secrets and normal permissions away from fork builds, require a team member comment before a build starts, and use Microsoft-hosted agents so nothing is left behind. Microsoft's setting called "Securely build pull requests from forked repositories" bundles most of this.
Why forks are risky
A pull request from a fork contains code written by someone you may not know. If your pipeline builds it with the same secrets and permissions as a normal build, the author can try to print the secrets or call your service connections from inside the build. Microsoft says forked repositories increase the risk of malicious code execution or release of sensitive information, and that forks from outside your organization are the biggest concern. This guidance applies to forked GitHub repositories used with Azure Pipelines.
The settings, from strictest to most flexible
Under Project Settings or Organization Settings, then Pipelines, Settings, Triggers, Microsoft lists these options.
| Option | Effect |
|---|---|
| Disable building pull requests from forked repositories | No fork builds at all. Enabled by default |
| Limit building pull requests from forked GitHub repositories | Restricts fork builds. Enabled by default |
| Securely build pull requests from forked repositories | Builds, but without secrets or normal permissions, and only after a team member comment |
| Customize rules for building pull requests from forked repositories | Choose each behavior yourself |
At pipeline level you can also deselect "Build pull requests from forks of this repository", or keep "Make secrets available to builds of forks" and "Make fork builds have the same permissions as regular builds" off, and select "Require a team member's comment before building a pull request".
A safe setup in five steps
- Start from the default, which blocks or limits fork builds.
- If you need fork builds, choose the secure option rather than customizing.
- Make sure the pipeline that runs for forks has no service connection or variable group that grants production access.
- Have a maintainer read the diff before commenting to approve the build. Check changes to pipeline files and build scripts first, since those run code.
- Use Microsoft-hosted agents. Microsoft says resources are deleted from the agent right after the build. If you use self-hosted agents, clean and update them regularly or use separate agents for different forks or branches.
What the team member comment really is
It is a manual gate. The comment is a person saying "I read this and it can run." If a reviewer comments without reading, the gate is only decoration. Teach reviewers that the build executes the contributor's code, including test files and package install scripts.
Related controls
Use the protected branch check and approvals on environments so even a mistakenly approved build cannot deploy. See approvals and checks for how those run. Also review dependency changes in the pull request, because a new package can run install scripts during the build.
Try it yourself
Click through the demo, which shows a pull request being gated, and note which findings come from a dependency change rather than the code itself.
Click through it at your own pace, or open it full screen.
Quick check
Are fork builds on by default?
No. Microsoft says the options to limit and to disable building pull requests from forked repositories are enabled by default.
Why prefer Microsoft-hosted agents for fork builds?
Resources are deleted from the agent immediately after the build, so a malicious build cannot leave code for a later job.
Safeguard dependency scanning and policy gates can review new packages in a pull request before it merges. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
