I dunno! But if it can't, then it can't allow itself to be instantiated in a way that allows these kinds of mixed interactions in the first place.

The GitHub API could also have the same effects if you wired up some other automated tool to hit it with a token that can access private and public repos. Is the GitHub API also at fault for having the potential for these mixed interactions?

Say you had a Jenkins build server and you gave it a token which had access to your public and private repos. Someone updates a Jenkinsfile which gets executed on PRs to run automated tests. They updated it to read from a private repo and write it out someplace. Is this the fault of Jenkins or the scoping of the access token you gave it?

GitHub provides the GitHub MCP server we're discussing right now. That tool allows interactions that violate the access control constraints defined by GitHub itself.

If you wired up "some other automated tool" to the GitHub API, and that tool violated GitHub access control constraints, then the problem would be in that tool, and obviously not in the API. The API satisfies and enforces the access control constraints correctly.

A Jenkins build server has no relationship with, or requirement to enforce, any access control constraints for any third-party system like GitHub.

> violate the access control constraints defined by GitHub itself.

I don't see anything defining these access control constraints listed by the MCP server documentation. It seems pretty obvious to me its just a wrapper around its API, not really doing much more than that. Can you show me where it says it ensures actions are scoped to the same source repo? It can't possibly do so, so I can't imagine they'd make such a promise.

GitHub does offer access control constraints. Its with the token you generate for the API.

The token you provide to the GitHub official MCP server determines what that server is allowed to access. But the MCP server doesn't just serve requests with responses, which is the normal case. It can read private data, and then publish that private data to something that is outside of the private scope, e.g. is public. This is a problem. The system doesn't need to make an explicit promise guaranteeing that this kind of stuff isn't valid, it's obviously wrong, and it's self-evident that it shouldn't be allowed.

I'm not sure whether you're confused, or I'm just having a horrible time understanding your point. The MCP server really does just serve requests with responses via a mechanism that satisfies the MCP spec. The MCP hosts (e.g. VSCode) work with an LLM to determine which of those tools to call, and ideally work with users via confirmation prompts to ensure the user really wants those things to happen.

What am I missing?

I do believe there's more that the MCP Server could be offering to protect users, but that seems like a separate point.

Sorry, I probably was being imprecise. You're correct that the [GitHub] MCP server really does serve requests with responses. But my point was that certain kinds of requests (like create_new_pr or whatever) have side effects that make mutating calls to third-party systems, and the information that can be passed as part of those mutating calls to those third-party systems isn't guaranteed to satisfy the access control expectations that are intuitively expected. Specifically by that I mean calling create_new_pr might target a public repository, but include a body field with information from a private repo. That's a problem and what I'm talking about.

The problem is that the MCP server does not know that the data being posted is intended to be private. It is provided as a separate disconnected API call. Yes, it would be possible for GitHub to scan the he contents of a request for things they might believe should be private but that would be very brittle.

How does the MCP server know the content is from a private repo?