Job authorization scope decides which identity an Azure DevOps pipeline uses at run time. A collection level identity can reach resources across projects. A project level identity can reach only its own project. Microsoft recommends the project level identity, enabled by limiting job authorization scope to the current project.
Collection or project identity
Pipelines use an identity to reach repositories, service connections, and variable groups. Microsoft describes two types.
| Identity | Reach | Trade off |
|---|---|---|
| Collection level | Resources across projects in the organization | Easy to set up, larger blast radius |
| Project level | Only the pipeline's own project | Needs explicit grants for cross project access |
If a malicious change runs in a pipeline with a collection identity, it can read code in unrelated projects. With a project identity, the same change is boxed in.
The settings to turn on
In Project Settings, under Pipelines then Settings, or in Organization Settings, Microsoft names three toggles.
- Limit job authorization scope to current project for non-release pipelines.
- Limit job authorization scope to current project for release pipelines, if you have release pipelines.
- Protect access to repositories in YAML pipelines, if you have Azure Repos YAML pipelines.
If the setting is on at organization level, a project cannot override it. If it is off there, projects can turn it on themselves. The documentation says the project level limit overrides the Build job authorization scope option on Classic build pipelines, so a Classic pipeline set to Project collection still runs with a project identity once it is on.
What breaks and how to fix it
Expect failures the first time, usually the error TF401019: The Git repository with name or identifier ... does not exist or you do not have permissions. That means the pipeline relied on cross project access. To fix it:
- Find which repositories in other projects the pipeline checks out.
- Grant the pipeline's project access to the other project.
- Grant the pipeline's build identity Read access on each repository it checks out, and on any repository used as a submodule.
- If a repository uses another as a submodule, explicitly check out the submodule repository first, then the one that uses it.
- For command line
git clonesteps, switch to thecheckoutkeyword so the permission request can work.
Protect access to repositories in YAML pipelines
This setting makes a YAML pipeline ask for permission to use any repository, in any project, the first time it runs. A person then selects Permit. It does not apply to GitHub repositories. Microsoft also notes that turning it on stops Classic build pipelines from reaching any repository other than the one in their settings, so if you have both kinds of pipelines you may need separate projects.
Further hardening from the same page
- Disable creation of classic build and release pipelines. Microsoft says these are disabled by default for new organizations.
- Add a manual approval each time a pipeline requests a repository.
- Use a protected branch check so pipelines do not run on unauthorized branches.
- Limit the pipeline access token to repositories listed in the pipeline's resources section.
Quick check
Does the project setting turn off all cross project checkouts?
It blocks them until you grant access. Grant the project access to the other project and the build identity Read on the repository.
Does the YAML repository protection cover GitHub repositories?
No. Microsoft states the Protect access to repositories in YAML pipelines setting does not apply to GitHub repositories.
Safeguard asset discovery and dependency scanning can map which repositories feed which builds, and a free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
