I have seen a bunch of demos of this, often building on top of open standards like the SAFE-MCP MITRE ATT&CK analysis https://github.com/SAFE-MCP/safe-mcp
In general, the only way to make sure MCPs are safe is to limit which connections are made in an enterprise setting
Agreed. Only provide the servers and tools needed for that job.
It would be silly to provide every employee access to GitHub, regardless of whether they need it. It’s just distracting and unnecessary risk. Yet people are over-provisioning MCPs like you would install apps on a phone.
Principle of least access applies here just as it does anywhere else.
The MCP landscape is a huge frothing septic tank. Go on, try to create a simple MCP server that is protected by a password and connect it to ChatGPT or Claude. Or even the one that uses your local SSO system for authentication.
I tried and failed after about 3 days of dealing with AI-slop-generated nonsense that has _never_ been worked. The MCP spec was created probably by brainless AI agents, so it defines two authentication methods: no authentication whatsoever, and OAuth that requires bleeding-edge features (dynamic client registration) not implemented by Google or Microsoft.
The easiest way for that right now is to ask users to download a random NodeJS package that runs locally on their machines with minimal confinement.
Had an almost identical experience. Even if you don’t need anything with auth, no one has yet made an mcp that wasn’t ultimately worse or the same as a cli but with a lot more song and dance. Security is also a bit of a joke when half the time it’s installing docker and phoning home. I wanted to like mcp and vend out remote mcp but this spec is not ready.
My understanding is that it can upgrade to an SSE connection so a persistent stream. Also for interprocess communication you usually prefer a persistent connection. All that to reduce communication overheads. The rationale also is that an AI agent may trigger more fine-grained calls than a normal program or a UI, as it needs to collect information to observe the situation and decide next move (lot more get requests than usual for instance).
This seems like the solution getting ahead of the problem. A series of API requests over HTTP can easily use a persistent connection and will practically default to that with modern client and server implementations. A claim that a more complex approach is needed for efficiency should be accompanied by evidence that the simple approach was problematic.
MCP can use SSE to support notifications (since the protocol embeds a lot of state, you need to be able to tell the client that the state has changed), elicitation (the MCP server asking the user to provide some additional information to complete a tool call) and will likely use it to support long-running tool calls.
Many of these features have unfortunately been specified in the protocol before clear needs for them have been described in detail, and before other alternative approaches to solving the same problems were considered.
I can't agree more, downloading OpenAPI doc for an API and parse it is more than enough to implement the core of MCP. But sadly the buzzword completely took of and for instance all participants to my trainings will ask for MCP, systematically.
Using SSE was far too inconvenient in theory despite that being how nearly all of the MCP that gained traction was working, so instead the spec was switched to being better in theory but very inconvenient in practice:
There are a million "why don't you _just_ X?" hypothetical responses to all the real issues people have with streamable http as implemented in the spec, but you can't argue your way into a level of ecosystem support that doesn't exist. The exact same screwup with oAuth too, so we can see who is running the show and how they think.
It's hard to tell if there is some material business plan Anthropic has with these changes or if the people in charge of defining the spec are just kind of out of touch, have non-technical bosses, and have managed to politically disincentivize other engineers from pointing out basic realities.
I use it basically as a cache, I create local artifacts that are fast to filter/query and easily paginate on the client (which is to say in the MCP server).
MCP provides a convenient packaging for tools, and generally workflows, for LLM clients.
You can debate all day whether bringing your own tools is a good thing vs giving the LLM a generic shell tool and an API doc and letting it run curls. I like tools because it brings reproducibility.
MCP is really just a json RPC spec. json RPC can take place over a variety of transports and under a variety of auth mechanisms- MCP doesn't need to spec a transport or auth mechanism.
I totally agree with everybody that most MCP clients are half assed and remote MCP is not well supported, but that's a business problem
Every LLM tool today either runs locally (cursor, zed, IDEs, etc.) so can run MCP servers as local processses w/ no auth, or is run by an LLM provider where interoperability is not a business priority. So the remote MCP story has not been fleshed out
You've obviously got some substantive points to make here, which is great, but indignant putdown rhetoric has a destructive effect on the threads. If you could just make your substantive points thoughtfully, we'd appreciate it.
However, it IS also a description of the current state of affairs in the MCP land. The comment threads and proposals in the MCP projects are dominated by the LLM-generated text, so it is almost impossible to keep the full picture in one's mind. LLMs made it possible to create an overwhelming amount of activity with ease.
Moreover, a lot of _code_ for the MCP servers is also AI-generated and has never been used in practice. It's easy to verify. Here are Github search results for the ProxyOAuthServerProvider that is supposed to delegate the authentication to a third-party server: https://github.com/search?q=ProxyOAuthServerProvider&type=co...
There are 215 results at the time of writing, and all but 3 of them are either forks of or LLM-fueled rewrites of the same code from the `modelcontextprotocol` repo. And one of the 3 is mine, and it doesn't quite work.
So yes, "It's just more of AI slop". Sorry. That's just a neutral description of the current state of affairs in the MCP/AI world. And yes, it's absolutely horrifying.
I don't have any problem with this argument* and if you had posted this comment originally I wouldn't have replied. The "absolutely horrifying" bit at the end is a bit beyond the pale, but not, er, absolutely horrifying.
Yes, I'm sorry about that. I really should not write one-line comments without taking time to detail them. I will just stay silent in future in these cases.
> bit beyond the pale
Uhm... Why? It's an honest question. I thought that "horrifying" (as in "inducing horror") is a normal descriptor, not racially/sexually loaded or anything. The AI situation certainly induces real dread in me.
I did say "a bit" :) - I guess because it pattern-matches to internet rhetoric for me. By 'internet rhetoric' I mean something where the largeness/sensationalness of the claim is high and the information content is low. (Oh also, the leading "And yes" is a bit of an internet trope)
This is quite minor though; if it distracts from the main point, I'd say forget it.
I've made some contributions to the typescript-sdk and I'm part of the MCP Contributors server and can confirm, it was all vibecoded and the direction it is going is really not promising.
There is a difference between protocol error and tool usage error, makes sense you want the model to see the tool usage error, so they can correct.
I'm guessing it has a the same shape as a normal message + IsError so on the handling side you don't really have to do anything special to handle it, just proceed as normal and send the results to the LLM so it can correct if needed.
“Ok, how do we do customer auth” has become my go-to question to kill MCP projects. There is no working solution which makes any kind of enterprise exploration into the space pointless.
The initial remote MCP specification was pretty painful, but the June spec and the upcoming November spec are much more workable - MCP auth is (mostly) just OAuth now. MCP Clients are OAuth clients and can be granted access tokens and managed just like any other 3rd party app integration.
I'd love to hear more about the specific issues you're running into with the new version of the spec. (disclaimer - I work at an auth company! email in bio if you wanna chat)
Basically, I'm trying to just create a protected MCP server that works with ChatGPT. That's it. Nothing fancy.
So far, I was not able to do it. And there are no examples that I can find. It's also all complicated by the total lack of logs from ChatGPT detailing the errors.
I'll probably get there eventually and publish a blog...
ChatGPT provides a new Apps SDK that makes things easier. The MCP server does need a proper Authorization Server to do OAuth, including DCR and OIDC metadata support, but those are the best way to do what they are trying to do. Anything else I have considered would be much worse security and discovery wise.
Serious question, as I’m starting to go through this process myself -
Is it possible for the customer to provide their own bearer tokens (generated however) that the LLM can pass along to the MCP server? This was the closest to a workable security I’ve looked at. I don’t know if that is all that well supported by Chat GUI/web clients (user supplied tokens), but should be possible when calling an LLM through an API style call, right (if you add additional pass thru headers)?
The LLM doesn't intervene much actually, it just tells what tool to call. It's your MCP implementation that does the heavy lifting. So yeah you can always shove a key somewhere in your app context and pass it to the tool call. But I think the point of other comments is that the MCP protocol is kinda clueless about how to standardize that within the protocol itself.
I think an important thing to note is the MCP client is a distinct thing from the ‘LLM’ architecturally, though many LLM providers also have MCP client implementations (via their chat ui or desktop / cli implementations).
In general, I’d say it’s not a good idea to pass bearer tokens to the LLM provider and keep that to the MCP client. But your client has to be interoperable with the MCP server at the auth level, which is flakey at the moment across the ecosystem of generic MCP clients and servers as noted.
> but should be possible when calling an LLM through an API style call, right (if you add additional pass thru headers
Nope. I assumed as much and even implemented the bearer token authentication in the MCP server that I wanted to expose.
Then I tried to connect it to ChatGPT, and it turns out to NOT be supported at all. Your options are either no authentication whatsoever or OAuth with dynamic client registration. Claude at least allows the static OAuth registration (you supply client_id and client_secret).
The MCP & DCR OAuth ecosystem was immature at the start, but has really evolved and become robust. E.g., WorkOS has some really robust OAuth that can act as a standalone proxy for MCP connecting to any existing auth infrastructure.
Metadata and resource indicators are solving the rest of the problems that came with the change to OAuth spec.
It's really messy now. ChatGPT in particular makes it really hard; it turns out that Custom GPTs with actions can do pretty well, if you bridge MCP tools into actions; but setting any of these up is a pita.
The LLMs are also really bad at generating correct code for OAuth logic - there are too many conditions there, and the DCR dance is fairly complicated to get right.
Shameless plug: we're building a MCP gateway that takes in any MCP server and we do the heavy lifting to make it compatible with any client on the other end (Claude, ChatGPT - even with custom actions); as a nice bonus it gives you SSO/logs as well. https://mintmcp.com if you're interested.
MCP works best for tool calling that doesn't require auth (so tools that are trusted on your own machine). The whole pitch that you should be using it for business facing tools and things that require auth is a terrible idea.
Even if you're doing local only - MCP tools can mostly be covered by simply asking Claude Code (or whatever) to use the bash equivalent.
> MCP works best for tool calling that doesn't require auth (so tools that are trusted on your own machine).
In other words, downloading random crap that runs unconfined and requires a shitty app like Claude Desktop.
BTW, Claude Desktop is ALSO an example of AI slop. It barely works, constantly just closing chats, taking 10 seconds to switch between conversations, etc.
In my case, I wanted to connect our CRM with ChatGPT and ask it to organize our customer notes. And also make this available as a service to users, so they won't have to be AI experts with subscriptions to Claude.
Is this to scan your own MCP servers? Does using someone else's MCP server put you at risk?
I didn't even know want an MCP server was until I noticed the annoying category in VSCode Extensions panel today. Only able to get rid of it by turning off a broad AI related flag in settings (fine by me, wish I knew it was there earlier). An hour later, I'm seeing this.
At Snyk, we've been working on this for a while. Here's our flagship open source project consolidating a lot of the MCP risk factors we've discovered over the last year or so into actionable info: https://github.com/invariantlabs-ai/mcp-scan
ALAN
It's called Tron. It's a security
program itself, actually. Monitors
all the contacts between our system
and other systems... If it finds
anything going on that's not scheduled,
it shuts it down. I sent you a memo
on it.
DILLINGER
Mmm. Part of the Master Control Program?
ALAN
No, it'll run independently.
It can watchdog the MCP as well.
DILLINGER
Ah. Sounds good. Well, we should have
you running again in a couple of days,
I hope.
I believe one of the main differences is that our scanner looks for toxic flows between mcp endpoints regarding how they interact with one another. Unless I'm missing something, the Cisco tool does not support this.
Our research lab discovered this novel threat back in July: https://invariantlabs.ai/blog/toxic-flow-analysis and built the tooling around it. This is an extremely common type of issue that many people don't realize (basically, when you are using multiple MCP servers that individually are safe, but together can cause issues).
This org has gone to some dubious lengths to make a name for themselves, including submitting backdoored packages to public npm repos which would exfiltrate your data and send to a Synk-controlled C&C. This included the environment, which would be sending them your username along with any envvars like git/aws/etc auth tokens.
This might give them some credibility in this space, maybe they stand a decent chance of scanning MCPs for backdoors based on their own experience in placing malicious code on other people's systems.
I have seen a bunch of demos of this, often building on top of open standards like the SAFE-MCP MITRE ATT&CK analysis https://github.com/SAFE-MCP/safe-mcp
In general, the only way to make sure MCPs are safe is to limit which connections are made in an enterprise setting
Agreed. Only provide the servers and tools needed for that job.
It would be silly to provide every employee access to GitHub, regardless of whether they need it. It’s just distracting and unnecessary risk. Yet people are over-provisioning MCPs like you would install apps on a phone.
Principle of least access applies here just as it does anywhere else.
The MCP landscape is a huge frothing septic tank. Go on, try to create a simple MCP server that is protected by a password and connect it to ChatGPT or Claude. Or even the one that uses your local SSO system for authentication.
I tried and failed after about 3 days of dealing with AI-slop-generated nonsense that has _never_ been worked. The MCP spec was created probably by brainless AI agents, so it defines two authentication methods: no authentication whatsoever, and OAuth that requires bleeding-edge features (dynamic client registration) not implemented by Google or Microsoft.
The easiest way for that right now is to ask users to download a random NodeJS package that runs locally on their machines with minimal confinement.
Had an almost identical experience. Even if you don’t need anything with auth, no one has yet made an mcp that wasn’t ultimately worse or the same as a cli but with a lot more song and dance. Security is also a bit of a joke when half the time it’s installing docker and phoning home. I wanted to like mcp and vend out remote mcp but this spec is not ready.
I'm still confused as to how mcp is better that say a Fastapi endpoint and it's generated swagger docs?
In the cases I’ve tried building/integrating they are the same thing…
I think the only difference is the statefulness of the request. HTTP is stateless, but MCP has state? Is this right?
I haven’t seen many use cases for how to use the state effectively, but I thought that was the main difference over a plain REST API.
My understanding is that it can upgrade to an SSE connection so a persistent stream. Also for interprocess communication you usually prefer a persistent connection. All that to reduce communication overheads. The rationale also is that an AI agent may trigger more fine-grained calls than a normal program or a UI, as it needs to collect information to observe the situation and decide next move (lot more get requests than usual for instance).
This seems like the solution getting ahead of the problem. A series of API requests over HTTP can easily use a persistent connection and will practically default to that with modern client and server implementations. A claim that a more complex approach is needed for efficiency should be accompanied by evidence that the simple approach was problematic.
MCP can use SSE to support notifications (since the protocol embeds a lot of state, you need to be able to tell the client that the state has changed), elicitation (the MCP server asking the user to provide some additional information to complete a tool call) and will likely use it to support long-running tool calls.
Many of these features have unfortunately been specified in the protocol before clear needs for them have been described in detail, and before other alternative approaches to solving the same problems were considered.
I can't agree more, downloading OpenAPI doc for an API and parse it is more than enough to implement the core of MCP. But sadly the buzzword completely took of and for instance all participants to my trainings will ask for MCP, systematically.
Using SSE was far too inconvenient in theory despite that being how nearly all of the MCP that gained traction was working, so instead the spec was switched to being better in theory but very inconvenient in practice:
https://blog.fka.dev/blog/2025-06-06-why-mcp-deprecated-sse-...
There are a million "why don't you _just_ X?" hypothetical responses to all the real issues people have with streamable http as implemented in the spec, but you can't argue your way into a level of ecosystem support that doesn't exist. The exact same screwup with oAuth too, so we can see who is running the show and how they think.
It's hard to tell if there is some material business plan Anthropic has with these changes or if the people in charge of defining the spec are just kind of out of touch, have non-technical bosses, and have managed to politically disincentivize other engineers from pointing out basic realities.
I use it basically as a cache, I create local artifacts that are fast to filter/query and easily paginate on the client (which is to say in the MCP server).
MCP doesn't serve any technical purpose. It exists for business reasons.
MCP provides a convenient packaging for tools, and generally workflows, for LLM clients.
You can debate all day whether bringing your own tools is a good thing vs giving the LLM a generic shell tool and an API doc and letting it run curls. I like tools because it brings reproducibility.
MCP is really just a json RPC spec. json RPC can take place over a variety of transports and under a variety of auth mechanisms- MCP doesn't need to spec a transport or auth mechanism.
I totally agree with everybody that most MCP clients are half assed and remote MCP is not well supported, but that's a business problem
Every LLM tool today either runs locally (cursor, zed, IDEs, etc.) so can run MCP servers as local processses w/ no auth, or is run by an LLM provider where interoperability is not a business priority. So the remote MCP story has not been fleshed out
Lol yeah, lots going on that will hopefully make it better though.
https://github.com/modelcontextprotocol/modelcontextprotocol... https://github.com/modelcontextprotocol/modelcontextprotocol... https://github.com/modelcontextprotocol/modelcontextprotocol... https://aaronparecki.com/2025/05/12/27/enterprise-ready-mcp https://github.com/modelcontextprotocol/modelcontextprotocol... https://www.okta.com/newsroom/press-releases/okta-introduces... https://github.com/modelcontextprotocol/ext-auth/blob/main/s... https://github.com/modelcontextprotocol/modelcontextprotocol... https://github.com/modelcontextprotocol/modelcontextprotocol... https://github.com/modelcontextprotocol/modelcontextprotocol...
[flagged]
Can you please stop posting unsubstantive/fulminatey comments? We've already asked you this multiple times:
https://news.ycombinator.com/item?id=45022004 (Aug 2025)
https://news.ycombinator.com/item?id=44396920 (June 2025)
https://news.ycombinator.com/item?id=43028401 (Feb 2025)
https://news.ycombinator.com/item?id=39337678 (Feb 2024)
You've obviously got some substantive points to make here, which is great, but indignant putdown rhetoric has a destructive effect on the threads. If you could just make your substantive points thoughtfully, we'd appreciate it.
https://news.ycombinator.com/newsguidelines.html
OK, I will tone it down.
However, it IS also a description of the current state of affairs in the MCP land. The comment threads and proposals in the MCP projects are dominated by the LLM-generated text, so it is almost impossible to keep the full picture in one's mind. LLMs made it possible to create an overwhelming amount of activity with ease.
Moreover, a lot of _code_ for the MCP servers is also AI-generated and has never been used in practice. It's easy to verify. Here are Github search results for the ProxyOAuthServerProvider that is supposed to delegate the authentication to a third-party server: https://github.com/search?q=ProxyOAuthServerProvider&type=co...
There are 215 results at the time of writing, and all but 3 of them are either forks of or LLM-fueled rewrites of the same code from the `modelcontextprotocol` repo. And one of the 3 is mine, and it doesn't quite work.
So yes, "It's just more of AI slop". Sorry. That's just a neutral description of the current state of affairs in the MCP/AI world. And yes, it's absolutely horrifying.
I don't have any problem with this argument* and if you had posted this comment originally I wouldn't have replied. The "absolutely horrifying" bit at the end is a bit beyond the pale, but not, er, absolutely horrifying.
(Btw, that makes your comment a case of the so-called rebound effect (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...) - one of the more interesting phenomena we've noticed.)
* I mean qua moderator of course. Qua reader, I have no opinion.
Yes, I'm sorry about that. I really should not write one-line comments without taking time to detail them. I will just stay silent in future in these cases.
> bit beyond the pale
Uhm... Why? It's an honest question. I thought that "horrifying" (as in "inducing horror") is a normal descriptor, not racially/sexually loaded or anything. The AI situation certainly induces real dread in me.
I did say "a bit" :) - I guess because it pattern-matches to internet rhetoric for me. By 'internet rhetoric' I mean something where the largeness/sensationalness of the claim is high and the information content is low. (Oh also, the leading "And yes" is a bit of an internet trope)
This is quite minor though; if it distracts from the main point, I'd say forget it.
I've made some contributions to the typescript-sdk and I'm part of the MCP Contributors server and can confirm, it was all vibecoded and the direction it is going is really not promising.
I'm still laughing on how the error handling for tools is done, it's just a boolean field IsError.
https://modelcontextprotocol.io/specification/2025-06-18/ser...
There is a difference between protocol error and tool usage error, makes sense you want the model to see the tool usage error, so they can correct.
I'm guessing it has a the same shape as a normal message + IsError so on the handling side you don't really have to do anything special to handle it, just proceed as normal and send the results to the LLM so it can correct if needed.
“Ok, how do we do customer auth” has become my go-to question to kill MCP projects. There is no working solution which makes any kind of enterprise exploration into the space pointless.
The initial remote MCP specification was pretty painful, but the June spec and the upcoming November spec are much more workable - MCP auth is (mostly) just OAuth now. MCP Clients are OAuth clients and can be granted access tokens and managed just like any other 3rd party app integration.
I'd love to hear more about the specific issues you're running into with the new version of the spec. (disclaimer - I work at an auth company! email in bio if you wanna chat)
Basically, I'm trying to just create a protected MCP server that works with ChatGPT. That's it. Nothing fancy.
So far, I was not able to do it. And there are no examples that I can find. It's also all complicated by the total lack of logs from ChatGPT detailing the errors.
I'll probably get there eventually and publish a blog...
ChatGPT provides a new Apps SDK that makes things easier. The MCP server does need a proper Authorization Server to do OAuth, including DCR and OIDC metadata support, but those are the best way to do what they are trying to do. Anything else I have considered would be much worse security and discovery wise.
Serious question, as I’m starting to go through this process myself -
Is it possible for the customer to provide their own bearer tokens (generated however) that the LLM can pass along to the MCP server? This was the closest to a workable security I’ve looked at. I don’t know if that is all that well supported by Chat GUI/web clients (user supplied tokens), but should be possible when calling an LLM through an API style call, right (if you add additional pass thru headers)?
The LLM doesn't intervene much actually, it just tells what tool to call. It's your MCP implementation that does the heavy lifting. So yeah you can always shove a key somewhere in your app context and pass it to the tool call. But I think the point of other comments is that the MCP protocol is kinda clueless about how to standardize that within the protocol itself.
I think an important thing to note is the MCP client is a distinct thing from the ‘LLM’ architecturally, though many LLM providers also have MCP client implementations (via their chat ui or desktop / cli implementations).
In general, I’d say it’s not a good idea to pass bearer tokens to the LLM provider and keep that to the MCP client. But your client has to be interoperable with the MCP server at the auth level, which is flakey at the moment across the ecosystem of generic MCP clients and servers as noted.
> but should be possible when calling an LLM through an API style call, right (if you add additional pass thru headers
Nope. I assumed as much and even implemented the bearer token authentication in the MCP server that I wanted to expose.
Then I tried to connect it to ChatGPT, and it turns out to NOT be supported at all. Your options are either no authentication whatsoever or OAuth with dynamic client registration. Claude at least allows the static OAuth registration (you supply client_id and client_secret).
The MCP & DCR OAuth ecosystem was immature at the start, but has really evolved and become robust. E.g., WorkOS has some really robust OAuth that can act as a standalone proxy for MCP connecting to any existing auth infrastructure.
Metadata and resource indicators are solving the rest of the problems that came with the change to OAuth spec.
It's really messy now. ChatGPT in particular makes it really hard; it turns out that Custom GPTs with actions can do pretty well, if you bridge MCP tools into actions; but setting any of these up is a pita.
The LLMs are also really bad at generating correct code for OAuth logic - there are too many conditions there, and the DCR dance is fairly complicated to get right.
Shameless plug: we're building a MCP gateway that takes in any MCP server and we do the heavy lifting to make it compatible with any client on the other end (Claude, ChatGPT - even with custom actions); as a nice bonus it gives you SSO/logs as well. https://mintmcp.com if you're interested.
Why just a gateway? Why not a serverless way to host tools?
+1 many tools can be run stateless / have state in a external db, and we have ways to support running that efficiently as well.
It looks great, but it's yet another service. I believe that the infrastructure must be as simple as possible.
Have you considered adding a stand-alone service? Perhaps using the AGPL+commercial license.
We do have self-hosted options, and are still thinking through OSS strategies. If you've suggestions on that angle, would love to learn / read more.
MCP works best for tool calling that doesn't require auth (so tools that are trusted on your own machine). The whole pitch that you should be using it for business facing tools and things that require auth is a terrible idea.
Even if you're doing local only - MCP tools can mostly be covered by simply asking Claude Code (or whatever) to use the bash equivalent.
> MCP works best for tool calling that doesn't require auth (so tools that are trusted on your own machine).
In other words, downloading random crap that runs unconfined and requires a shitty app like Claude Desktop.
BTW, Claude Desktop is ALSO an example of AI slop. It barely works, constantly just closing chats, taking 10 seconds to switch between conversations, etc.
In my case, I wanted to connect our CRM with ChatGPT and ask it to organize our customer notes. And also make this available as a service to users, so they won't have to be AI experts with subscriptions to Claude.
So where can we host simple single file MCP tools with the ease of a lambda?
Aws has agentcore
Missed opportunity to call it TRON.
Nice to see a scanner for MCP servers. Curious about audit depth: config checks only or live exploit tests and what reporting formats it supports?
I love how we now have a class of AI tools that try to catch issues created by other AI tools.
Is this to scan your own MCP servers? Does using someone else's MCP server put you at risk?
I didn't even know want an MCP server was until I noticed the annoying category in VSCode Extensions panel today. Only able to get rid of it by turning off a broad AI related flag in settings (fine by me, wish I knew it was there earlier). An hour later, I'm seeing this.
At Snyk, we've been working on this for a while. Here's our flagship open source project consolidating a lot of the MCP risk factors we've discovered over the last year or so into actionable info: https://github.com/invariantlabs-ai/mcp-scan
Missed opportunity to call it TRON.
Would you want to share how/why it's different from the submission, since you're making a comment here?
I believe one of the main differences is that our scanner looks for toxic flows between mcp endpoints regarding how they interact with one another. Unless I'm missing something, the Cisco tool does not support this.
Our research lab discovered this novel threat back in July: https://invariantlabs.ai/blog/toxic-flow-analysis and built the tooling around it. This is an extremely common type of issue that many people don't realize (basically, when you are using multiple MCP servers that individually are safe, but together can cause issues).
Was trying to remember where I had heard this org's name: https://news.ycombinator.com/item?id=42690473
This org has gone to some dubious lengths to make a name for themselves, including submitting backdoored packages to public npm repos which would exfiltrate your data and send to a Synk-controlled C&C. This included the environment, which would be sending them your username along with any envvars like git/aws/etc auth tokens.
This might give them some credibility in this space, maybe they stand a decent chance of scanning MCPs for backdoors based on their own experience in placing malicious code on other people's systems.
Was this comment meant to be in reply to https://news.ycombinator.com/item?id=45726223 ?
[dead]