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.

New to MCP?

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-pink-panda-6942.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)

1. Create a host — a named gateway instance with its own subdomain, policies, and users
2. Import MCP servers — connect to upstream servers, discover their tools, and classify each tool by risk level
3. Grant user access — specify which users can connect to which MCP servers and set a per-user trust ceiling

Connection (User)

4. Connect and authenticate — the MCP client connects to the gateway URL; the user signs in via the configured authentication method (SSO, OAuth, email)
5. Consent — the user selects an MCP server, reviews available tools, and chooses a trust level for their agent (up to the admin-defined ceiling)
6. 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)

7. Authenticate — the gateway verifies the agent's JWT and identifies the calling agent and its authorizing human
8. Authorize — the gateway checks Permit.io policy: "Can this agent call this tool on this MCP server?"
9. 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

What the Gateway Logs

• Every call_tool authorization 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

note

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.

---

Ready to get started? Follow the Getting Started Guide to set up your first gateway in minutes.