Design and implement permissions and security groups in Azure DevOps

Groups and targeted grants

Azure DevOps ships built-in groups such as Readers, Contributors, Project Administrators, Build Administrators, and Project Collection Administrators. Prefer built-in or custom security groups for roles, teams, and access cohorts, setting a permission once at the highest supported scope. Targeted direct-user grants remain supported when a specific exception is genuinely required.

Allow, Deny, and inheritance

Permissions exist at organization/collection, project, and object scopes. Group membership can combine grants, and some object namespaces inherit from a supported parent; there is no universal organization → project → object chain for every permission.

For most groups and almost all permissions, Deny overrides Allow at the same evaluation point. Administrator, permission, and object-specific exceptions exist, so apply the rule in its documented context.

Not set supplies no explicit Allow. Another group or a supported object's parent can determine effective access; otherwise the task is implicitly denied. It is not the same as an explicit Deny, which normally overrides a same-context Allow.

Scope the sensitive things separately

Azure Pipelines protected resources include repositories, environments, service connections, agent pools, secure files, and secret variables in variable groups. They can have user permissions, pipeline permissions, and checks evaluated before consumption. Repository permissions alone do not authorize every protected resource.

Other Azure DevOps objects can also be permissioned without being pipeline protected resources. For example, saved queries and query folders have object permissions controlling creation, editing, deletion, and management.

Primary sources

Permissions and security groups in Azure DevOps

Design and implement permissions and security groups in Azure DevOps

Groups and targeted grants

Allow, Deny, and inheritance

Scope the sensitive things separately