1. Static API Tokens for Non-OAuth Upstream MCP Servers For upstream MCP servers that don't require OAuth, the gateway handles this transparently — if the upstream server doesn't require authentication, no token is sent (1) . The documented consent flow shows that when the Consent Service probes an upstream server and doesn't receive a

401

response indicating OAuth is required, the upstream OAuth step is skipped entirely . The sources don't document a configuration option for static API tokens, service account credentials, or custom headers for non-OAuth upstream servers. The architecture shows that upstream OAuth tokens are stored in Redis when OAuth is required, but there's no mention of static token configuration . 2. Granular User/Tool Permissions The permission model is based on the ​*Low / Medium / High trust level system*​ (2) (1) . Tools are auto-classified into these trust levels based on naming patterns during import (2) : • ​*Low trust*​ — read-only tools (default for tools not matching medium or high patterns) (3) • ​*Medium trust*​ — write operations (tools containing:

create

,

write

,

update

,

set

,

modify

, etc.) • ​*High trust*​ — destructive operations (tools containing:

delete

,

remove

,

destroy

,

drop

, etc.) Trust levels are hierarchical — higher levels inherit all permissions from lower levels . The sources indicate that admins grant users access to specific MCP servers and set a per-user trust ceiling, and users then choose their agent's trust level during consent (up to that ceiling) (2) (1) . However, the sources don't document a way to create an exact

user × tool

permission matrix that grants access to individual tools outside of the trust level framework. The gateway returns all tools in

list_tools

responses regardless of the agent's trust level, with authorization enforcement happening exclusively at

call_tool

time (3) . 3. Upstream OAuth Flow For OAuth-protected upstream MCP servers, ​*every end user must complete the upstream OAuth flow individually*​ (1) . The consent flow shows: 1. The Consent Service probes the upstream server and receives a

401

indicating OAuth is required 2. The user is redirected to the upstream provider to authorize 3. The Consent Service exchanges the authorization code for tokens 4. The upstream tokens are stored securely and used for all future tool calls proxied through the gateway The sources don't document an option to use admin or service-account credentials for all users. The architecture explicitly shows that upstream OAuth tokens are stored per-user session and used when proxying tool calls . Permit-level permissions (the trust level system) are separate from upstream permissions — Permit enforces which tools an agent can call based on trust levels, while upstream OAuth handles authentication to the upstream service (3) (2) . 4. Outbound IP Addresses for Permit Cloud The sources don't document static outbound IP addresses for the Permit Cloud hosted gateway deployment. The egress requirements table in the on-premises installation guide lists upstream MCP servers as a required destination, but this is in the context of customer-controlled deployments, not the hosted cloud service (4)

Feel free to tag me with additional questions. I also appreciate feedback, it helps me improve. 👍 button 👎 button

Appreciate the feedback! Feel free to ask me again with additional guidance or context.

3. Giving access without bounding to a authenticating and binding to a specific user is probably a bad idea for both zero trust and for users delegating access to their own surfaces within services. But this can technically be done

4. We don't provide static IPs, but the Gateway does support approaching an MCP server with a dedicated secret for auth