[HN Gopher] Show HN: MCP Security Suite
___________________________________________________________________
Show HN: MCP Security Suite
Hi HN! We kept seeing devs get pwned through MCP tools in ways
that security scanners completely miss. So we built an open-source
analyzer to catch these attacks. Our first OSS by Mighty team. The
problem: At Defcon, we saw MCP exploits with 100% success rate
against Claude and Llama. Three attack patterns: Hidden Unicode in
"error messages" - Paste a colleague's error into Claude, your SSH
keys get exfiltrated Trusted tool updates - That database tool
you've used for months? Last week's update added credential theft
Tool redefinition - Malicious tool redefines "deploy to prod" to
run attacker's script Traditional scanners (CodeQL, SonarQube)
catch <15% of these. They're looking for SQLi, not prompt
injections hidden in tool descriptions. What we built: git clone
https://github.com/NineSunsInc/mighty-security python
analyzers/comprehensive_mcp_analyzer.py /path/to/your/mcp/tool
Scans for prompt injection, credential exfil, suspicious updates,
tool shadowing. Runtime wrapper adds <10ms overhead. Fully local,
no telemetry. Why this matters: 43% of MCP tools have command
injection vulns. GitHub's own MCP server was exploitable. We found
Fortune 500s running database-connected MCP tools that hadn't been
audited since installation. We went from paranoid code review to
"AI said it works" in 18 months. The magic is real, but so are the
vulnerabilities. Demo:
https://www.loom.com/share/e830c56d39254a788776358c5b03fdc3
GitHub: https://github.com/NineSunsInc/mighty-security Would love
feedback - what MCP security issues have you seen?
Author : jodoking
Score : 15 points
Date : 2025-08-14 20:01 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Munam wrote:
| Helped to build this out a little bit. Was really cool to get to
| play with Cerberus for the first time as well.
|
| I'm really interested in learning more about how devs integrate
| MCP security into their routine code evals.
|
| I think there's a big opportunity as a space to get tools like
| this into CI/CD pipelines and workflows.
|
| Happy to answer any questions and happy to hear any feedback!
|
| Thanks for checking it out :)
| jodoking wrote:
| Appreciate the interest and the first comments man. We like how
| fast Cerebras is and its importance to making the scanning
| fast! Yeah we have thought about this being part of dev
| workflow via Github Actions and locally for the dev environment
| too. Love to hear what you are building!
| IMAYousaf wrote:
| This is definitely valuable. I started paying attention to MCP
| security vulnerabilities largely because of Defcon. I believe
| that they largely focused on Agentic Security as a theme this
| time around.
|
| It's a bit mind blowing how we've simply accepted non-technical
| people within orgs in particular executing code to "automate
| their tasks" without the same level of rigor that normal code
| reviews go through. Definitely think that this is a cultural
| issue that we must fix.
|
| And these MCP vulnerabilities in particular seem much scarier
| because almost all MCP tools require an insane amount of
| permissions.
| jodoking wrote:
| I know right? I mean the timing is great. I love MCP but cant
| stand how unsafe it is. I think there are greatness ahead if we
| are able to fix this security issue. This was made around the
| idea to be as seamless as possible, as we built a dashboard,
| drop in a GH project MCP server link, and have a local DB to
| show what you ran. We have more great things ahead. But give it
| a try and let us know what you think!
| jelambs wrote:
| this is super interesting! MCP is really exciting in terms of
| what it can unlock for agent use cases, but still the wild west
| in terms of security. I was on a panel discussion yesterday where
| this topic came up, basically how do you trust the use of AI
| tools when so much is still unknown. I think the the idea of
| using something open source and tool agnostic is appealing, the
| landscape is evolving so fast that horizontal solutions like this
| feel valuable. Although I wish clients, anthropic, cursor, etc
| would build more protections in too so that we didn't have to
| spend so much time thinking about this. but they've barely
| implemented remote mcp support so I think we have a ways to go.
| ripley12 wrote:
| I work in this space and I was not able to understand how this
| project works in a couple minutes. The README feels LLM-
| generated. I think you're supposed to point this at your MCP
| server's _code_ and not the server itself, is that right?
| simonw wrote:
| I found this file full of regular expressions:
| https://github.com/NineSunsInc/mighty-security/blob/28666b36...
|
| And this with prompts: https://github.com/NineSunsInc/mighty-
| security/blob/89e4b319...
|
| Are you running any other tests that I missed?
| simonw wrote:
| > Would love feedback - what MCP security issues have you seen?
|
| For me the number one problem with MCP security is the lethal
| trifecta - the fact that it's so easy to combine MCPs from
| different vendors (or even from the same vectors) that provide
| exposure to potentially untrusted/malicious instructions in a way
| that can then trigger exfiltration of private data.
|
| https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
|
| https://simonwillison.net/2025/Aug/9/bay-area-ai/
|
| I don't know how we can solve this with more technology - it
| seems to me to be baked into the very concept of how MCP works.
| tptacek wrote:
| I'm going to pick a fight on this one; I think you know I'm a
| fan, so take this in the spirit I intend+.
|
| My contention is that "lethal trifecta" is the AI equivalent of
| self-XSS. It's not apparent yet, because all this stuff is just
| months old, but a year from now we'll be floored by the fact
| that people just aimed Cursor or Claude Code at a prod
| database.
|
| To my lights, the core security issue with tool/function
| calling in agents isn't MCP; it's context hygiene. Because
| people aren't writing their own agents, they're convinced that
| the single-visible-context-window idiom of tools like Cursor
| are just how these systems work. But a context is just a list
| of strings. You can have as any of them in an agent as you
| want.
|
| Once you've got untrusted data hitting one context window, and
| sensitive tool calls isolated in another context window, the
| problem of securing the system isn't much different than it is
| with a traditional web application; some deterministic code
| that a human reviewed and pentested mediates between those
| contexts, transforming untrusted inputs into trustable commands
| for the sensitive context.
|
| That's not a trivial task, but it's _the same_ task as we do
| now when, for instance, we need to generate a PDF invoice in an
| invoicing application. Pentesters find vulnerabilities in those
| apps! But it 's not a news story when it happens, so much.
|
| + _More a note for other people who might thing I 'm being
| irritable. :)_
| sharathr wrote:
| Looks like Ramparts which solves these issues and is written in
| fast RUST instead of python.
| https://github.com/getjavelin/ramparts
___________________________________________________________________
(page generated 2025-08-14 23:00 UTC)