Show HN: MCP Gateway – Zero-Trust Access to MCP Tool Servers(github.com)
github.com
Show HN: MCP Gateway – Zero-Trust Access to MCP Tool Servers
https://github.com/openziti/mcp-gateway
3 comments
Gateways and signatures solve different problems. A gateway controls access; a signature lets the server verify what request was actually sent. That matters for replay, tamper, and forgery cases after the request passes the edge.
We've been using per-tool-call Ed25519 receipts for this in MCP flows. Verification happens directly in the server handler instead of adding another proxy hop. You can also add a server co-signature if you want proof of what the server received and responded.
We've been using per-tool-call Ed25519 receipts for this in MCP flows. Verification happens directly in the server handler instead of adding another proxy hop. You can also add a server co-signature if you want proof of what the server received and responded.
This happens in the OpenZiti layer for mcp-gateway. The overlay has strong identity and end-to-end encryption. So by simply wrapping any standard MCP server with mcp-gateway, you've got all of that and more, without having to change your implementation.
mcp-bridge wraps any stdio MCP server in one command and shares it over a zrok/OpenZiti overlay. mcp-gateway aggregates multiple backends... local stdio servers and remote shares... into a single connection with a unified, namespaced tool registry. Permission filtering removes tools from the schema entirely... they're not checked at runtime, they're gone from the registry. No listening ports, no VPN, no port forwarding. Your MCP server doesn't change.
Go, Apache 2.0, single binaries, part of the OpenZiti project. Works seamlessly with the llm-gateway I introduced a couple of weeks ago.