Give a GitHub MCP token only the repo scopes it needs
You will set up a GitHub token for the MCP server that covers only the organization and repositories the workflow needs. Narrow tokens limit what an agent can reach if the token is misused or leaked.
Broad token
- Classic token with top-level repo scope
- Personal account as resource owner
- Broad permissions across many repos
Scoped token
- Fine-grained token set to the organization
- Read-only unless a task needs write
- Only the repos the workflow uses
- Token passed via environment variable
Why it matters
The GitHub MCP server can only do what its token allows. In one reported case, private org repos returned 404 or Bad credentials even with a PAT, and a maintainer closed the report as expected auth behavior because the same API calls fail directly against GitHub with the same token (source (opens external site)). Choosing the narrowest token that still works is the main control you have.
Steps
- Create a fine-grained personal access token and set "Resource Owner" to the company organization, not your personal account. One user got private org repos working this way (source (opens external site)).
- Grant access only to the repositories the workflow touches, with read permission first. Add write permission only when a specific task needs it.
- If the organization uses SSO, authorize the token for that organization after generating it (source (opens external site)).
- If you fall back to a classic token, use it as a last resort. In one reported case, enabling only the sub-scopes under "repo" did not grant private repo access, and a fine-grained read-only token failed while a classic token worked (source (opens external site)). Test each token type against one repo before widening it.
- Keep the token in an environment variable, not in a config file you commit. For Docker, the working args from the report were:
"args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
- Restart the container after updating the token, since the reported fix depended on it (source (opens external site)).
- Run one read call, such as list_issues against a single repo, to confirm access before you add more repositories.
Common mistakes
- Reusing a broad personal token for agent sessions instead of one scoped to the organization.
- Treating a 404 as a server bug without first checking the same token against GitHub directly.
- Forgetting that some organizations block PAT access entirely, which looks like a token problem.
- Committing tokens to config files. Rotate any token that was exposed.
The same principle applies to other MCP servers. In a Redshift MCP server report, every user shared one database user, which removed per-user attribution in system views like stl_query. No fix is merged yet (source (opens external site)). Where a server lets you choose an identity, pick the narrowest one.
Checklist
0 of 8 done