4 ms·

This is true for any code you install from a third party. Control your own MCP Server, your own supply chain, and this isn't an issue. Ensure it's mapped into

This is true for any code you install from a third party. Control your own MCP Server, your own supply chain, and this isn't an issue. Ensure it's mapped into your risk matrix when evaluating MCP services before implementing them in your organisation.

akoboldfrying 1y ago
> This is true for any code you install from a third party. I agree with you that their "discovery" seems obvious, but I think it's slightly worse than third-party code you install locally: You can in principle audit that 3P code line-by-line (or opcode-by-opcode if you didn't build it from source) and control when (if ever) you pull down an update; in contrast, when the code itself is running on someone else's box and your LLM processes its output without any human in between, you lack even that scant assurance.
- spoaceman7777 1y ago
  If you replace the word "LLM" in your reply with "web browser", I think you'll see that the situation we're in with MCP servers isn't truly novel. There are lots of tools to handle the many, many programs that execute untrusted code, contact untrusted servers, etc., and they will be deployed more and more as people get more serious about agents. There are already a few fledgling "MCP security in a box" projects getting started out there. There will be more.
  - calrain 1y ago
    Yes, this is just 'your code' if you're writing your own MCP code, but it's also 'Googles' code if you're using their MCP service in front of GMail. As with all code reviews, supply chain validation, CVE scanning, SNYK, whatever, definitely keep doing that for your home brew MCP implementation. For the commercial stuff, then that falls under the terms of service umbrella that covers all the stuff your company is still using from them. This article from CyberArk seemed to be fear mongering, not really educating people on writing better code. Not sure what their angle is, unless they are about to deliver a MCP Server service.
  - akoboldfrying 1y ago
    > If you replace the word "LLM" in your reply with "web browser", I think you'll see that the situation we're in with MCP servers isn't truly novel. Oh I agree 100%, and even pointed this out myself in other comments.

akoboldfrying 1y ago

> This is true for any code you install from a third party. I agree with you that their "discovery" seems obvious, but I think it's slightly worse than third-party code you install locally: You can in principle audit that 3P code line-by-line (or opcode-by-opcode if you didn't build it from source) and control when (if ever) you pull down an update; in contrast, when the code itself is running on someone else's box and your LLM processes its output without any human in between, you lack even that scant assurance.

spoaceman7777 1y ago
If you replace the word "LLM" in your reply with "web browser", I think you'll see that the situation we're in with MCP servers isn't truly novel. There are lots of tools to handle the many, many programs that execute untrusted code, contact untrusted servers, etc., and they will be deployed more and more as people get more serious about agents. There are already a few fledgling "MCP security in a box" projects getting started out there. There will be more.
- calrain 1y ago
  Yes, this is just 'your code' if you're writing your own MCP code, but it's also 'Googles' code if you're using their MCP service in front of GMail. As with all code reviews, supply chain validation, CVE scanning, SNYK, whatever, definitely keep doing that for your home brew MCP implementation. For the commercial stuff, then that falls under the terms of service umbrella that covers all the stuff your company is still using from them. This article from CyberArk seemed to be fear mongering, not really educating people on writing better code. Not sure what their angle is, unless they are about to deliver a MCP Server service.
- akoboldfrying 1y ago
  > If you replace the word "LLM" in your reply with "web browser", I think you'll see that the situation we're in with MCP servers isn't truly novel. Oh I agree 100%, and even pointed this out myself in other comments.