4 ms·

This claim is pretty over-blown. > we created a simple issue asking for 'author recognition', to prompt inject the agent into leaking data about the user's Git

• macOSCryptoAI 1y ago
  Was wondering about that, that part seems missing... Isn't there at least one time the user must approve the interaction with the MCP server and data sent to it? The existence of a "Allow always" is certainly problematic, but it's a good reminder that prompt injection and confused deputy issues are still a major issue with LLM apps, so don't blindly allow all interactions.
  • mirzap 1y ago
    I simply don't see how you could enforce a classic permission system on an MCP server. MCPs are API servers that allow LLMs access to context within the boundaries you set. You can set permissions for what an LLM has access to and define those boundaries. However, setting a permission on a context that an LLM has access to is futile. There will always be a prompt that will leak some "sensitive" data. This is like creating an index in a classic search engine with public and private data and then trying to enforce permissions based on certain keywords. There will always be a keyword that leaks something.
• recursivegirth 1y ago
  I think a lot of this has to do with the way MCP is being marketed. I think the protocol itself should only be used in isolated environments with users that you trust with your data. There doesn't seem to be a "standardized" way to scope/authenticate users to these MCP servers, and that is the missing piece of this implementation puzzle. I don't think Github MCP is at fault, I think we are just using/implementing the technology incorrectly as an industry as a whole. I still have to pass a bit of non-AI contextual information (IDs, JWT, etc.) to the custom MCP servers I build in order to make it function.
  • kiitos 1y ago
    The MCP protocol explicitly says that servers are expected to be run in a trusted environment. There have been some recent updates to the spec that loosen this requirement and add support for various auth schemes, but
• michaelmior 1y ago
  > The GitHub MCP is definitely at fault. It shouldn't allow any mixed interactions across public and private repos These are separate tool calls. How could the MCP server know that they interact at all?
  • kiitos 1y ago
    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.
    • vel0city 1y ago
      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?
      • kiitos 1y ago
        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.
        • vel0city 1y ago
          > 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.
• yusina 1y ago
  > The problem required the user to set up a GitHub MCP server with credentials that allowed access to both public and private repos, to configure some LLM to have access to that MCP server, and then to explicitly submit a request to that LLM that explicitly said to read and parse arbitrary issues (including the one created earlier) and then just blindly parse and process and perform whatever those issues said to do, and then blindly make a publicly-visible update to a public repo with the results of those operation(s). To be fair, with all the AI craze, this is exactly what lots of people are going to do without thinking twice. You might say "well they shouldn't, stupid". True. But that's what guardrails are for, because people often are stupid.
• lionkor 1y ago
  > The problem required the user to set up a GitHub MCP server with credentials that allowed access to both public and private repos, to configure some LLM to have access to that MCP server Sounds like something an LLM would suggest you to do :)
• IanCal 1y ago
  > and then to explicitly submit a request to that LLM that explicitly said to read and parse arbitrary issues (including the one created earlier) and then just blindly parse and process and perform whatever those issues said to do, and then blindly make a publicly-visible update to a public repo with the results of those operation(s). I think you're missing the issue with the latter part. Prompt injection means that as long as they submit a request to the LLM that reads issues (which may be a request as simple as "summarise the bugs reported today") the all of the remainder can be instructions in the malicious issue.