GitLab Project Access Tokens vs Group Access Tokens for MCP Servers

What the token choice decides

An MCP server sits between an agent and GitLab and presents GitLab operations as tools. Whatever credential the server holds defines the outer limit of what any of those tools can do. If the agent is prompt-injected or simply wrong, that limit is the blast radius.

Project access tokens are limited to a single project. Group access tokens span every project in a group and its subgroups. That one difference drives four decisions: how much the agent can reach, which role and scopes it is granted, how many credentials must be issued and rotated, and which token identity is blamed or credited for a given action.

NIST's least-privilege language applies directly. SP 800-53 Rev. 5 asks for only the accesses that are necessary for assigned tasks, for users and for processes acting on their behalf. An MCP-connected agent credential belongs in that second category, and the same text says such processes should run at no higher privilege than the mission requires.

Project tokens and group tokens side by side

The table compares the two token types on the dimensions that matter most when the holder is an agent rather than a person.

• Reach: Project token: one project. Group token: every project in the group and its subgroups, including projects added later.
• Role ceiling: Both carry an assigned role that caps what the token can do. The same role on a group token applies across a much larger set of projects.
• Scope options: Both are limited by the scopes selected at creation. A broad scope such as api widens the agent's actions on either type, but across far more data on a group token.
• Lifecycle: Project tokens mean more credentials to issue and rotate as agents multiply. Group tokens reduce that count but concentrate risk in each one.
• Auditability: Each token acts under its own token identity. Attribution is clear only if one token serves one agent and one task.
• Best fit: Project token: single-repository agents. Group token: narrowly scoped, read-oriented agents that must cover many projects.

Role and scope ceilings matter more than token type

Token type sets reach, but role and scope set capability. A token with api scope or a Maintainer role can let an agent read, write, merge or alter pipelines well beyond its task. On a group token, that same capability extends over every project beneath the group, so the combination of group reach and broad scope is the worst case for an agent credential.

A practical rule is to choose reach first and capability second. Start from the narrowest reach the task allows, which is usually a project token. Then assign the lowest role and the smallest scope set that lets the specific MCP tools you enable function. If the MCP server exposes tools the agent does not need, the credential should not have to cover them. Disable those tools rather than widening the token to match.

Separation of duties applies as well. NIST's agent identity guidance says agent access should be bounded to the minimum required for a designated task so an agent cannot assume conflicting privileges. Separate identities for retrieval, triage and review are easier to defend than one credential that can do all three.

Choosing a token for common agent tasks

These starting points apply the reach-first, capability-second rule. Each task gets its own token, and each token carries an expiry.

• Read-only code retrieval: Project token for the one repository involved, lowest role that permits reading, read-only scope. Use a group token only if the agent must search across a defined set of projects, and keep it read-only.
• Issue triage: Project token where triage is per project. The agent needs to read issues and add comments or labels. If the narrowest scope that permits those writes is broad, treat the token as a loose boundary and constrain the tool calls separately.
• Merge request review: Project token, with read access to code and merge requests and permission to comment. Do not grant merge rights or write_repository. A review agent that can merge has stopped being a reviewer.
• Pipeline inspection: Read-only access to pipeline state on a project token. Pipeline modification is a separate task with a separate identity, if it is delegated to an agent at all.

Lifecycle, attribution and where token scoping stops

NIST's post on agent identity design says agent access should avoid long-lived bearer tokens and static, reusable secrets. It favors ephemeral access acquired when a task starts, time-bounded and audience-specific. Access tokens that live in an MCP server's configuration are closer to the static end of that spectrum. Short expiry, a named owner for each token and a tested revocation path narrow the gap. Many small project tokens raise the rotation workload, so automate issuance and rotation before you scale out agents.

Attribution follows the same logic. NCCoE working material recommends unique, traceable agent credentials with tightly scoped rights. A token shared across agents blurs which agent did what, and a group token reused across teams makes the history hard to interpret. One token per agent is the minimum for attributable activity.

Even a well-chosen token has limits. A scope is a static permission. If a token can comment on merge requests, it can do so on any merge request within reach, with any content, at any rate. It cannot distinguish a routine call from one steered by injected text. NIST describes individual tool invocations as needing continuous runtime verification, and it calls for policy separated from the model's reasoning with deterministic access decisions. NCCoE material also raises an open question about the sensitivity of data an agent aggregates as it gains tools. A per-token view does not address any of these.

Adding enforcement on each tool call

Treat the token as the outer boundary and the tool call as the decision point. Trussed enforces policy in the execution path across agents, tools and MCP servers. For each individual tool call, policy can allow, redact or block it, rate limit it, or escalate it for human approval. This means a permitted token does not automatically mean a permitted action. Enforcement happens at runtime, not after the fact.

The enforcement also generates audit-ready evidence of what the agent was allowed to do and what it did, including who approved escalated actions. Trussed serves regulated enterprises that need to show an auditor that evidence. Token scoping remains necessary, and runtime enforcement covers what scoping cannot.