[rdegges]

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

[spiritplumber]

Missed 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.

[embedding-shape]

Would you want to share how/why it's different from the submission, since you're making a comment here?

[rdegges]

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).