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