Never build Permissions again. Zero-latency fine-grained authorization as a service for human, machine, and agentic identities.
This is the 4th launch from Permit.io. View more
Permit.io MCP Gateway
Launching today
MCP lets AI agents connect to your tools, but its built-in auth is limited. There's no fine-grained authorization, no governance, and no connection to your existing IdP infrastructure. Permit MCP Gateway is a zero-trust proxy that adds what's missing to any MCP server without touching its code. Swap one URL and every tool call gets OAuth authentication, Zanzibar-style authorization, consent screens, and full decision logging. No SDK to install. No agents to rewrite. Works with any MCP server.
Free Options
Launch Team / Built With
Permit.io
This is a strong problem to go after. A lot of teams are excited about MCP, but the security and authorization layer is exactly where things start getting uncomfortable once real production access is involved. The fact that this works as a proxy and does not require rewriting agents or servers makes it feel much more realistic for actual adoption.
Curious, what tends to be the biggest blocker for teams right now when they start thinking about MCP security, visibility, fine-grained control, or integration with existing identity systems?
Permit.io
@akshay_kumar_hireid Thanks — that’s exactly what we’re hearing from teams right now.
The biggest blocker usually depends on who’s driving the project.
For engineering, it’s mostly about getting around the fact that OAuth 2.1 and existing identity systems were designed for humans, not agents. Teams want MCP security without having to rewrite their agents or servers, but today’s stack makes that awkward.
For security, the bigger issue is knowing where to begin. They need visibility, fine-grained control, and governance, but they’re still figuring out how to evolve toward Agentic Zero Trust and IGA. In other words: how do you understand what an agent is allowed to do, on whose behalf, and how that maps back to existing identity systems?
That’s really the core problem we’re solving.
okay yeah this makes a lot of sense. everyone wants agents to connect to tools now, but the second you think about who approved what and what that agent is actually allowed to do, it gets serious real fast. the one url change part is probably what will make people actually try it.
curious, what’s the first reaction you get from security teams when they see this, relief or more questions?
Permit.io
@nayan_surya98 definitely a bit of both — but the first reaction is usually relief.
security teams immediately see that this is not another massive platform overhaul. the one-url change makes the experience feel approachable right away, and that lowers the barrier to actually trying it. that simplicity is a big part of the value: we worked hard to make something that is incredibly powerful under the hood, but feels almost frictionless to adopt.
then the next reaction is curiosity, because they realize this isn’t just “tool access for agents” — it’s a real security layer built for agentic systems. that’s when the questions shift to the agentic-native capabilities: agent interrogation through MCP, JIT agentic identities, fine-grained delegation, auditability, and how to enforce least privilege in a world where agents are acting dynamically.
so in practice, it’s relief first, then deeper engagement. and honestly, that’s exactly what we want: an experience that’s simple enough to get teams started quickly, but advanced enough that security leaders immediately see this is the kind of infrastructure they’re going to need as agents move into production.
@or_weis Really well put. That balance is probably the hardest part in security products, making adoption feel lightweight without making the capability feel lightweight. The one-URL change feels like a smart wedge for that.
Wilco
Agent interrogation - seems interesting but problematic, how can you trust the agent not to lie, or be coerced to lie ? How can this produce a consistent Identity?
Permit.io
@on The key point is: we do not trust the agent to tell the truth.
Interrogation is not there to “believe” the agent. It is there to extract a behavioral fingerprint from the agent’s intent as expressed at that moment. In our framing, even if the agent lies, the pattern of answers is still useful: it gives you a stable enough signature to say “this is the same agentic identity within threshold” versus “something changed here.” That is why the model is not “trust the answer,” but “fingerprint the intent.”
That is also why coercion is actually part of the design, not a contradiction to it. If the agent gets prompt-injected, confused, or coerced into a materially different intent, its fingerprint should change. When that happens, the identity breaks, and you renegotiate consent or block access. In other words, instability is a detection signal. It is a feature, not a bug.
So how do you get a consistent identity out of something non-deterministic? By not relying on a single static property like hostname, model version, or token. Instead, the identity is composed from three things:
the human delegator identity,
the consent boundary the human granted,
the agent’s intent fingerprint derived through interrogation.
That combination is what persists through time, even when the underlying model, runtime, or context shifts.
And then we do the second crucial thing: the agent gets zero standing permissions. We do not give it broad credentials and hope for the best. Every time it tries to act, the gateway revalidates the identity and derives only the permissions needed just in time, based on the relationship to the human and the current policy. So even if the agent is imperfect, the blast radius stays small.
So the clean answer is:
We don’t trust the agent not to lie.
We trust a control plane that:
fingerprints its intent,
detects when that fingerprint changes,
revalidates it on each interaction,
and never gives it persistent credentials in the first place.
That is how you get a consistent identity out of an inconsistent actor.
Permit.io
Hey PH ! Or Weis here, co-founder and CEO of Permit.io. Fourth time launching here, and always great to be back.
We’ve been building in authorization for years, and the shift we’re seeing with MCP feels like one of those rare infrastructure moments. Every protocol starts a little messy. HTTP was messy. TCP/IP was messy. MCP is no exception. But it is quickly becoming the connective tissue between AI agents and enterprise systems, which makes it the right place to enforce identity, trust, and governance.
Most of the market looks at MCP and asks, “How do I push this through my existing stack?” We think that is the wrong question.
Agents are not service accounts with better branding. They need a new kind of identity: dynamic, delegated, auditable, and revocable in real time.
That is why we built Permit MCP Gateway.
Permit MCP Gateway is a drop-in trust layer for MCP. It helps teams secure AI agents connecting to tools and enterprise systems with fine-grained authorization, consent, auditability, and runtime enforcement — without rewriting their stack.
A few things we think matter:
fine-grained permissions for agent actions
delegated access on behalf of users
audit logs for every tool call
zero-standing-privilege approach
built on Permit, so controls can extend deeper into APIs, services, and data for defense in depth
This is a very natural evolution for us. Permit started with application authorization, and now we’re bringing the same philosophy into the AI era.
If you’re thinking about how to bring MCP into your organization without turning your systems into open desert, we’d love to talk.
We’re here all day — would love your feedback, questions, and skepticism.
Hey Product Hunt! David here, Solutions Engineer at Permit.io.
We just published two walkthroughs showing the MCP Gateway in action:
Enforce per-user trust levels on Linear's MCP (Developer vs PM access): https://docs.permit.io/permit-mcp-gateway/demos/linear-mcp-gateway
Gate an n8n automation workflow with real-time trust controls: https://docs.permit.io/permit-mcp-gateway/demos/n8n-linear-mcp-gateway
No changes to the underlying MCP servers — just drop the Gateway in front and control who (or what) can do what. Both demos take just a few minutes to set up. Would love to hear what MCPs you'd want to see demoed next!