A stolen DevOps PAT carries the user's authority without the user

A personal access token is convenient precisely because it carries your authority everywhere. When it leaks, it carries that authority to whoever holds it.

How the attack works

A developer’s Azure DevOps PAT leaks. It is a long-lived bearer credential scoped to the developer’s permissions, so the attacker authenticates from an unfamiliar location and clones private repositories in quick succession. The session then reads pipeline definitions, variable groups, and service-connection configuration, hunting for secrets and cloud credentials. Finally the attacker commits a pipeline YAML change that injects a payload to run with the build’s service-connection identity, turning a credential theft into a supply-chain compromise. The Azure DevOps audit log records the PAT authentication and every operation. This maps to T1552, Unsecured Credentials, and T1195, Supply Chain Compromise.

Why it works

The PAT is broadly scoped and long-lived, so it carries full user authority and outlives any single session. It is a separate bearer credential, which is why resetting the developer’s Entra password leaves it working untouched.

How to fix it

The non-obvious point is that revoking the PAT is necessary but not sufficient. Anything the token already read is burned, so you must revoke the PAT to end the session and then rotate every pipeline secret and service-connection credential it could have reached, because those are compromised regardless of the token’s state. Treat any build artifact produced after the pipeline change as suspect. Durably, enforce least-privilege PAT scopes with short expiry across the org, move automation off developer PATs onto scoped service principals or managed identities, and alert on anomalous PAT use.

Practice it

We built this as a GraphLattice Range scenario so developers learn why you revoke the PAT and rotate every secret it could read.