A leaked personal access token shouldn't expose every project its owner can reach. Fine-grained PATs scope each token’s permissions to the job.

Personal access tokens (PATs) authenticate most of the automation that runs in GitLab. When a token is issued with a broad scope like api or read_api, it extends permissions across many projects and groups. Fine-grained permissions for PATs, now in beta, let you scope a token to exactly the privileges the job requires — read access to one project's code, say, instead of read access across every project the user can reach.The case for narrowing PAT privilegesA maintainer on 20 projects might carry a single token that can read source, modify pipelines, pull from the container registry, and decrypt CI/CD variables across all those projects. The token is scoped to the user, not a specific task, so if it leaks, it exposes every project the user can touch.Fine-grained PATs let teams ensure that scope follows the task: A read-only token issued for one project is read-only on that project alone. When exposed, investigation and remediation start and end there. Fine-grained PATs join safeguards like lifetime limits and automatic revocation, which limit how long an attacker can misuse a stolen token.What’s newYou can define a fine-grained PAT along two dimensions:Where it can reach: personal projects only, all projects and groups you’re a member of, or only the projects and groups you select.What it can do there: per‑resource permissions across the things developers automate against (Issues, Merge Requests, Pipelines, Repositories, Container Registry, and more), with Create, Read, Update, and Delete assigned independently for each resource.Instead of one PAT that can do everything you can do, you issue one PAT per job, carrying exactly that job's permission set. A pipeline that pushes container images doesn't get an api-scoped token; it gets a token scoped to the Container Registry on a single project, with Create and Read and nothing else. If that token leaks, the blast radius is one registry on one project, not your entire footprint.Define a fine-grained PAT's scope by selecting which groups or projects it can reach, then assigning per-resource permissions.The tokens table has been updated to make this auditable at a glance. Every token you’ve created (coarse or fine-grained) shows the exact scopes and per-resource permissions, so over-privileged tokens are easier to spot during reviews.Today’s coverage and future roadmapWe advise against using fine-grained PATs in production workloads until general availability. Fine-grained PATs currently cover about 75% of REST API endpoints. In the months ahead, we're adding support for the remaining REST endpoints and expanding GraphQL coverage.Existing PATs continue working as before. During the beta, you can create traditional and fine-grained PATs side by side as you evaluate the new model.To create a fine-grained personal access token:Navigate to User Settings → Personal Access Tokens.Choose Fine-grained token from the Generate token dropdown.Define the scope.To view administrative controls and the full list of supported resources and permissions, check out access the fine-grained personal access tokens documentation.We’d love to hear how fine-grained permissions for PATs work in your environment, and what else you need to fully adopt least-privilege token patterns. Please share your feedback in this roadmap epic to help shape our next iterations.