For many years I was feeling my skills and my time were wasted on one-off queries. Requests were coming from everywhere, slack, teams, tickets. At some point I decided that it would be better to build the tool that will save me time. So after studying the last months about AI in general and text to sql concepts more specifically I decided to build Savvina - my daughter's name. Privacy was my...
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.
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.
https://github.com/PanosSalt/MCP-Gateway
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.