How do you configure Azure DevOps permissions at organization, project, repo, and pipeline levels using least privilege?

Think of Azure DevOps permissions like a corporate building's access control system with multiple layers. The building badge (organization) grants entry to the lobby and common areas. The floor badge (project) allows access to your department's floor. The room key (resource-level) opens specific offices and labs. Each level inherits from above but can restrict further: having building access does not automatically grant room access. A well-designed system gives the mail carrier lobby access only, the accountant access to the finance floor and their specific office, and the CEO access everywhere. Azure DevOps implements this same graduated model with organization, project, and resource-level permissions that can be explicitly allowed, denied, or inherited.

At the organization level, built-in groups define the broadest access boundaries. Project Collection Administrators have unrestricted access to everything: all projects, all settings, all resources. Project Collection Build Administrators manage build infrastructure across all projects. Project Collection Valid Users simply have the right to exist in the organization and see project listings. The critical least-privilege principle here is minimizing Project Collection Administrators: only infrastructure and security team leads should hold this role. Create custom organization-level groups for cross-project needs rather than elevating individuals to collection admin. For example, create an 'Audit Readers' group with read-only access across projects for compliance teams.

Project-level permissions scope access within a single project. Each project has built-in groups: Project Administrators (full project control), Contributors (standard development access), Readers (view-only), and Build Administrators (pipeline management). The least-privilege approach is to default new team members to Contributors and grant additional permissions only when specific needs arise. Create custom project groups for specialized roles: 'Release Managers' who can approve production deployments but cannot modify code, 'Security Reviewers' who can view pipeline secrets but not create them, or 'Stakeholders' who can manage work items but not access source code. Avoid adding individuals directly to permission assignments; always use groups so that role changes require only group membership updates.

Repository-level permissions provide the finest granular control over source code access. Each Git repository inherits project-level permissions but can override them. You can restrict specific branches using branch policies: require pull requests to main (preventing direct pushes), require specific reviewers for changes to security-sensitive paths, and restrict who can bypass policies. For repositories containing secrets or security-critical code, remove the Contributors group's push permission and add only the specific team that owns that codebase. The 'Bypass policies when completing pull requests' permission is particularly dangerous and should be restricted to repository administrators only, as it allows merging without reviews.

Pipeline permissions control who can create, edit, and run pipelines, and critically, which pipelines can access which resources. Pipeline-level permissions determine who can edit pipeline YAML, queue builds, and view results. Resource-level permissions on Service Connections, Variable Groups, Environments, and Agent Pools determine which pipelines are authorized to use them. This second dimension is where most least-privilege violations occur: teams grant all pipelines access to production Service Connections rather than restricting to only the production deployment pipeline. Configure pipeline permissions explicitly: when a new pipeline attempts to use a Service Connection, Azure DevOps requires an administrator to authorize it rather than auto-granting access.

The production gotcha is permission inheritance creating unexpected access. Azure DevOps permissions use an Allow/Deny/Not Set model where explicit Deny overrides Allow at the same level, and permissions inherit from parent to child (organization → project → resource). A common mistake is granting broad access at the project level and then trying to restrict at the repository level without using explicit Deny. Not Set at the resource level inherits the project-level Allow, so you must explicitly Deny to restrict. Another gotcha is the difference between the 'Edit build pipeline' permission (controls who can modify the YAML) and 'Queue builds' permission (controls who can trigger runs). Teams often restrict editing but forget that anyone who can queue a build with different parameters might exploit parameter injection. Always audit permissions using the 'Permissions' diagnostic page which shows effective permissions for a specific user across all inheritance levels.