Azure Pipelines · YAML pipelines and resources · Checked November 5, 2026

Azure Pipelines: "This pipeline needs permission to access a resource before this run can continue": who can select Permit, and how to authorize a pipeline ahead of time

This is not a failure: the run waits. A YAML pipeline stops here when it uses a protected resource that has not authorized it: a service connection, an agent pool, an environment, a variable group, a secure file or, with Protect access to repositories in YAML pipelines turned on, a repository. Someone who administers that resource selects View and then Permit, and the run goes on (a Stack Overflow question about it has been seen more than 30,000 times).

If the waiting run is a pull request's build validation: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, shows the pull request's branch policies with their state, so the required build that has not passed is next to the pull request in your IDE. Get it on JetBrains Marketplace

What it looks like

• The run's summary page shows This pipeline needs permission to access a resource before this run can continue to <stage name> with a View button, and the stage waits.
• View opens Waiting for review. Select Permit there, and Permit again on the confirmation (Microsoft's steps for a service connection).
• Permit adds the pipeline as an authorized user of that resource, so the same pipeline does not ask again for it.
• If the run is a pull request's build validation, it waits the same way, and the pull request's build policy does not pass until someone permits it.

Why it happens

• For YAML pipelines, service connections, agent pools, environments, repositories, variable groups and secure files are protected resources (Resources in Azure Pipelines). Each has pipeline permissions: open to all pipelines of the project, or restricted to the pipelines on its list.
• A pipeline that someone creates is authorized automatically only for the resources on which that person has at least the User role (Resource authorization). When a colleague creates a new pipeline that deploys to an environment they only read, the first run asks.
• With Protect access to repositories in YAML pipelines turned on (a project or organization setting), Azure Repos YAML pipelines always ask for permission to access repositories the first time they run (Protect access to repositories). The setting does not apply to GitHub repositories.

Who can select Permit

Permit changes the resource's pipeline permissions, so it takes a role that administers that resource, not a role in the pipeline. From Microsoft's security role tables:

• Environment: the Administrator role on that environment, which "can administer permissions". The person who creates an environment gets it, permanently. By default Contributors are only Reader on an environment, and Project Administrators get only the Creator role (create environments), so adding someone to Project Administrators does not by itself let them permit on an existing environment. Give them Administrator on that environment: Pipelines → Environments → the environment → More actions → Security → User permissions.
• Service connection: its Administrator role ("can use the service connection and manage roles for other users and groups"). The person who creates a service connection gets it, and so does the group [project]\Endpoint Administrators.
• Agent pool, variable group, secure file: the people who administer that pool, group or file, with its Administrator role (Project settings → Agent pools, or Pipelines → Library → Security).

If you cannot permit and nobody else is around, send the person who created the resource the link to the waiting run.

Authorizing a pipeline ahead of time

• On the resource's Security page, Pipeline permissions: Restrict access keeps a list, and + adds a pipeline to it. Open access lets every pipeline in the project use the resource; on an environment, only Project Administrators can turn Open access on.
• Service connections and agent pools are in Project settings → Pipelines, variable groups and secure files in Pipelines → Library, environments in Pipelines → Environments.
• A service connection also has Grant access permission to all pipelines. Microsoft does not recommend it, and asks you to authorize each pipeline instead.
• With the REST API, Pipeline Permissions - Update does the same as Permit for a list of pipelines. In Microsoft's example the resource is an agent pool's queue (queue and its ID); the pipeline ID is the definitionId in the pipeline's address.

PATCH https://dev.azure.com/YOUR-ORG/YOUR-PROJECT/_apis/pipelines/pipelinepermissions/queue/QUEUE-ID?api-version=7.1-preview.1
{ "pipelines": [ { "id": 16, "authorized": true } ] }

Telling it apart

• The run fails instead of waiting, with Could not find a <resource> with name <name>. The <resource> does not exist or has not been authorized for use: Microsoft says to make sure you have at least the User role on the resource, then authorize it from the failed run and start a new one.
• Environment <name> could not be found. The environment does not exist or has not been authorized for use.: the environment does not exist, and the pipeline could not create it because Azure Pipelines did not know who was creating it (a YAML file changed outside the web editor, or a run started by a trigger). Create the environment first (Microsoft's FAQ).
• A required build has not run or has not passed, and Complete is refused: "This pull request requires an explicit override to bypass policies that aren't currently passing".

Azure DevOps pull requests in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote and lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request with their state, so a required build that has not passed is next to its pull request, and when a required policy has not passed, its Complete dialog offers auto-complete first. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.

Get it on JetBrains Marketplace

Azure DevOps and Azure Pipelines are trademarks of Microsoft Corporation; GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft, GitHub, Inc. or JetBrains.

More: no Microsoft-hosted parallel job yet · a required policy has not passed · Node.js 6, 10 and 16 leave the agent on November 24, 2026 · 日本語