Fine-Grained PAT vs GitHub App vs OAuth: Which Limits GitHub MCP Server Access Best?

What 'limits access' means in practice

An MCP server acts with delegated permissions and chains tool calls. That raises the impact of a single weakness, because whatever the credential can reach, any tool the agent calls can reach too. The credential is therefore the outer boundary of an agent's capability.

Four properties define how well a credential limits access. Permission scope is whether it can be restricted to read-only or to specific resource types. Resource scope is whether it can be restricted to the repositories the task involves. Lifetime is how long the credential remains valid and how easily it is rotated or revoked. Accountability is whether actions taken through it can be attributed to a specific person or application.

OWASP names over-scoped tokens as a distinct MCP risk. Its example is a server that requests broad access when read-only would do, which creates aggregation risk: one grant exposes more than the task needs. Its guidance is to give each MCP server the minimum permissions its function requires, use scoped per-server credentials and never share tokens across servers.

Comparing the three methods by criterion

The three methods differ first in who the credential represents. A personal access token is issued by and belongs to an individual user. A GitHub App is installed on an account or organization and acts as its own application identity. An OAuth app obtains authorization from a user and acts within that user's delegated access. Most of the practical differences below follow from that.

• Permission granularity: Evaluate whether the method lets you grant only the permissions the agent's function needs. Avoid any configuration that grants write access where read-only is enough. Verify the permission set for each method before approving it for an agent.
• Repository scoping: Select the method and configuration that limit the credential to the specific repositories in the task. A credential that reaches every repository its owner can reach is the over-scoped pattern, whichever method issued it.
• Token expiry and rotation: Shorter-lived, regularly rotated credentials reduce exposure if a token leaks. Store them in a secrets management system with fine-grained access controls, so access to the secret is also least-privilege.
• Attribution of actions: A personal token ties actions to the individual who issued it. A GitHub App ties them to an application identity. An OAuth app ties them to the authorizing user. Shared agents are easiest to audit when their actions are not mixed with a person's own activity.
• Organization-level control: Control is strongest when the organization decides which applications are installed or authorized, rather than individuals issuing their own credentials. Decide who may create, approve and retire each credential type.
• Revocation: Revocation should be fast, targeted and independent of any one employee. A credential tied to a person's account is exposed to that person's role changes. An application identity can be retired without touching a user.

Verdict by deployment scenario

For a single developer running a coding assistant locally, a fine-grained personal access token is the simplest fit. The assistant acts as that developer, so scope it to the specific repositories and the read or write permissions the work requires, and issue a separate token for each MCP server. The tradeoff is that the token belongs to a person, so offboarding, rotation and attribution depend on individual discipline unless the organization governs issuance.

For a shared or automated agent, such as a pull request reviewer or an issue triage agent running for a team, a GitHub App is the better fit. The agent has its own identity, actions are attributable to that application, and the credential does not depend on any one employee's account. This is the strongest pattern for accountability, because the audit trail separates agent activity from human activity.

For a remote MCP deployment where many users each connect their own assistant, an OAuth app fits best. Each session acts within that user's own delegated access, which keeps the agent from exceeding what the person could do. The tradeoff is that the agent inherits everything the user can reach unless the authorization is narrowly scoped. Audience validation also matters here: clients should identify the intended MCP server, and tokens should be validated as issued for that server.

Where credential scoping stops

Authentication establishes identity before an access decision is made. It is not the access decision for each action. Once a token is issued, every tool the credential permits is available to the agent, and the credential cannot tell a legitimate call from a misuse of the same permission.

Three risks remain after careful scoping. First, a toolset broader than the task exposes permitted actions the agent never needed. Second, prompt injection can steer an agent into misusing a tool it is legitimately allowed to call, such as writing to a pull request or reading an issue from a repository that was in scope. Third, a long-lived token extends the window in which any of this can happen.

NIST and OWASP both treat fine-grained authorization as separate from authentication. OWASP also recommends human-in-the-loop oversight as a governance control for MCP use. In practice that means a second layer that evaluates individual requests, which credential choice alone cannot provide.

Tool-call policy as a separate layer

Trussed enforces policy in the execution path, at the level of individual interactions and tool calls, including calls to MCP servers and from coding assistants. A call can be allowed, redacted, blocked or rate limited, or escalated for human approval. These decisions are enforced at runtime, not reviewed after the fact.

This complements the credential rather than replacing it. The token or app installation bounds what the agent can reach. Policy at the tool-call level then decides what the agent may do within that boundary, for example blocking a write call from an agent that should only read, or sending a sensitive action to a person for approval. Enforcement also produces audit-ready evidence of what the agent was allowed to do and what it did, which is useful when a security team or auditor asks for more than the credential's configuration.

Trussed does not choose or issue the GitHub credential. That decision stays with the security team, using the criteria above.