Originally published at mergerequests.dev.
The credential your review bot authenticates with is the part of the setup that breaks first. Commenting on a merge request is the same job on GitLab, Azure DevOps and Bitbucket, but it is done by four different kinds of token, and two of those token types are being retired during 2026. Teams usually notice when the comments stop appearing while the pipeline stays green.
The dates set the scope for this post. Global personal access tokens in Azure DevOps Services stop working on 1 December 2026, and Microsoft states that Azure DevOps Server is not affected. On Bitbucket Cloud, app passwords could no longer be created from 9 September 2025 and all remaining ones are disabled on 9 June 2026. GitLab splits project and group access tokens by offering, which decides whether the credential a bot needs exists at all on your instance.
What the reviewer credential decides
Four properties of a token shape how a review bot behaves, and none of them depend on the model behind it.
The identity comes first. An OAuth app posts as a dedicated bot account, so the merge request shows something clearly not human. A personal token posts as whoever owns it, which puts a person's name on machine comments and removes the difference between a human review and a bot review from the audit trail. On a codebase with any compliance requirement, that usually settles the choice.
Reach comes second. Scopes decide which repositories the token can read, and on Azure DevOps a personal access token cannot grant more permission than its owner has, so a bot running on a senior engineer's PAT carries that engineer's access to every project the token was scoped for.
Write ability comes third, and this is where editions diverge. Approving, commenting, applying a suggestion and merging are separate permissions, and not every token type on every edition can do all of them.
Lifetime comes last. GitLab invalidates a rotated token immediately, so rotation is a deploy rather than an edit. Azure DevOps deactivates PATs in Entra-backed organizations after 90 days without sign-in. Bitbucket Cloud tokens cannot be edited after creation, so a rotation means issuing a replacement and updating the integration.
GitLab: access tokens are split by offering, and Self-Managed is the generous side
This is the single most useful fact for a team on GitLab Self-Managed, and it runs the other way from what people assume about self-managed software. Per the project access token documentation, project access tokens require a Premium or Ultimate subscription on GitLab.com, where a trial is limited to one token. On GitLab Self-Managed and GitLab Dedicated they are available with any license, and the group access token documentation states the same for group tokens. A team on a free self-managed instance can hand a reviewer a project-scoped token with a defined role and scope, while a team on GitLab.com without a paid subscription cannot.
Personal access tokens sit at Free, Premium and Ultimate on every offering, and the personal access token documentation gives the lifetime rules: 365 days by default, extendable to 400 days from GitLab 17.6 through a feature flag named buffered_token_expiration_limit, with the instance administrator able to change the maximum. That default matters more than it looks, because a bot whose token was issued a year ago stops working on a date nobody wrote down.
The cleaner identity is a service account. Service accounts do not use a seat, are always marked as external users, cannot sign in through the UI, and authenticate with a personal access token. Premium and Ultimate allow an unlimited number, while Free allows 100 per top-level group on GitLab.com and 100 for the entire instance on Self-Managed. A reviewer running as a service account survives staff changes; a reviewer running as a maintainer's PAT does not. The self-managed GitLab setup that follows your own rules covers the configuration side of that, and the credential is the prerequisite for all of it.
Azure DevOps: PATs narrow to one organization, Server is untouched
Microsoft's personal access token page now opens with the retirement notice rather than the instructions: all existing global PATs stop working on 1 December 2026, and the guidance is to migrate to organization-scoped PATs or Microsoft Entra authentication. The same page tells you to avoid PATs where a better option exists and to prefer Entra tokens, managed identities or service principals for applications and automation, falling back to an organization-scoped PAT with the minimum scopes and shortest practical lifetime when a tool does not support Entra.
For a reviewer bot that distinction is concrete. An organization-scoped PAT can only reach one organization, which is the intended outcome of the change, and a service principal or managed identity removes the human owner entirely. The global token was convenient because it reached every organization the user could see, and that is exactly the property being removed.
PAT usage itself has not changed. Azure DevOps accepts one through an HTTP Basic header, base64-encoding the string :{PAT} with the username left empty, and the token expires on the date set at creation, with a notification sent before it does. On an Entra-backed organization, signing in with a new PAT within 90 days is required or the token becomes inactive, which is a policy interaction worth knowing before a long-lived CI credential quietly goes dormant.
Azure DevOps Server is a separate product line and the retirement notice does not apply to it. Server PATs are scoped to a collection rather than an organization, and Microsoft states that no changes are being made to global PATs there. A team on Server 2022 or 2020 that reads the announcement and starts a migration project is solving a problem it does not have. The edition differences between Azure DevOps Services and Server for code review tooling are wider than the credential, and the token change is one of the few places where Server comes out ahead.
Bitbucket Cloud: app passwords are gone, access tokens are per-resource
Atlassian replaced app passwords with API tokens, and the API token page describes the shape: user-based, scoped at creation, optionally scoped to a single workspace, intended for a single purpose, and impossible to view or edit afterwards. Two limitations matter to a review bot. API tokens cannot be used to log in to bitbucket.org, and they cannot manage workspace actions.
The other credential family on Cloud is access tokens, which are tied to a repository, project or workspace rather than a user. That fits a bot better because there is no human owner to lose access, with two catches. Workspace and project access tokens require the Premium plan, and each workspace, project and repository has a hard limit of 25 tokens that cannot be increased. A repository access token is available without Premium, which makes it the practical choice for a per-repository reviewer.
Bitbucket Data Center: the cleanest bot identity, with two catches
Data Center keeps its own HTTP access tokens, and it has a credential advantage Cloud does not. Project and repository tokens require a Data Center license, and once you have one you can issue a token that belongs to a project rather than to a person, which is the cleanest bot identity on any of the three forges. Two documented limits follow from that. Project and repository tokens work with Bearer authentication only and must not be paired with a username in Basic authentication, which breaks the copy-paste example people reuse from Server PATs. And a token cannot merge a pull request, because a merge creates a commit and only users with a valid email address can do that. The token can perform pull request actions at repository write permission; the merge itself needs a user identity.
Suggestion handling differs too, and it decides how much of a review a bot can finish on its own. GitLab merge request suggestion blocks are applied through the suggestions API and are available on Free tier. Bitbucket Data Center exposes an apply-suggestion endpoint, Bitbucket Cloud does not, and Azure Repos has no apply operation at all, so a bot there posts the replacement as comment text and a human applies it. On Bitbucket, where the native AI review actually runs is a separate question from what the token is allowed to do.
Credentials per forge and edition
| Forge and edition | Practical bot credential | What limits it |
|---|---|---|
| GitLab.com | Service account with a personal access token | Project and group access tokens need Premium or Ultimate |
| GitLab Self-Managed | Project or group access token, or a service account | 100 service accounts for the instance on Free |
| Azure DevOps Services | Entra service principal or managed identity; organization-scoped PAT as fallback | Global PATs stop working 1 December 2026; PATs go inactive after 90 days without sign-in in Entra-backed orgs |
| Azure DevOps Server | Collection-scoped PAT | Not affected by the global PAT retirement |
| Bitbucket Cloud | Repository access token | Workspace and project tokens need Premium; 25-token cap per resource |
| Bitbucket Data Center | Project or repository HTTP access token | Requires a Data Center license; Bearer only; cannot merge a pull request |
What to check before the dates land
The two retirements have different shapes. The Azure DevOps one is a hard stop on 1 December 2026 for global PATs, and the migration target already exists, so the work is finding every integration that still uses a global token. The Bitbucket one is already done: app passwords are disabled, and anything still holding one is broken now rather than later.
On GitLab, the useful check is whether the bot is a service account or a person. A token owned by an engineer who leaves is a review process that stops without an error, and the offering you are on decides which token types you can issue in the first place.
Top comments (0)