### Goal Developers run Claude agents (Claude Code, Claude Desktop, claude.ai) on their laptops and connect them to GitLab's MCP server at `/api/v4/mcp` over OAuth. An administrator (an instance admin on self-managed and Dedicated, or a group owner on GitLab.com) registers one OAuth application and declares which namespaces and permissions those agents may reach. Each developer authorizes the application separately and gets their own token. Effective access is the intersection of the application's declared scope set and the developer's live membership: the administrator sets a ceiling, and the developer's own access narrows it further. Done looks like this: an administrator registers an application declaring group X with read-only permissions plus `execute_mcp_tool`, and configures Claude Code with the client ID. A developer authorizes once, and the agent can list and read inside group X but is denied outside it and on writes within it. An agent using its own OAuth client instead of the shared one is rejected wherever the namespace requires granular tokens, and revoking the grant cuts the agent off on its next request. ### What phase 1 delivers and leaves out Phase 1 is https://gitlab.com/gitlab-org/gitlab/-/work_items/605869 (milestone 19.5, feature flag `granular_oauth_tokens`, no UI), built against proposal 017 (https://gitlab.com/gitlab-org/architecture/auth-architecture/design-doc/-/merge_requests/136), under the parent epic https://gitlab.com/gitlab-org/gitlab/-/work_items/468924. It delivers OAuth tokens that carry only the `granular` scope string, with permissions resolved per request through one consent grant per user and application joined to `granular_scopes`, enforced by the same boundary policy used for granular PATs (project, group, user, and instance boundaries). It leaves out any UI (phase 2, owned by the consuming teams named in the parent epic), OAuth tokens under the namespace enforcement setting, and any application-level scope declaration. Those gaps are what this item covers. | Task | What it covers | | --- | --- | | https://gitlab.com/gitlab-org/gitlab/-/work_items/608632 | Extract `Authz::GranularTokenInterface` (done) | | https://gitlab.com/gitlab-org/gitlab/-/work_items/608633 | Generalize `Authz::BoundaryPolicy` (done) | | https://gitlab.com/gitlab-org/gitlab/-/work_items/608634 | Add tables `oauth_consent_grants` and `oauth_consent_grant_granular_scopes` (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255384) | | https://gitlab.com/gitlab-org/gitlab/-/work_items/608635 | Implement the interface on `OauthAccessToken`; OAuth tokens are excluded from `granular_token_required?` so existing integrations keep working | | https://gitlab.com/gitlab-org/gitlab/-/work_items/608636 | Consent capture and minting at authorization and refresh, including the trusted-app auto-grant | | https://gitlab.com/gitlab-org/gitlab/-/work_items/608637 | Enforcement wiring for REST, GraphQL, and Git over HTTP; rollout beyond internal testing waits on the boundary conjunction defect and the KAS proxy path (https://gitlab.com/gitlab-org/gitlab/-/work_items/604810) | | https://gitlab.com/gitlab-org/gitlab/-/work_items/608638 | Console proof | W4 now covers three bypass paths, including one that survives namespace enforcement; see its rollout subsection for namespaces that already enforce granular tokens. ### Work breakdown | # | Work | Owner | Depends on | Notes | | --- | --- | --- | --- | --- | | W1 | Pass the access token into MCP tool execution | MCP server owners | None | Also fixes granular PAT enforcement today | | W2 | Application-level declared scope set | group::authorization | #608634 | Tasks W2.1 to W2.3. W2.1 (#630370) in progress in !257023. Needed before the trusted auto-grant in #608636. | | W3 | Consent and management path for group-owned applications | group::authorization (backend/API), consuming teams (UI) | W2 | Group owners are UI-only until an applications API exists for group-owned apps | | W4 | Enforcement so the ceiling cannot be bypassed | group::authorization | #608635, phase 1 flag, W1, W2, W3 | Staged lift of `granular_token_required?` to OAuth plus an application-ownership rule under enforcing namespaces; Duo composite exemption; migration mode for already-enforcing namespaces | | W5 | Client and protocol details | group::authorization, with MCP server owners | W2 (request contract) | Scope advertisement, Claude client configuration, PKCE | | W6 | Per-tool governance for external MCP clients | MCP server owners | None | Optional for this scenario | ### W1. Pass the access token into MCP tool execution Granular personal access tokens pass the MCP entry check, but GraphQL-backed and custom MCP tools never receive the token, so they run with the user's full access instead of the token's declared scopes. This affects granular PATs today and granular OAuth tokens once phase 1 ships. REST re-dispatch tools and the aggregated tools built on them already handle this correctly. The work has no dependency on the OAuth track and can start now. ### W2. Application-level declared scope set The tables from !255384 require a user on every grant, so nothing could hold a scope set per application. W2 adds that. Decisions made: consent grants copy the declared scopes rather than reference them, decided in #608636. The request contract is a per-application declaration with no scope parameter on the request, and !257024 forces a granular application's authorize request to the `granular` scope. Widening or narrowing the declared set therefore does not change existing grants. W3 revokes grants on amendment so users re-consent. Boundary validation is against the application's owner, not a target user. Instance applications may declare any access level, group-owned applications are confined to their own hierarchy, and user-owned applications follow the PAT rule. Detail is in W2.3. Dynamic applications also have a nil owner, so ownership rules in W4 must test `dynamic` explicitly. W4's ownership rule means a user-owned granular application is a least-privilege tool for its owner, not a way past a group's ceiling, so W2 validation does not need tightening for that purpose. The declared set must include `execute_mcp_tool` at the user boundary, or tokens never pass the MCP entry check at `lib/api/mcp/base.rb:209`. <details> <summary>W2 tasks</summary> | Task | What it covers | |---|---| | W2.1 #630370 | Table, model, trigger, organisation transfer. In progress in !257023. Its description refers to the declaring write path as W3; that work is W2.3. | | W2.2 #631824 | Shared builder and uniqueness refactor. | | W2.3 #631825 | Declaring service with owner rule, `granular` scope, warning, audit. | </details> ### W3. Consent and management path for group-owned applications The `trusted` flag can currently only be set by instance admins (https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/admin/applications_controller.rb#L75-L77), but on GitLab.com the administrator in this scenario is a group owner. Extending `trusted` to group owners is not recommended, since it would skip consent for every user on the instance, not only the group's members. For a non-trusted application with a declared set, the consent screen should show that set read-only, and authorizing should write an ordinary `doorkeeper` grant from it. Amending the declared set should revoke existing grants so affected users re-consent. Trusted instance applications keep the existing `skip_authorization` path, writing a `trusted_auto_grant` grant from the declared set instead. The admin UI needs a way to declare the scope set on application create and edit, for instance and group applications, and the applications REST API (`POST /applications`) needs a granular scopes parameter. Both call the W2.3 service, which owns boundary validation, actor authorisation and the audit event. Group-owned applications have no REST API today (https://docs.gitlab.com/user/model_context_protocol/mcp_server/#reuse-a-single-oauth-application), so group admins will be UI-only until one exists. The "Reuse a single OAuth application" documentation section should be extended to describe the granular flow. ### W4. Enforcement so the ceiling cannot be bypassed Four bypass paths exist (1-3 once W2 ships, 4 is live today). All end in a token that the group's declared ceiling never sees: 1. **Dynamic client registration** creates `[Unverified Dynamic Application]` records with `trusted: false`, `dynamic: true`, and scopes forced to `mcp` or `mcp_orbit` (https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/oauth/dynamic_registrations_controller.rb#L43-L50 and https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/oauth/dynamic_registrations_controller.rb#L72-L90). The token is legacy, with the user's full access. 2. **A user-owned application with the `mcp` scope** mints the same legacy token, and is not `dynamic`. 3. **A user-owned (or foreign-group-owned) granular application.** Once W2's declaring write path exists, a member can declare every permission they hold, consent to their own application, and receive a `granular` token. Namespace enforcement passes it, because enforcement only asks whether a token is granular, not which application minted it. Audit events show a well-formed consent grant, so it looks like compliant usage. <details> <summary>Example: an enforcing group and a member's own granular application</summary> **Setup.** Acme is a top-level group on GitLab.com with the MCP server enabled and `enforce_granular_tokens` set, enforcement date in the past. Dana, an Acme owner, registers a group-owned application "Acme MCP" declaring `execute_mcp_tool` at the user boundary plus read-only permissions (`read_project`, `read_code`) on `acme/platform`, and distributes its client ID through managed settings. Sam is a developer with Maintainer on `acme/platform` and Developer on `acme/billing`. **Intended path.** Sam configures Claude Code with Dana's client ID, sees the consent screen listing the declared set, approves, and receives a token with scope `granular`. Every request resolves that token to Sam's grant for "Acme MCP": reads on `acme/platform` succeed, writes are denied, `acme/billing` is invisible. **Bypass.** 1. Sam creates a user-owned application "Sam's MCP" and, with the W2 declaring write path, attaches `execute_mcp_tool` at the user boundary plus `selected_memberships` scopes on `acme/platform` and `acme/billing` listing every permission they hold there, reads and writes alike. Boundary validation "like PATs" passes, because Sam is a member of both. 2. Sam points Claude Code at their own client ID. The application is granular, so the authorize request is forced to scope `granular`; the consent screen shows Sam's own declared set; Sam approves; a `doorkeeper` consent grant is written copying that set. 3. The token is minted with scope `granular`. `granular?` is true, `legacy?` is false. 4. MCP entry: the token carries `granular`, Sam belongs to a group with MCP enabled, and the grant holds `execute_mcp_tool`. Admitted. 5. Per-tool checks inside Acme run `Authz::Tokens::AuthorizeGranularScopesService`. `should_check_authorization?` is true because the token is granular; `granular_token_required?` is irrelevant because the token is not legacy. The tool's required permission is compared with Sam's grant, which contains everything Sam declared. Writes to `acme/platform` and reads of `acme/billing` succeed, and role checks pass because Sam holds those roles. Nothing in that chain ever looks at "Acme MCP". Enforcement asked "is this a granular token" and got yes. **What still holds.** Sam cannot exceed their own membership, at declaration time or later, because effective access is the declared set intersected with live permissions. Revoking Sam's roles cuts the agent off immediately. What Dana lost is the blast-radius reduction: a prompt-injected agent can now merge into `acme/billing` or exfiltrate code from it, which the declared set was meant to prevent. **Why existing controls miss it.** Namespace enforcement passes (granular). A toggle against dynamic applications does nothing ("Sam's MCP" is not dynamic). Disabling user-owned applications (`user_oauth_applications`) is instance-wide and self-managed only, and Sam could host the application in any other group where they are Owner, since group-owned declarations are validated against the owning group, not the target group. **Under Proposals 1 + 3 below.** Step 5 additionally asks whether the token's application is owned by Acme or is a genuine instance application. "Sam's MCP" is user-owned, so the request is denied with an error naming Acme's own application client ID. </details> 1. **A fine-grained PAT with the `execute_mcp_tool` permission.** A member mints a granular PAT, adds every permission they hold on the group's projects, and points the client at the MCP endpoint with a static bearer header (skips OAuth flow). Namespace enforcement passes it because it only asks whether the token is granular. <details> <summary>Example: an enforcing group and a member's own fine-grained personal access token</summary> Same setup as bypass 3, except Sam skips Dana's application entirely and never sees a consent screen. **Bypass.** 1. Sam creates a fine-grained PAT with `execute_mcp_tool` at the user boundary plus every permission they hold on `acme/platform` and `acme/billing`, reads and writes alike. Boundary validation passes because Sam is a member of both. 2. Sam configures Claude Code with a static `PRIVATE-TOKEN` header carrying that PAT. 3. MCP entry: the token is granular and holds `execute_mcp_tool`. Admitted. Namespace enforcement passes for the same reason. 4. Per-tool checks inside Acme compare the tool's required permission with the token's own declared set, which Sam filled in. Writes to `acme/platform` and reads of `acme/billing` succeed. **What still holds.** Sam cannot exceed their own membership. What Dana lost is the same blast-radius reduction as in bypass 3. **Why existing controls miss it.** Namespace enforcement passes (granular). There is no application to inspect, dynamic or otherwise. </details> Existing controls do not cover this. The instance settings `dynamic_client_registration_enabled` and `user_oauth_applications` are self-managed only and absent on GitLab.com, the `explain_missing_dynamic_client` error (https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/oauth/tokens_controller.rb#L61-L70) only helps once DCR is off, and the MCP server group setting gates entry per user rather than access per resource. The general mechanism already exists at the namespace level: `enforce_granular_tokens` and `granular_tokens_enforced_after` (https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/namespace_setting.rb#L83-L97 and https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/namespace_setting.rb#L246-L250) drive `granular_token_required?`, which rejects legacy tokens under an enforcing namespace. Phase 1 excludes OAuth from this check in https://gitlab.com/gitlab-org/gitlab/-/work_items/608635, since applying it broadly today would break every `api`-scoped OAuth integration before a granular alternative exists for them. Two complementary controls are proposed. A third, a GitLab.com per-root-namespace toggle rejecting `dynamic` applications at the MCP entry point, was considered and dropped: the ownership rule below subsumes it for any enforcing group, and its "any of the user's root groups" entry-point semantics would cut a user off from all MCP use because one of their groups opted in. **Proposal 1: staged lift of `granular_token_required?` to OAuth tokens.** Stage one applies the check to OAuth tokens whose scopes include `mcp` but not `api` or `read_api`, a population that is new, mostly AI agents, with no long-lived integrations built on it. Stage two extends it to all OAuth tokens once the creation and consent UI gives `api` integrations a migration path. **Proposal 3: application ownership under enforcing namespaces.** For the same stage-one population, a token touching a resource under an enforcing root namespace is admitted only if its application is **owned by that root namespace** or is a **genuine instance application**, meaning `owner` is nil **and** `dynamic` is false (dynamic applications are also owner-less). The check lives in `Authz::Tokens::AuthorizeGranularScopesService` next to `root_namespaces_enforce_granular_tokens?`, using the token's `application_id` and the boundaries' root namespace IDs. - PATs keep working outside MCP (REST, GraphQL, Git over HTTP). On an MCP tool call under an enforcing namespace the token must have been minted through an group-owned or instance application, so a PAT is denied there with the same error naming the group's own application client ID; the check therefore needs to know it runs on the MCP path, which W1 can mark in the tool context. Trade-off to record: this shuts out headless or CI-style agents that cannot complete an OAuth browser flow until a service-account or group-access-token path through the owned application exists. - Instance applications are admitted because GitLab's own clients (Duo, Web IDE) are instance applications, because self-managed and Dedicated administrators register one instance-wide application rather than one per group, and because only instance administrators can create them. Combined rule under an enforcing namespace in stage one: an MCP OAuth token must be granular **and** minted through an application the namespace owns or the instance provides. Granular-only defeats paths 1 and 2; ownership defeats path 3. Neither alone closes the worked example. Consequences and open points: - **Duo composite application.** The Duo Agent Platform composite application (https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/ai/duo_workflows/create_composite_oauth_access_token_service.rb) is owner-less and trusted, and its tokens carry `ai_workflows mcp user:*` with no `api`. They fall inside the stage-one population and are not granular, so Proposal 1 would reject them under enforcing namespaces before ownership is even considered, breaking Duo workflows in exactly the groups most likely to enforce. Decide between (a) exempting trusted instance applications from the stage-one lift as an explicit, recorded allow, or (b) making Duo tokens granular through the per-session grants in proposal 017 before stage one ships. Verify that the Web IDE default application (scope `api`) and any other first-party instance applications stay outside the population. - **Entry point.** The MCP entry check is declared at the user boundary (https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/api/mcp/base.rb#L202) and cannot evaluate a root namespace. Check only `granular` plus `execute_mcp_tool` there, and apply Proposals 1 and 3 per tool where the boundary resolves to a project or group. This depends on W1, so that every tool actually runs the check with the token in hand. Do not deny at entry based on "any of the user's root groups". - **Multi-group users.** A user in two enforcing groups needs one client configuration per group, and each token works only inside its own group, because W2 already confines group-owned declarations to the group's hierarchy. Record this as an accepted UX cost. - **Error message.** When a token is denied for ownership, include the enforcing group's own MCP application client IDs (if any exist) in the error so the user can reconfigure without reading docs. Fall back to the "Reuse a single OAuth application" docs link only when the group has no application. - **IAM cutover.** IAM-issued tokens must expose the client or application identity for the ownership check to survive the Q3 cutover. Add to the open questions tracked in proposal 017. - **Performance.** The check adds an `oauth_applications` lookup per authenticated request. Preload `application` with the token, the same concern #608635 records for the grant lookup. - **Observability.** Key `Current.token_info` on `application_id` and owner type so denied-by-ownership is distinguishable from denied-by-legacy in logs (#608637). #### Rollout for namespaces that already enforce granular tokens Namespaces with `enforce_granular_tokens` and a past `granular_tokens_enforced_after` already exist on GitLab.com, behind the `granular_personal_access_tokens_enforcement_saas` flag. Shipping Proposals 1 and 3 as-is would, on day one, reject every MCP OAuth token in those groups (Claude Code and claude.ai through Anthropic's shared dynamic registration, plus user-owned applications) with an error pointing at the "Reuse a single OAuth application" docs and no application to reuse. Preconditions before any enforcement of OAuth tokens: the W2 declaring write path, the W3 group-owned application flow, and the error message above. Then choose a migration mode. Options for migrating enforcing namespaces (not mutually exclusive): | # | Option | Who acts | Mechanism | Trade-off | | --- | --- | --- | --- | --- | | M1 | **Warn-only period** | nobody | Per-root-namespace flag; evaluate Proposals 1 and 3 but only log and surface a warning (MCP `initialize` response `instructions`, tool-result annotation, `Current.token_info`), no denial. Flip to deny per namespace later. | Zero breakage; yields data on how many members use non-compliant applications per group. Needs W1 for coverage. | | M2 | **Separate OAuth enforcement date, owner opt-in** | group owner | New `NamespaceSetting#oauth_granular_tokens_enforced_after` (nil = not enforced), same UI pattern as `granular_tokens_enforced_after`. The existing PAT date is not reused, so currently enforcing groups are untouched until the owner sets an OAuth date. | Safest; but groups that expect their existing setting to cover agents stay exposed until the owner acts. | | M3 | **Automatic grace window with owner notification** | GitLab, then owner | On ship, enforcing namespaces get `oauth_granular_tokens_enforced_after = ship + N days` through a background migration. Email plus group settings banner to owners with a checklist: create the group MCP application, declare scopes, distribute the client ID. In-app to-do for owners. | A deadline guarantees coverage; owners who miss the notice still break on day N. No owner mailer exists for `enforce_granular_tokens` today; it must be built. | | M4 | **Auto-provision a group MCP application** | GitLab, owner completes | Background job creates one group-owned public application per enforcing namespace ("<group> MCP", scopes `mcp granular`, loopback redirect URI, which Doorkeeper matches for any port) with an **empty** declared set. The group settings page shows it as "setup incomplete" until an owner declares scopes, and the denial error names this application's client ID. | Removes the "no application exists" dead end and gives users a concrete client ID. Choosing a declared set on the owner's behalf is out of bounds, so the application is not granular until the owner acts. Redirect URIs for non-loopback clients such as claude.ai connectors still need owner input. | Recommended: **M1 and M2 by default, with M4 to make the owner's job a single step**, and M3 only if product wants a hard deadline. Sequence: W2 and W3 UI, then M4 provisioning, then M1 warn mode on enforcing groups, then owners set the OAuth date (M2), then deny. Owner communication lists the client ID and the docs section. ### W5. Client and protocol details The protected resource metadata endpoint advertises `scopes_supported: ["mcp"]` (https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/oauth/protected_resource_metadata_controller.rb#L34-L39), and clients request scopes from there or from the `scope` parameter of the `WWW-Authenticate` header on a 401. `granular` is backend-only and clients cannot request it directly; the MCP endpoint currently accepts either `mcp` or `granular` (https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/api/mcp/base.rb#L65-L66). The request contract from W2 needs to define what happens to a client's requested `mcp` scope when the application has opted into granular scopes. Claude clients support a pre-registered client. Claude Code takes `--client-id` on `claude mcp add` or `oauth.clientId` in `.mcp.json`, and managed settings can distribute the server entry with the client ID; secrets are not allowed in managed settings, so the shared application should be a public client using PKCE. Claude Desktop and claude.ai expose Client ID and Client Secret under Advanced settings. See https://code.claude.com/docs/en/mcp, https://code.claude.com/docs/en/managed-mcp, https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp, and https://claude.com/docs/connectors/building/authentication. GitLab currently requires PKCE only for dynamic applications (https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/oauth/authorizations_controller.rb#L256-L271). It is recommended to require, or at least document, PKCE for the shared public application used here. On redirect URIs: Doorkeeper compares loopback redirect URIs ignoring the port (RFC 8252), so one registered application serves Claude Code's `http://localhost:<port>/callback` style callbacks. claude.ai connectors use a fixed HTTPS callback that must be registered on the application explicitly, which matters for the M4 auto-provisioning option in W4. ### W6. Per-tool governance for external MCP clients `Ai::ToolRule` already supports allow, ask, and deny rules (https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/ai/tool_rule.rb), but only Duo flow services consume them today. The MCP tool base classes include `GovernanceNamespaceResolver` as groundwork (https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/mcp/tools/concerns/governance_namespace_resolver.rb), but nothing in the tool-call handler enforces those rules yet, and `X-Gitlab-Enabled-Mcp-Server-Tools` only filters `tools/list`. This is not required to scope agents by namespace and permission, which W1 through W5 already cover. It matters for an administrator who wants to disable specific write tools for agents beyond what the granular scope set expresses. ### Sequencing W1 has no dependency on the OAuth track and can start now; it also fixes granular PAT enforcement immediately. W2 is tracked as W2.1 to W2.3. W2.1 is in progress. W2.2 can start now, since it touches only PAT code on `master`. W2.3 follows W2.1, W2.2 and the `granular_oauth_tokens` flag. W3 follows W2, and W4 follows https://gitlab.com/gitlab-org/gitlab/-/work_items/608635, the phase 1 flag, and W1 through W3 (the ownership rule needs the declaring write path, the group application flow, and the token threaded into every tool). If M3 is chosen, an owner notification mailer for the OAuth enforcement date must be built; none exists for `enforce_granular_tokens` today. W5 gets settled together with the request contract in W2, and W6 is independent of the rest. Enabling the `granular_oauth_tokens` flag beyond internal testing still waits on the boundary conjunction defect and on https://gitlab.com/gitlab-org/gitlab/-/work_items/604810, per https://gitlab.com/gitlab-org/gitlab/-/work_items/608637. The conjunction defect matters here because roughly forty endpoints derive their boundary from the URL while also touching a second container named in the request body. On observability, #608637 keys `Current.token_info` off the granular token interface, and MCP tool-call logs should carry the same distinction between granular and legacy tokens. ### Acceptance criteria - [ ] An admin creates an OAuth application, declares group X with read permissions and `execute_mcp_tool`, and shares its client ID with developers - [ ] A developer configures Claude Code with that client ID, authorizes once, and the agent can list and read resources inside group X - [ ] The same agent is denied on a project outside group X and on write tools inside group X, with the existing granular denial error - [ ] A GraphQL-backed tool and a REST-backed tool both enforce the token's granular scopes - [ ] A Claude client using a dynamically registered application, a user-owned application, or a user-owned granular application is denied on resources under a root group that enforces granular tokens, with an error naming the group's own application client ID (or linking to the docs when the group has none) - [ ] A Duo Agent Platform workflow keeps working under an enforcing root group, per the recorded Duo composite decision - [ ] Namespaces that already enforced granular tokens before this shipped went through the chosen migration mode (warn period and/or owner-set OAuth date) before any denial - [ ] Revoking the grant from the authorized applications page denies the agent on its next request, without waiting for token expiry - [ ] Narrowing the application's declared set applies to existing users' access according to the reference-or-copy decision from W2, and that behavior is documented - [ ] Tool-call logs distinguish granular OAuth tokens from legacy tokens ### References - Phase 1 item: https://gitlab.com/gitlab-org/gitlab/-/work_items/605869 - Parent epic: https://gitlab.com/gitlab-org/gitlab/-/work_items/468924 - Design proposal 017: https://gitlab.com/gitlab-org/architecture/auth-architecture/design-doc/-/merge_requests/136 - Consent grant tables MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255384 - Phase 1 tasks: https://gitlab.com/gitlab-org/gitlab/-/work_items/608632, https://gitlab.com/gitlab-org/gitlab/-/work_items/608633, https://gitlab.com/gitlab-org/gitlab/-/work_items/608634, https://gitlab.com/gitlab-org/gitlab/-/work_items/608635, https://gitlab.com/gitlab-org/gitlab/-/work_items/608636, https://gitlab.com/gitlab-org/gitlab/-/work_items/608637, https://gitlab.com/gitlab-org/gitlab/-/work_items/608638 - KAS proxy path: https://gitlab.com/gitlab-org/gitlab/-/work_items/604810 - MCP server docs (reuse a single OAuth application): https://docs.gitlab.com/user/model_context_protocol/mcp_server/#reuse-a-single-oauth-application - Claude Code MCP docs: https://code.claude.com/docs/en/mcp - Claude Code managed MCP docs: https://code.claude.com/docs/en/managed-mcp - Claude custom connectors (remote MCP): https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp - Claude connector authentication docs: https://claude.com/docs/connectors/building/authentication