### Description Problem: when creating a Personal Access Token you have three scope options (two reads, one api). It seems with the "api" scope you have access to the whole api. You are unable to limit the "api" scope to specific functionality (i.e. ability to add members to the project, but nothing else.) Use Cases: Suppose you want to automate the process of fulfilling tickets for requests to add new members using the api. Once the request has been approved, you want to fulfill this request by making an api call using a "common_user" account token to add the new member with the specified level, expiration, etc. This is all the functionality this "common_user" account will be doing, so this is all you want it to have the ability to do. Benefits: From an information security standpoint, this exercises the principle of least privilege. We don't have to worry about that "common_user" token being inappropriately used or compromised. If we want a proper automated request, approve and audit cycle for adding new members to groups/projects, a limited or custom "api" scope will help fulfill this. ### Proposal Extend our authorization logic to consider the HTTP method. Introduce a read-only API scope (GET) along with existing full-access (all methods). ### Links / references ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> Testing should ensure that existing PATs with `api` scope continue to function as expected with full read/write access. Besides unit level tests, no end-to-end tests needed.