4 ms·
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 l
by rdegges 11mo ago
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 https://github.com/invariantlabs-ai/mcp-scan
- embedding-shape 11mo agoWould you want to share how/why it's different from the submission, since you're making a comment here?
- rdegges 11mo agoI 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 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).
- spiritplumber 11mo agoMissed opportunity to call it TRON. 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.
- deleted 11mo ago[deleted]