## Executive Summary GitLab will offer fine-grained permissions for Personal Access Tokens, allowing users to create tokens with specific, limited access to only the resources and operations they need. This new capability replaces the previous broad scopes like `read_api` and `api` with granular permissions that can be restricted to specific projects and groups, significantly reducing the security blast radius if a token is compromised. Users can now apply the principle of least privilege to their automation and integrations by selecting precise combinations of read and write for different resource types including repositories, issues, pipelines, and more. --- ## Current Status See parent epic: https://gitlab.com/groups/gitlab-org/-/epics/18177#current-status+ --- ## Beta Scope ### User Experience - MVP As a user, when I create a token: - I can select between legacy (current) or fine-grained type (new, displays beta label) - I can scope down by namespaces including: my personal projects, all groups and projects I'm a member of, or select groups and projects. - I can select the granular resource and permission action by CRUD or verb. - There is 75% of REST endpoints covered by permissions during selection [(Wave 1-3)](https://gitlab.com/gitlab-org/gitlab/-/issues/572694) - I can see a single page documentation read-out of all the supported endpoints along with the permission names on a single page. This is broken down by boundary (group, project, user) and permission category. - There is an internal instrumentation event is triggered with the following metadata: * Type: Legacy or fine-grained model * Scope type selected: personal, all namespaces I’m a member of, or select namespaces (ignore customer values selected) * Resource and permissions selected - There is 10% of GraphQL resources covered by permissions during selection. <details> <summary> ### Interlock Details </summary> ##### Engineering Assessment * Epic/Issue dependencies: https://gitlab.com/gitlab-com/content-sites/internal-handbook/-/merge_requests/7011 ##### Dependencies * Team dependencies: None ##### DRIs * **PM**: @NellyVahab * **EM**: @jayswain * **DRI Eng**: @alexbuijs * **Other engs:** @abime (BE); @dftian (FE) * **UX/PDM**: @ipelaez1 @jmandell * **Group(s)**: ~&quot;group::authorization&quot; * **Engineering Owner**: @mmishaev * **Product Security:** @pmartinsgl ##### Initiative Driver - Product or Engineering? * [x] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment * These initiatives require a Product Priority label (P1/P2/P3) * They may also receive GTM tier labels (T1/T2/T3) for external communication * [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components * These initiatives require an Engineering Priority label (E1/E2/E3) * They have internal visibility only and are not externally communicated * Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades </details>