Repository navigation
Concern: GitHub PAT auth grants org-wide publish permissions regardless of user's role #982
Description
Activity
cc @jenn-newton
I will start exploring the approaches on the issue mentioned here and on discord by @rdimitrov https://discord.com/channels/1358869848138059966/1474187542164144231
Reacted by Radoslav Dimitrov@domdomegg @rdimitrov @tadasant
Did analysis of suggested solutions and tried POCs of other approaches also, adding document link for the same
https://www.notion.so/MCP-Registry-Authorization-Model-Analysis-Issue-982-31736f79f74980bc90c6e53de1c564c5?source=copy_link. Document also covers which approach has been selected by other registries(industry standard).Let me know if we can discuss this, I can give a walkthrough of each for quick clarity on each approach. Happy to take this issue also.
User-scoped publish as the default is the right call. The current behavior is essentially "any public org member can ship a release" which is closer to a bug than a feature for most orgs.
The
.github/mcp-registry-publishers.jsonallowlist is clean but I'd push back slightly on putting it in.github/- that directory is conventionally for GitHub features and adding registry-specific config there muddies it. A top-levelmcp-registry.jsonor even reusing the existing publish manifest pattern would be more discoverable.Validating actual GitHub permissions is feasible via the org membership API, but the enterprise concern you raised is real: "can write to any repo in the org" is way too permissive for a 10k-employee org. The allowlist approach scales better there, since it forces an explicit decision rather than inheriting whatever the repo permissions happen to be.
- added a commit that references this issue
on Jun 21, 2026 Picking this up as there is some urgency now to get this resolved.
Thanks @pree-dew for digging into this. My reactions:
- I think your Option B (B2) is probably the right long term solution
- I'm not big on Option A, because it requires the registry to maintain a mapping of server
namevalues to repositories. So I think Option B is strictly better and no more expensive to implement
That said, I think there's a lower lift short term solution I like: step-up the requirement for publishing a server at the org-level to be only allowed by org admins (instead of any org member).
This is fairly restrictive (not many individuals are GitHub admins), but for the 90% of cases where we'd be breaking some small company's flow, they can remediate it by getting an admin to issue a (very scope limited) PAT and adding it to their CI workflow.
Draft PR: #1383
@rdimitrov @BobDickinson @pree-dew what do you think? If this seems directionally correct, I can properly test and polish up that PR and try to land it this week.
cc @localden
- added a commit that references this issue
on Jul 10, 2026
Summary
When a GitHub user authenticates to the registry via PAT, they receive
io.github.<org>/*publish permissions for every org they're a publicly visible member of - regardless of their actual role.This means that a read-only org member can publish new versions of servers under the org's namespace.
This is intentional behaviour, but some users have raised concerns about this approach. I think it might be reasonable to tone down these permissions/allow better control of them, or at least document this more clearly?
Proposed change
Default to user-scoped publish only. PAT auth should grant
io.github.<username>/*and not automatically grant org-level publish. Orgs that want GitHub publishing already have OIDC.Opt-in allowlist for org publishing. Orgs that want specific users to publish via PAT can maintain a file like
.github/mcp-registry-publishers.jsonlisting which users can publish which servers. The registry would fetch this on auth and scope permissions accordingly.This would be a breaking change for users currently relying on PAT-based org publishing, so it would need a deprecation/warning period.
An alternative I'd be excited about (but I don't know how feasible it is) is to validate the GitHub user's permissions within the org, not just that they are a member of the org. Then we could filter it down only to people able to write to repositories or something. But not sure how feasible that is + I think this needs to be made more precise (e.g. what if you can only write to some repos? what about enterprises with many thousands of employees who may not want people who can write to repos to publish things?)