https://linen.dev logo
Join Slack
Powered by
Hi everyone, I’m new here, so hello everyone :wave...
# permit-saas
b
Hi everyone, I’m new here, so hello everyone 👋 We're evaluating the MCP Gateway for our platform. We already run OPA + OPAL as authorization sidecars across 12 services, with ~350 fine-grained permissions and a custom OPAL data publisher. We'd like to keep our existing OPA as the authoritative policy engine. From the architecture docs, we understand the Gateway calls 
permit.check()
via the Permit SDK and this is answered by Permit's PDP , not a generic OPA query. We've also reviewed the enterprise deployment page but found no mention of external/delegated decision endpoints. Two questions: • Does the MCP Gateway support an external decision endpoint (webhook, custom PDP URL or similar) that would let us route authorization decisions to our own OPA? • If not, can the open-source PDP be configured to load policies from our own OPAL server and Rego bundles instead of Permit's cloud control plane? We'd want to avoid running two parallel OPA+OPAL stacks with two separate policy sources.
a
Hi @Bartosz Gołębiewski, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
The Permit MCP Gateway's authorization architecture is tightly integrated with Permit.io's control plane and PDP (1) . The Gateway calls 
permit.check()
on every tool call, and these authorization decisions are evaluated by the Permit PDP (Policy Decision Point) . In the hosted deployment, the cloud PDP handles these evaluations, while customer-controlled deployments can use a local PDP so authorization decisions stay within your network . ​*Regarding external decision endpoints:*​ The available documentation does not describe support for routing authorization decisions to an external OPA instance or custom decision endpoint. The architecture shows the Gateway is designed to integrate specifically with Permit.io's PDP for all authorization checks . ​*Regarding PDP policy source configuration:*​ The PDP is configured via environment variables (2) . The critical configuration is 
PDP_API_KEY
, which is required and must be an Environment-level API Key used to authenticate the PDP against Permit.io . The PDP also uses 
PDP_CONTROL_PLANE
(default: 
<https://api.permit.io>
) as the URL of the Permit.io control plane . The documentation does not describe configuring the PDP to load policies from an external OPAL server or custom Rego bundle source instead of Permit's control plane. The PDP configurations reference Permit.io's control plane endpoints (
PDP_CONTROL_PLANE_PDP_DELTAS_API
, 
PDP_CONTROL_PLANE_RELAY_API
) with a note that these are "controlled by Permit.io, changing it can cause your PDP to malfunction" . I don't have information in the available sources about delegating to external OPA instances or using custom policy sources with the MCP Gateway's authorization flow. For your specific use case—integrating with an existing OPA + OPAL stack—I'd recommend reaching out over Email to discuss whether custom integration patterns are available for enterprise deployments. Would you like a general answer based on my knowledge instead? **
To learn more, see the sources I considered: [[1] Permit MCP Gateway Architecture](https://docs.permit.io/permit-mcp-gateway/architecture) [[2] Configurations](https://docs.permit.io/concepts/pdp/configuration)
o
Hi Adding on top of the AI’s answer - a self-hosted version of the Gateway supports both configuring your own policies in Rego, and setting up your own OPA. In the hosted cloud version you can log-in into Permit and configure additional ReBAC and RBAC Permit policies on top of the auto generated ones. @Ask Inkeep elaborate if you can
👍 1
a
Thanks for tagging me @Or Weis. I'll look through relevant sources and get back to you shortly.
The available documentation does not explicitly describe configuring custom Rego policies or connecting to an external OPA instance in the self-hosted MCP Gateway deployment. ​*What the documentation does cover:*​ The enterprise deployment models show that customer-controlled deployments include the Gateway, Consent Service, and a local PDP running in your environment (1) . The fully on-premises package includes "Policy Decision Point (PDP) — local authorization engine for real-time 
permit.check()
evaluations" . The PDP is described as "bundling together OPA, OPAL and an API Server" (2) , and Permit's PDP orchestration is "powered by OPAL" . However, the architecture documentation consistently shows the Gateway calling 
permit.check()
against Permit's PDP (3) , and each gateway host maps 1:1 to a Permit environment where "MCP servers imported into a host become resource types in the linked Permit environment" (4) . ​*What's not documented:*​ The available sources don't describe: • Configuring the self-hosted Gateway to use an external OPA endpoint instead of Permit's PDP • Loading custom Rego policies from your own OPAL server into the Gateway's authorization flow • Bypassing the Permit control plane for policy management in self-hosted deployments For detailed information about custom Rego policy configuration and external OPA integration in self-hosted Gateway deployments, I recommend reaching out over Email to discuss your specific architecture requirements. Would you like a general
To learn more, see the sources I considered: [[1] Enterprise Deployment](https://docs.permit.io/permit-mcp-gateway/enterprise-deployment) [[2] Permit's PDP (Policy Decision Point)](https://docs.permit.io/concepts/pdp/overview) [[3] Permit MCP Gateway Architecture](https://docs.permit.io/permit-mcp-gateway/architecture) [[4] Permit MCP Gateway Overview](https://docs.permit.io/permit-mcp-gateway/overview)
o
if you’d like a self-hosted gateway please schedule a meeting via: https://calendly.com/permitio/permit-enterprise CC: @Natalia Edelson , @Shay Shany
👍 1
2 Views
Open in Slack
PreviousNext
Powered by