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.
“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 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.
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.
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.
[+] [-] tsouth|4 months ago|reply
In general, the only way to make sure MCPs are safe is to limit which connections are made in an enterprise setting
[+] [-] electric_muse|4 months ago|reply
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.
[+] [-] cyberax|4 months ago|reply
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.
[+] [-] fasbiner|4 months ago|reply
[+] [-] zingababba|4 months ago|reply
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...
[+] [-] dorkypunk|4 months ago|reply
https://modelcontextprotocol.io/specification/2025-06-18/ser...
[+] [-] bootsmann|4 months ago|reply
[+] [-] tsouth|4 months ago|reply
Metadata and resource indicators are solving the rest of the problems that came with the change to OAuth spec.
[+] [-] jngiam1|4 months ago|reply
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.
[+] [-] throwaway314155|4 months ago|reply
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.
[+] [-] oezi|4 months ago|reply
[+] [-] kgwxd|4 months ago|reply
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.
[+] [-] spiritplumber|4 months ago|reply
[+] [-] Ryan07|4 months ago|reply
[+] [-] AbstractH24|4 months ago|reply
[+] [-] unknown|4 months ago|reply
[deleted]
[+] [-] unknown|4 months ago|reply
[deleted]
[+] [-] rdegges|4 months ago|reply
[+] [-] spiritplumber|4 months ago|reply
[+] [-] embedding-shape|4 months ago|reply
[+] [-] unknown|4 months ago|reply
[deleted]
[+] [-] luma|4 months ago|reply
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.
[+] [-] raesene9|4 months ago|reply
[+] [-] unknown|4 months ago|reply
[deleted]
[+] [-] seivan|4 months ago|reply
[deleted]