Show HN: VellaVeto — blocks unsafe MCP tool calls by default(github.com)
github.com
Show HN: VellaVeto — blocks unsafe MCP tool calls by default
https://github.com/paolovella/vellaveto
3 comments
The fail-closed approach is the right default.
One thing I'd add to the attack classes you're
considering: prompt injection via filesystem reads —
an attacker can craft a file that, when read by the
agent, injects instructions into the tool-call chain.
We solved a similar boundary problem by signing all outputs with HMAC-SHA256 so downstream consumers can verify the response wasn't modified after the tool-call boundary. Not a replacement for your approach but complementary — input validation + output signing covers both ends.
Is the MCPSEC benchmark public yet?
We solved a similar boundary problem by signing all outputs with HMAC-SHA256 so downstream consumers can verify the response wasn't modified after the tool-call boundary. Not a replacement for your approach but complementary — input validation + output signing covers both ends.
Is the MCPSEC benchmark public yet?
VellaVeto is a fail-closed gateway between an AI agent and its MCP tools. Every tool call is evaluated before execution; if evaluation fails for any reason, the call is denied.
Concrete example: under shield mode, a filesystem server trying to read ~/.ssh/id_rsa is denied by default. A list_files /tmp call from the same server is allowed.
What it does not solve: prompt injection, model-level jailbreaks, or supply-chain attacks in server packages. It only controls what crosses the tool-call boundary.
Since March, I added three zero-config protection levels, topology discovery, tamper-evident audit, Consumer Shield, and MCPSEC, an open benchmark for MCP gateways.
The feedback I’d most like:
Is the tool-call boundary the right place to enforce MCP security? Are the MCPSEC attack classes sensible? What important attack classes am I still missing?