This tracks exactly with why I built MCP Gateway — the root
causes you listed (absent authentication, blind trust, no
access control) are all things the protocol leaves up to
each implementer to solve independently.
OAuth 2.1 + PKCE, Microsoft Entra SSO, per-tool RBAC,
full audit trail on every tool call. The gateway sits in
front of your tools so auth and access control are solved
once at the platform level rather than per-server.
Self-hostable with Docker.
First open source project — built it after seeing exactly
the pattern described here in enterprise MCP deployments.
The gateway approach (OAuth + RBAC) solves the perimeter problem — who can connect. protect-mcp solves a different layer — what can they do once connected, and how do you prove it.
It wraps any MCP server as a stdio proxy. Per-tool policies (block, rate-limit, require human approval). Every decision gets an Ed25519-signed receipt that's verifiable offline — no callbacks, no accounts.
The two layers stack: your gateway authenticates the caller, protect-mcp constrains which tools they can call and signs the evidence.
Really well thought out — anchoring every policy rule to a real
incident (Clinejection, the terraform destroy incident) is a
smart way to make governance feel necessary rather than
bureaucratic. The observe mode is a good adoption path too.
The problem you're solving is the developer workstation side —
stopping an agent from breaking the developer's own environment.
I've been working on the complementary server side: controlling
which users in an org can access which MCP tools, with full
audit trail.
OAuth 2.1 + PKCE, Microsoft Entra SSO with group-based role
assignment, per-tool RBAC, multi-tenant isolation. The two
approaches could actually stack — Vectimus at the workstation,
MCP Gateway at the server.
One question: how does Vectimus handle the case where the MCP
server itself is legitimate but the tool parameters contain
injected instructions? The Clinejection attack was a malicious
server, but the harder problem is a legitimate server returning
poisoned data that the agent then acts on.
Vectimus does input inspection on approved MCP servers, but it can only catch known bad patterns too. It does not try to solve prompt injections or if a legitimate MCP server was comprimised and returned poisoned outputs. I do plan to add additional post took hooks in future that can scan the MCP server output too.
You're project is interesting. It's a bit of an MCP proxy in a way, moreso than Azure API Management, yours seems to give more functionality. I will definitely take a look.
https://github.com/PanosSalt/MCP-Gateway
OAuth 2.1 + PKCE, Microsoft Entra SSO, per-tool RBAC, full audit trail on every tool call. The gateway sits in front of your tools so auth and access control are solved once at the platform level rather than per-server. Self-hostable with Docker.
First open source project — built it after seeing exactly the pattern described here in enterprise MCP deployments.
reply