Permit MCP Gateway overview
Learn how Permit MCP Gateway controls AI agent access to Model Context Protocol (MCP) servers: what the gateway checks on each tool call, how it uses Permit.io, what it enforces and logs, and what stays outside its scope. This page is for AI agent builders and security reviewers deciding whether and how to put the gateway in front of their MCP servers.
Permit MCP Gateway is an enforcement proxy between MCP clients and MCP servers. The gateway authenticates users, authorizes each agent tool call against policy, collects the user's consent, and logs each decision. You don't modify your 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 such as Cursor, Claude Desktop, VS Code, and Claude Code. MCP servers are the services those clients connect to, such as GitHub, Linear, Slack, and Jira. Permit MCP Gateway sits between MCP clients and MCP servers and applies access control to each connection.
Problems the gateway addresses
Teams that connect AI agents to MCP servers run into these gaps:
- No visibility: without a central log, you can't answer which agents access which systems, what they read or change, and which human authorized the access.
- No per-tool control: API gateways and identity and access management (IAM) tools don't model a human delegating access to an agent, and don't control access per MCP tool.
- Unreviewed MCP connections: anyone can add an MCP server to a client, which creates access paths to sensitive systems that skip security review.
- Compliance gaps: when agents act for humans, audits under regulations and frameworks such as GDPR, HIPAA, and SOC 2 need the same traceability that applies to human actions.
- Broad agent privileges: agents often run with the full access of the credentials they hold, because nothing limits them at the tool level.
How the gateway works
You adopt the gateway with one configuration change: point the MCP client at the gateway URL instead of the upstream MCP server. For the steps, follow Getting started with Permit MCP Gateway.
Admin setup
- Create a host: a named gateway instance with its own subdomain, policies, and users.
- Import MCP servers: the gateway connects to each upstream server, discovers its tools, and assigns each tool a trust level by risk.
- Grant user access: the admin chooses which users can connect to which MCP servers and sets a maximum trust level per user and server.
User connection
- Connect and authenticate: the MCP client connects to the gateway URL, and the user signs in with a method the host allows, such as single sign-on (SSO), OAuth, or email.
- Consent: the user selects an MCP server, reviews its tools, and chooses a trust level for the agent, up to the admin's maximum.
- Use tools: the MCP client works as before. The gateway forwards allowed tool calls to the upstream server and returns a permission error for denied calls.
Each tool call at runtime
- Authenticate: the gateway verifies the agent's JSON Web Token (JWT) and identifies the agent and the human who authorized it.
- Authorize: the gateway asks Permit.io whether this agent can call this tool on this MCP server.
- Audit: the gateway logs the allow or deny decision with the agent, the human, the tool, the MCP server, and the time.
The upstream MCP server receives forwarded requests with the user's upstream credentials, as it would without the gateway.
How Permit MCP Gateway uses Permit.io
Permit MCP Gateway is built on Permit.io. Permit is the control plane and the default data plane for every gateway host: Permit stores the policies, evaluates each authorization decision, and stores the audit logs.
| Component | Role | Dashboard |
|---|---|---|
| Permit.io | Control plane and policy engine. Holds the authorization model, evaluates each permit.check() call, and stores audit logs. | app.permit.io |
| Permit MCP Gateway | Enforcement layer. Proxies MCP traffic, runs authentication and consent, and calls Permit for each authorization decision. The hosted gateway runs on *.agent.security subdomains. | app.agent.security |
Each host is a Permit environment
Each gateway host, such as acme-brave-coral-37.agent.security, maps to one Permit environment:
| Gateway concept | Permit object |
|---|---|
| MCP server imported into a host | Resource type |
| Tool on an MCP server | Action on that resource type |
| User or agent | Permit user with role assignments |
| Trust level | Role, with higher levels including lower ones |
| Maximum trust level (trust ceiling) | Relations and derived roles, using relationship-based access control (ReBAC) |
Because the gateway uses standard Permit objects, gateway policies can use:
- Role-based access control (RBAC), attribute-based access control (ABAC), and ReBAC policy models.
- Policy updates through Open Policy Administration Layer (OPAL). A change to a trust level, access grant, or revocation applies on the next tool call, without a restart.
- Audit logs for each authorization decision, in the Permit dashboard and through the Permit API.
- Policy as code, through the Permit UI, the Permit API, or the Terraform provider.
Two dashboards for one system
Both dashboards show the same authorization data:
- app.agent.security is the gateway dashboard. Use it to create hosts, import MCP servers, grant user access, configure authentication, and review agent activity.
- app.permit.io is the Permit control plane. Use it to inspect derived role rules, raw audit log entries, resource schemas, and role assignments.
For how gateway concepts map to Permit objects in detail, see How Permit MCP Gateway works with Permit.io.
Key capabilities
Authentication
Users sign in through the consent flow before any agent can reach an MCP server. Each host has its own sign-in methods:
- Email and password, email one-time passcode (OTP), and passkeys.
- Google, GitHub, and Microsoft OAuth.
- Enterprise SSO with SAML 2.0 or OpenID Connect (OIDC).
- Email domain restrictions, and redirects that send users with a matching domain straight to SSO.
Authorization
The gateway authorizes each tool call when the agent calls the tool:
- Trust levels per tool: during import, the gateway assigns each tool low (read), medium (write), or high (destructive) trust. Admins can override any tool.
- Maximum trust level per user: admins set the highest trust level each user can grant an agent.
- Consent-based delegation: users choose how much access to grant, up to the admin's maximum.
- Trust ceiling: the agent's effective trust level is the lower of the level the user granted and the level the admin allowed. Permit enforces this ceiling with ReBAC along the human, agent, and MCP server chain.
See Managing humans and agents.
Consent
The consent flow records that a human authorized an agent's access:
- Users see which tools each trust level allows before they grant access.
- Trust levels above the admin's maximum can't be selected.
- The maximum is enforced in the consent UI, in the consent API, and in the Permit policy.
- Sessions persist across client restarts. A session expires 90 days after the last tool call. See Session expiry.
See Consent service.
Audit
The gateway logs each authorization decision:
- Logs appear in the Permit MCP Gateway dashboard and in the Permit.io dashboard.
- Each entry includes the agent, the human, the tool, the MCP server, the time, and the allow or deny decision.
- You can filter logs by agent, user, server, action, or decision.
See Audit logs.
Security and trust model
This section lists what Permit MCP Gateway sees, enforces, and logs, and what stays the responsibility of other components in your environment.
What the gateway sees
| Data | Source |
|---|---|
| User identity | The user's sign-in during the consent flow (SSO, OAuth, or email) |
| Agent identity | The MCP client, such as Cursor or Claude Desktop, identified by its OAuth client ID |
| Tool calls | The name and parameters of each call_tool request |
| MCP server identity | The upstream server the call is sent to |
| Authorization decisions | Whether each tool call was allowed or denied, and why |
What the gateway enforces
- Authentication: users sign in before any agent can reach an MCP server.
- Authorization: the gateway checks each tool call against policy and blocks denied calls before they reach the upstream server.
- Trust ceilings: an agent can't exceed the trust level the human granted, and the human can't grant more than the admin's maximum.
- Consent: an agent gets access only after the human completes the consent flow.
- Session management: sessions expire after 90 days of inactivity, and admins can revoke a session immediately.
- Rate limiting: rate limits apply to authentication, OAuth registration, and MCP endpoints. A request over the limit gets HTTP 429 with a JSON error body. See Architecture: rate limiting.
What the gateway logs
- Each
call_toolauthorization decision (allow or deny), with the agent, human, tool, and server. - User sign-in and consent events.
- Creation and expiry of agent-to-server sessions.
You can read the logs in the Permit MCP Gateway dashboard and through the Permit.io audit log API.
Risks the gateway reduces
- Unauthorized tool access: agents can call only the tools they are permitted to use.
- Privilege escalation: the trust ceiling stops an agent from exceeding the admin's maximum.
- Untraceable agent activity: each tool call is logged and tied to one human and one agent.
- Unreviewed MCP connections: by default, users can connect only to MCP servers an admin imported. Turning on Dynamic MCPs removes this restriction for a host.
- Credential exposure to agents: the gateway holds upstream OAuth tokens and doesn't pass them to MCP clients.
What the gateway does not cover
The gateway enforces access control and audit at the MCP protocol layer. These areas stay with other components:
- Upstream server security: the gateway doesn't check what the upstream MCP server does with an authorized request. Input validation, data access controls, and business logic stay in the server.
- Prompt injection and adversarial inputs: the gateway authorizes tool calls by identity and policy, not by the content or intent of prompts. Defend against prompt injection in the MCP client and the model layer.
- Data classification: the gateway assigns trust levels from tool names. The gateway doesn't inspect data returned by tool calls or classify data sensitivity.
- Network-level controls: the gateway works at the application layer. Network segmentation, firewall rules, and transport security for upstream connections are configured separately.
How the gateway compares to other tools
| Approach | Limitation for MCP use cases |
|---|---|
| API gateways (Kong, Apigee) | Built for REST and gRPC APIs, not the MCP protocol. No model of a human delegating to an agent or of per-tool trust levels. |
| IAM platforms (Okta, Microsoft Entra ID) | Authenticate users, but don't authorize individual MCP tool calls by agents or record consent-based delegation. |
| Direct MCP server access | No gateway authentication, authorization, or audit. Agents connect with whatever credentials the client holds. |
| Permit MCP Gateway | Per-tool authorization tied to the human and the agent, trust delegation from human to agent, consent, and audit at one enforcement point. |
Use cases
Secure the MCP servers your team uses
Your team uses Cursor, Claude, VS Code, or internal agents with MCP servers such as GitHub, Linear, Slack, and Jira. The gateway sits between the agents and those servers, applies per-user access control and trust levels, and logs each tool call.
Example: an engineering team connects Cursor to GitHub and Linear through the gateway. Admins let developers use read and write tools and block destructive tools. Each tool call is logged, and an admin must import an MCP server before anyone can connect.
Offer secured MCP servers to your customers
You build or host MCP servers that your customers connect to. The gateway adds authentication, per-customer authorization, consent, and audit, so each customer's agents reach only what they are permitted to.
Example: a SaaS platform exposes its API as an MCP server. Enterprise customers connect their agents through the gateway with SSO, per-user trust levels, and a separate audit trail per customer.
When to use Permit MCP Gateway
Use the gateway when one or more of these apply:
- You use MCP from Cursor, Claude, VS Code, or internal agents, or plan to.
- You need per-user or per-agent control over which tools agents can call.
- You need one audit trail of agent actions across MCP servers.
- You want users to consent before agents use sensitive tools.
- Different MCP servers and tools need different risk controls.
- You build MCP servers for customers and need to control their agents' access.
If your agents don't use MCP or don't call external tools, the gateway has nothing to enforce. You can add the gateway later, one MCP server at a time.
Deployment models
Permit MCP Gateway runs in three deployment models. For the full comparison, requirements, and air-gapped support, see Enterprise deployment.
Hosted gateway (SaaS)
Permit runs the gateway, the consent service, and the policy decision point (PDP). Each host runs on a subdomain of agent.security, such as acme-brave-coral-37.agent.security, with its own users, policies, and sessions. The hosted gateway is the starting point for evaluation: follow the Permit MCP Gateway quickstart.
Customer-controlled and fully on-premises deployment
- Customer-controlled: the gateway and the PDP run in your virtual private cloud (VPC), data center, or private cloud. MCP traffic stays in your network, and Permit.io remains the control plane.
- Fully on-premises: the whole stack, including the control plane, runs in your environment, and can run air-gapped without internet access.
Both models are available on Enterprise plans. To discuss your requirements, book a demo.
Next steps
- Permit MCP Gateway quickstart: get a gateway URL and connect one MCP client.
- Getting started with Permit MCP Gateway: set up a host for your team and test allowed and denied calls.
- Architecture: data flows and sequence diagrams.
- How Permit MCP Gateway works with Permit.io: the policy model behind hosts, tools, and trust levels.