23 ms·
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 proto
by salterisp 6mo 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 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.
- Xiaoher-C 6mo ago[dead]
- globalchatads 5mo ago[dead]
- tomjwxf 6mo agoThe 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. npx protect-mcp -- node your-server.js MIT licensed. The receipts protocol has an IETF Internet-Draft: https://datatracker.ietf.org/doc/draft-farley-acta-signed-receipts/ https://datatracker.ietf.org/doc/draft-farley-acta-signed-re... npm: https://npmjs.com/package/protect-mcp https://npmjs.com/package/protect-mcp
- willamhou 6mo ago[dead]