This is a classic and complex network routing issue that occurs when combining OAuth 2.0 Authorization Code Flows with strict VNet-inbound restrictions (Private Links) in multi-tenant SaaS environments like Copilot Studio / Power Platform.
The reason your connection works perfectly via VS Code, Postman, and your test VM, but fails inside Copilot Studio, comes down to where the actual OAuth handshake request originates from.
The Root Cause Analysis
When you initiate the OAuth 2.0 connection from Copilot Studio, the process breaks down at the Azure API Hub redirect URL (consent.azure-apihub.net).
- The Handshake Origin: During the OAuth authorization phase, the underlying Azure Power Platform connector infra (Azure API Hub) makes an outbound call to Palantir’s token/authorization endpoint to exchange the code for an access token.
- The Routing Blindspot: Even though you have configured and approved a Power Platform Virtual Network (VNet) Data Gateway / Private Link, the initial OAuth token-exchange traffic from the managed API Hub infrastructure often routes via the Public Microsoft/Azure Backbone Internet IPs, rather than traversing through your specific customer-configured VNet Private Endpoint.
- The Block: Because Palantir is configured to strictly block any request originating outside your VNet, it rejects/drops the token-exchange request from the Azure API Hub, causing the consent page to spin endlessly and eventually time out.
Recommended Solutions & Workarounds
1. Whitelist Azure API Hub / Power Platform Trusted IPs
If Palantir allows IP-based exceptions alongside VNet restrictions, you need to add the public IP addresses of the Power Platform / Azure API Hub connectors for your specific region (e.g., US Azure regions) to the Palantir inbound firewall rules.
- You can download the weekly updated Azure IP Ranges and Service Tags – Public Cloud" document from Microsoft to get the precise IP ranges for PowerPlatformInfra or AppService.
2. Leverage Power Platform Managed VNet Support for Custom Connectors
Ensure that your Palantir MCP integration is explicitly bound to a Managed VNet environment within Power Platform.
- Go to the Power Platform Admin Center, verify your network injection settings, and ensure that the Enterprise Policies for Subnet Injection are properly applied to the environment hosting your Copilot Studio Agent. If the connector bypasses this policy during the authorization phase, it will fail.
3. Transition to a Hybrid / Direct Logic Apps Wrapper (Robust Workaround)
If modifying Palantir's edge firewall to trust Azure public infrastructure is not an option, you can isolate the OAuth handshake within your VNet:
- Deploy an Azure Logic App (Standard Plan) injected directly into your Azure VNet where the Private Link is active.
- Configure the Logic App to handle the Model Context Protocol (MCP) communication with Palantir locally.
- Secure the Logic App endpoint using Microsoft Entra ID (OAuth).
- Call the Logic App from Copilot Studio. Since Copilot Studio will be authenticating against Entra ID (which is fully public and native to Microsoft), the connection setup will succeed instantly, while the internal VNet routing to Palantir will be safely handled inside your private network.
Summary Question for the Community
Has anyone successfully forced the Azure API Hub regional consent service to route exclusively through an Azure ExpressRoute or VNet Data Gateway during the initial authorization phase, without opening the endpoint to Microsoft's public service tags?
Hope this helps narrow down the network boundary breakdown!
Best regards,
