salterisp

Joined 7 months ago

Karma

Submissions

Member since

Mar 19

View on Hacker News

Recent submissions

Show HN: After years as data engineer, I built the tool I wish my colleagues had

2 salterisp 4 months ago 0 comments

Comment · 7 months ago

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.

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.

Comment · 7 months ago

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.

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.