Show HN: Permit MCP Gateway – Fine-Grained Authorization and IGA for MCP (opens in new tab)

(permit.io)

2 pointsgemanor7d ago2 comments

Hi HN, Gabriel, Co-Founder at Permit.io. We're releasing Permit MCP Gateway today, an authorization proxy for MCP servers.

TL;DR - we built an MCP Gateway that developers love and CISOs trust. Watch more[0]

Now, after your little hate on using fancy copy on HN, to the real thing:

MCP is in a strange place. Developers are debating whether it's overcomplicated compared to CLIs or skills files. Meanwhile, enterprises are adopting it by default because every agentic system that acts on your behalf, Cursor, Claude, Copilot, internal agents, needs a stable infrastructure for connecting to tools. MCP is the only standardized protocol for AI proactively acting on internal systems. Whether you love the protocol or not, it's where enforcement needs to happen.

We build authorization infrastructure (OPA-based, Zanzibar-style ReBAC, sub-10ms decisions). As our customers adopted AI tooling, MCP authorization became the most common gap they hit. The protocol has authentication (OAuth 2.1 in the latest spec), but no authorization layer. Once an agent authenticates, it can call any tool on the server. There's no per-tool policy, no way to scope what an agent can do based on who authorized it, no consent flow where a human explicitly approves what an agent can access, and no audit trail linking tool calls back to a human decision.

So we built a proxy that adds what's missing. You point it at any MCP server, change one URL in your client config, and every tool call gets evaluated against fine-grained policy before reaching the upstream server.

What the gateway does:

- Sits between MCP clients (Claude, Cursor, VS Code, custom agents) and upstream MCP servers - Auto-generates authorization policies per tool when you connect a new server - Evaluates every tools/call request against policy in real time - Tracks the delegation chain: which human authorized which agent, at what trust level - Enforces trust ceilings so an agent can't exceed what its human granted - Human-in-the-loop consent flows for sensitive tool access (visual editor, white-label support) - Logs every allow/deny decision with full context

The policy engine underneath uses OPA and a Zanzibar-style relationship graph (ReBAC). It supports RBAC, ABAC, and ReBAC. This is the same engine we've been running in production at companies like Tesla, Cisco, and Intel for application-level authorization. Extending it to MCP tool calls was a natural fit because the trust model maps directly: human -> agent -> server -> tool is just another relationship graph.

Tech details: the gateway speaks MCP natively (SSE transport, working on Streamable HTTP). It proxies the full MCP lifecycle including tool discovery, so it can inspect available tools and generate contextual policies on connection. Authorization decisions are evaluated by Permit's PDP (policy decision point) with sub-10ms latency. You can run it hosted (*.agent.security) or deploy the PDP in your own VPC for data residency.

Docs: https://docs.permit.io/permit-mcp-gateway/overview Architecture: https://docs.permit.io/permit-mcp-gateway/architecture Try it: https://app.agent.security

Happy to answer questions about the authorization model, the policy engine, the trust delegation approach, or hear how others are solving this.

[0] youtube.com/watch?v=plqcg31hsk8

2 comments

michaelksaleme3d ago

The authorization proxy approach makes sense. Putting enforcement at the gateway layer means you don't need cooperation from individual MCP servers, which is the right pragmatic choice.

Two questions from someone who's been testing MCP security at the protocol level:

1. *Capability escalation during initialize:* MCP's handshake lets the client declare capabilities it supports. A malicious client can claim capabilities (such as "sampling") that expose additional attack surface on the server. Does the gateway evaluate client-declared capabilities against policy, or does it only gate tool calls? The initialize handshake is the first place most MCP deployments are vulnerable, and it happens before any tool call.

2. *Protocol version downgrade:* MCP doesn't enforce a minimum version. A client can request an older protocol version that may lack security features present in newer versions. If the gateway sits between client and server, does it enforce a minimum protocol version, or pass through whatever the client negotiates?

The trust delegation chain (human -> agent -> server -> tool) is the right mental model. The piece I'd love to see addressed next is temporal scope - "this human authorized this agent to use this tool for this session" vs. "this human authorized this agent indefinitely." NIST's NCCoE concept paper on agent identity (Feb 2026) specifically calls out continuous authorization as an open gap, and session-scoped trust ceilings would be a natural fit for the ReBAC model.

devashishjadhav6d ago

The authorization gap you're describing is real but I think there's a layer missing even before the gateway the MCP server itself. If the tool schema is compromised or the server is a trojanized fork (there's an active thread about this today), a gateway that enforces policy on tool calls is still trusting the server's self-reported tool definitions.

Provenance at the server level knowing the binary you're running was signed by the original author seems like a necessary complement to runtime authorization. Has Permit thought about integrating with any signing or attestation layer, or is the assumption that server integrity is out of scope?

1 more reply

j / k navigate · click thread line to collapse