azuredevops v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-azuredevops-pat

Custody

customer_vault

Injection

header (Authorization)

An Azure DevOps personal access token, held in the client's own secret manager. The stored material must be the complete Authorization header value: the word Basic, one separating space, then the base64 encoding of :<personal-access-token> (an empty username, then a colon, then the PAT). Microsoft documents that PATs authenticate this way, that the expiry date is chosen at creation (no longer than one year, with notification emails before expiry), that regenerating a PAT invalidates the previous value, that revoking a PAT invalidates that issued token, and that organization administrators can restrict PAT creation — an issuance control, not a substitute for revoking already-issued tokens. Microsoft recommends Microsoft Entra tokens where available; this pack registers the documented PAT scheme only. Request the least-privilege scopes: the read forms of vso.project, vso.code, vso.build and vso.work cover the four read capabilities; build.queue additionally needs vso.build_execute — grant it only where the R3 capability is enabled, and nothing broader. Renewal ownership sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle itself, and it must never substitute a different credential without an approved pack change. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• azuredevops-organization (api, internal): https://dev.azure.com/ORGANIZATION/_apis
• azuredevops-project (api, internal): https://dev.azure.com/ORGANIZATION/PROJECT/_apis

The registered host is dev.azure.com (Azure DevOps Services). Self-hosted Azure DevOps Server uses an installer-specific host and a collection path segment: substituting either into the endpoints, the resource locators and the egress allowlist is a pack change that requires re-review before enablement. ORGANIZATION and PROJECT in the endpoint paths are placeholders the deployment substitutes with concrete values at registration time, before enabling: the pack is installed with the concrete paths it will actually call, not rebound per request. The api-version=7.1 query parameter is required by the service and is part of every registered endpoint. This pack registers only endpoints the public Azure DevOps REST API 7.1 documentation describes: listing an organization's projects, listing a project's Git repositories, listing a project's pipeline definitions, reading work items by id in batches, and queuing a build. Documented exclusions: work item create and update, WIQL queries (caller-authored query text), pipeline run create and update beyond queuing a build, release endpoints, pull request APIs, artifact publishing, repository writes, project create and delete, and every endpoint outside the registered list — a documented exclusion, not an approximated capability; each addition is a pack change and requires its own review. Tiering rationale: reads sit at the R0 floor. build.queue is registered as deploy at the R3 floor because Microsoft documents that the request body chooses the definition, source branch, parameters and template parameters, so the queued build runs whatever the definition and the caller's parameters say — including deployment stages where the definition has them — and deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). AAES has not been certified by Microsoft; reviewable default, not a vendor guarantee.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://learn.microsoft.com/en-us/rest/api/azure/devops/core/projects/list?view=azure-devops-rest-7.1 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/rest/api/azure/devops/git/repositories/list?view=azure-devops-rest-7.1 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/rest/api/azure/devops/pipelines/pipelines/list?view=azure-devops-rest-7.1 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/list?view=azure-devops-rest-7.1 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/queue?view=azure-devops-rest-7.1 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.