Permit MCP Gateway Overview
Permit MCP Gateway is an enforcement proxy between MCP clients and MCP servers. It authenticates users, authorizes agent tool calls against fine-grained policy, collects explicit consent, and logs every decision — all without modifying your existing MCP servers or AI tools.
The Model Context Protocol (MCP) is an open standard that lets AI tools connect to external services. MCP clients are AI tools like Cursor, Claude Desktop, VS Code, and Claude Code. MCP servers are the services they connect to — GitHub, Linear, Slack, Jira, and hundreds more. Permit MCP Gateway sits between the two, adding security controls to those connections.
The Problem
Enterprise adoption of AI agents is accelerating, but security controls have not kept pace:
- No visibility — AI agents interact with production systems, but most organizations cannot answer basic questions: which agents are accessing which systems? What data are they reading or modifying? Who authorized those actions?
- No per-tool control — traditional API gateways and IAM tools were not designed for MCP. They do not model the human-to-agent delegation chain or provide per-tool access controls for autonomous agents.
- Shadow MCP connections — teams connect MCP servers in minutes, creating unvetted access paths to sensitive systems that bypass standard review.
- Compliance gaps — unchecked agent activity risks violating data-privacy regulations (GDPR, HIPAA) and weakening audit posture (SOC 2). When agents act on behalf of humans, regulators expect the same traceability that applies to human actions.
- Privilege accumulation — agents often run with overly broad access because there is no practical way to apply least privilege at the tool level.
How Permit and Permit MCP Gateway Are Connected
Permit MCP Gateway is built on top of Permit.io. Permit acts as the control plane and default data plane for every gateway instance — it is where policies are defined, authorization decisions are evaluated, and audit logs are stored.
| Component | Role | Dashboard |
|---|---|---|
| Permit.io | Control plane and policy engine. Manages the authorization model, evaluates every permit.check() call, and stores audit logs. | app.permit.io |
| Permit MCP Gateway | Enforcement layer. Proxies MCP traffic, applies authentication and consent, and calls Permit for every authorization decision. The hosted SaaS gateway runs under *.agent.security subdomains. | app.agent.security |
Every Host Is a Permit Environment
Each gateway host (e.g., acme-brave-coral-37.agent.security) maps 1:1 to a Permit environment. This means:
- MCP servers imported into a host become resource types in the linked Permit environment
- Tools become actions on those resources
- Users and agents are created as Permit users with role assignments in that environment
- Trust levels map to Permit roles with hierarchical permissions
- Trust ceilings are enforced using Permit relations and derived roles (ReBAC)
Because the gateway builds on standard Permit primitives, you get the full power of Permit's policy engine:
- RBAC, ABAC, and ReBAC policy models are all available
- Real-time policy updates via OPAL — changes to trust levels, access grants, or revocations take effect on the next tool call with no restart
- Audit logs for every authorization decision, accessible via the Permit dashboard and API
- Policy-as-code — policies can be managed via the Permit UI, API, or Terraform provider
Two Dashboards, One System
You will work with two dashboards:
- app.permit.io — the Permit control plane. Use this for deep policy inspection, audit log analysis, viewing resource schemas, role assignments, and advanced policy configuration. This is where the authorization model lives.
- app.agent.security — the gateway dashboard. Use this for day-to-day gateway management: creating hosts, importing MCP servers, granting user access, configuring authentication, and monitoring agent activity.
Both dashboards show the same underlying authorization data. The gateway dashboard provides an MCP-focused view optimized for managing hosts, servers, and consent flows. The Permit dashboard provides the full policy view, including derived role rules, raw audit log entries, and resource schemas.
For a detailed walkthrough of the policy model and how gateway concepts map to Permit primitives, see Permit.io Integration.
How the Gateway Works
The gateway operates as a transparent proxy. Adopting it requires a single configuration change — pointing your MCP client at the gateway URL instead of directly at the upstream MCP server.
Setup (Admin)
- Create a host — a named gateway instance with its own subdomain, policies, and users
- Import MCP servers — connect to upstream servers, discover their tools, and classify each tool by risk level
- Grant user access — specify which users can connect to which MCP servers and set a per-user trust ceiling
Connection (User)
- Connect and authenticate — the MCP client connects to the gateway URL; the user signs in via the configured authentication method (SSO, OAuth, email)
- Consent — the user selects an MCP server, reviews available tools, and chooses a trust level for their agent (up to the admin-defined ceiling)
- Use tools — the MCP client operates normally; allowed tool calls pass through to the upstream server, and denied calls return a clear permission error
Runtime (Every Tool Call)
- Authenticate — the gateway verifies the agent's JWT and identifies the calling agent and its authorizing human
- Authorize — the gateway checks Permit.io policy: "Can this agent call this tool on this MCP server?"
- Audit — the authorization decision (allow or deny) is logged with full context: agent identity, human identity, tool name, MCP server, timestamp, and result
All of this is transparent to the upstream MCP server, which receives proxied requests with the user's upstream credentials as usual.
Key Capabilities
Authentication
Users authenticate through the consent flow before any agent can access MCP servers. Each gateway host supports configurable authentication methods:
- Email/password, email OTP, passkeys
- Social OAuth (Google, GitHub, Microsoft)
- Enterprise SSO (SAML 2.0, OIDC)
- Domain restrictions and force-redirect for streamlined enterprise sign-in
Authorization
Every tool call is authorized in real time against fine-grained policy:
- Trust-level classification — tools are auto-classified as low (read), medium (write), or high (destructive) during import, with manual overrides available
- Per-user trust ceilings — admins set the maximum trust level each user can grant their agents
- Consent-based delegation — users choose how much access to grant, within admin-defined boundaries
- Relationship-based access control (ReBAC) — authorization flows through a human → agent → server chain, enforced by Permit.io using a
min()trust ceiling
Consent
A one-time consent flow ensures that humans explicitly authorize agent access:
- Users see which tools are available at each trust level before granting access
- Trust levels above the admin ceiling are disabled
- Consent is enforced at three layers: UI, API validation, and policy engine
- Sessions persist across client restarts, with configurable expiry (30-day inactivity / 90-day absolute)
Audit
Every authorization decision is logged automatically:
- Logged in both the Permit MCP Gateway dashboard and the Permit.io dashboard
- Each entry includes: agent identity, human identity, tool name, MCP server, timestamp, and allow/deny decision
- Filterable by agent, user, server, action, or decision
- Supports compliance reporting, incident investigation, and access pattern analysis
Security and Trust Model
This section describes what Permit MCP Gateway enforces, what it logs, and what remains the responsibility of other components in your environment.
What the Gateway Sees
| Data | Description |
|---|---|
| User identity | Authenticated via the consent flow (SSO, OAuth, email) |
| Agent identity | The MCP client (e.g., Cursor, Claude Desktop) identified by its OAuth client ID |
| Tool calls | The name and parameters of every call_tool request |
| MCP server identity | Which upstream server the call is destined for |
| Authorization decisions | Whether each tool call was allowed or denied, and why |
What the Gateway Enforces
- Authentication — users must sign in before any agent can access MCP servers
- Authorization — every tool call is checked against policy; denied calls are blocked before reaching the upstream server
- Trust ceilings — agents cannot exceed the trust level granted by the human, and humans cannot exceed the ceiling set by the admin
- Consent — agents only receive access after the human completes the consent flow
- Session management — sessions expire after inactivity or absolute time limits, and can be revoked immediately by admins
- Rate limiting — per-IP rate limits protect authentication, OAuth registration, and MCP endpoints from abuse. Requests exceeding thresholds receive HTTP 429 with a JSON error body. See Architecture: Rate Limiting & WAF for details
What the Gateway Logs
- Every
call_toolauthorization decision (allow or deny) with full context - User sign-in and consent events
- Agent-to-server session creation and expiry
- All logs are available via the Permit MCP Gateway dashboard and the Permit.io audit log API
Hosted vs. Customer-Controlled Deployment
| Aspect | Hosted | Customer-Controlled |
|---|---|---|
| Gateway location | Managed by Permit at *.agent.security | Runs in your environment (VPC, on-prem) |
| Policy decisions | Evaluated by Permit.io cloud PDP | Can be evaluated by a local PDP |
| Data in transit | MCP traffic flows through the hosted gateway | MCP traffic stays within your network |
| Best for | Fast adoption, SaaS workloads, evaluation | Regulated environments, data residency requirements |
Customer-controlled deployment is available for enterprise plans. Contact us for architecture details. The hosted deployment is available for all plans and is the recommended starting point.
What Risks the Gateway Mitigates
- Unauthorized tool access — agents can only call tools they are explicitly permitted to use
- Privilege escalation — the
min()trust ceiling prevents agents from exceeding admin-defined boundaries - Invisible agent activity — every tool call is logged and traceable to a specific human and agent
- Unvetted MCP connections — by default, users can only connect to admin-approved MCP servers
- Credential exposure to agents — upstream OAuth tokens are managed by the gateway, not exposed to MCP clients
What the Gateway Does Not Fully Solve
The gateway enforces access control and audit at the MCP protocol layer. These areas remain the responsibility of the surrounding environment:
- Upstream server security — the gateway does not validate what the upstream MCP server does with authorized requests. Server-side input validation, data access controls, and business logic remain the server's responsibility.
- Prompt injection and adversarial inputs — the gateway authorizes tool calls based on identity and policy, not on the content or intent of prompts. Defending against prompt injection is the responsibility of the MCP client and LLM layer.
- Data classification — the gateway classifies tools by risk level (read/write/destructive) based on naming patterns. It does not inspect the data returned by tool calls or classify data sensitivity.
- Network-level controls — the gateway operates at the application layer. Network segmentation, firewall rules, and transport security for upstream connections are managed separately.
How It Compares to Existing Tools
| Approach | Limitation for MCP use cases |
|---|---|
| API gateways (Kong, Apigee, etc.) | Designed for REST/gRPC APIs, not MCP protocol. No model of human-to-agent delegation or per-tool trust levels. |
| IAM platforms (Okta, Azure AD, etc.) | Handle user authentication but do not enforce per-tool authorization for autonomous agents or model consent-based delegation. |
| Manual MCP server access | No authentication, no authorization, no audit. Agents connect directly with whatever credentials are available. |
| Permit MCP Gateway | Purpose-built for MCP: identity-aware per-tool authorization, human-to-agent trust delegation, consent, and audit in one enforcement point. |
Use Cases
Securely Consume MCP Servers (Internal)
Your team uses Cursor, Claude, VS Code, or internal agents to interact with MCP servers like GitHub, Linear, Slack, and Jira. Permit MCP Gateway sits between your agents and those servers, enforcing per-user access control, trust-level policies, and logging every tool call.
Typical scenario: An engineering team connects Cursor to GitHub and Linear through the gateway. Admins grant developers read/write access but restrict destructive operations. Every tool call is logged, and new MCP servers require admin approval before anyone can connect.
Provide Secure MCP Servers to Customers
You build or host MCP servers that your customers connect to. Permit MCP Gateway adds authentication, per-customer authorization, consent, and audit — so each customer's agents only access what they are permitted to, with full traceability.
Typical scenario: A SaaS platform exposes its API as an MCP server. Enterprise customers connect their AI agents through the gateway with SSO, per-user trust levels, and isolated audit trails per customer.
When to Use Permit MCP Gateway
Permit MCP Gateway is especially valuable when:
- You already use or plan to use MCP from tools like Cursor, Claude, VS Code, or internal agents
- You need per-user or per-agent controls over which tools can be called
- You need a central audit trail of all agent actions across MCP servers
- You want consent or approval workflows for sensitive operations
- You do not want every MCP server trusted equally — different servers and tools need different risk controls
- You are building MCP servers to be consumed securely by your customers
- You want to enable enterprise workflows where agents interact with sensitive systems or data
If you are not yet using MCP, or if your agents do not interact with external tools or data, you may not need the gateway today — but it is designed to be adopted incrementally as your MCP usage grows.
Deployment Options
Hosted Gateway (SaaS)
The fastest way to get started. Each gateway host runs under a subdomain of agent.security (e.g., acme-brave-coral-37.agent.security), with TLS, session management, and audit logging included. Permit.io provides both the control plane (app.permit.io) and the hosted data plane (PDP) that evaluates authorization decisions.
- No infrastructure to manage — Permit hosts the gateway, consent service, and policy decision point
- Minutes to first value — create a host, import a server, connect a client
- Isolated per host — each host gets its own subdomain, users, policies, and sessions
Customer-Controlled Deployment
For organizations that require enforcement within their own network boundary, Permit offers deployment options where the gateway and policy decision point (PDP) run in your environment. Permit.io still serves as the control plane, but authorization decisions and MCP traffic stay within your network.
Customer-controlled deployment is available for enterprise plans. Contact us or schedule a demo for architecture details and availability.
Ready to get started? Follow the Getting Started Guide to set up your first gateway in minutes.