Enterprise BYOK: allow gateway-fronted Azure AI Foundry / Anthropic-compatible endpoints for regulated zero-trust architectures

[nyckosleducmanage]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Copilot in GitHub

Body

Hi GitHub Copilot team,

I would like to raise an enterprise BYOK feature request for GitHub Copilot custom models.

GitHub Support has already confirmed that this is not a troubleshooting or configuration issue, but a product limitation / feature gap. They suggested opening a public discussion so other enterprise customers can signal demand.

Summary

GitHub Copilot BYOK currently blocks a valid regulated architecture where Azure AI Foundry is fronted by an enterprise API gateway.

The backend model endpoint works correctly. The blocker is that the Copilot BYOK configuration flow validates the Microsoft Foundry endpoint hostname before sending any request, and rejects gateway-fronted URLs that are intentionally not *.services.ai.azure.com or *.openai.azure.com.

For regulated organizations, this prevents adoption of Copilot custom models with private Azure AI Foundry deployments.

Enterprise architecture

We are operating in a regulated financial services environment with a hardened Azure Landing Zone and a central Azure AI Foundry account.

The Foundry account is configured with:

• public_network_access_enabled = false
• Private Endpoint only
• local_auth_enabled = false
• No account keys
• Entra ID / Managed Identity only
• Azure API Management in front of Foundry
• APIM policies for per-consumer subscription keys, rate limits, audit logging, and usage tracking
• Same pattern across UAT and PRD

The intended architecture is:

GitHub Copilot BYOK
        ↓
Enterprise API gateway / APIM
        ↓
Managed Identity
        ↓
Private Azure AI Foundry endpoint

Consumers never receive a Foundry key or direct Foundry endpoint access.

What works today

APIM exposes an Anthropic-compatible endpoint:

Base URL: https://api.ai.roversafe.com/devops
Operation: POST /v1/messages
Client auth: x-api-key carrying the APIM subscription key
Backend auth: APIM Managed Identity authenticates to Azure AI Foundry
Backend response: Foundry returns an Anthropic-format response

Direct protocol tests with Postman and curl are successful.

The APIM endpoint returns clean HTTP 200 responses with Claude Opus through Azure AI Foundry.

So the AI plumbing, authentication, APIM policy, backend routing, and response format are all working.

Current blocker

The Microsoft Foundry BYOK provider rejects the APIM URL during wizard validation before any request is sent.

This has been confirmed because APIM receives zero access log entries during the Copilot BYOK validation attempt.

The issue is therefore not connectivity, authentication, APIM policy, or model compatibility.

The issue is that the BYOK configuration UI enforces a hostname pattern such as:

*.services.ai.azure.com
*.openai.azure.com

This validation blocks enterprise gateway-fronted endpoints even when they are fully compatible with the expected provider API.

The Anthropic and OpenAI BYOK providers do not currently provide a custom base URL field either, so the same architecture is blocked through those providers as well.

Requested product changes

There are two possible ways to solve this.

Preferred option

In the Microsoft Foundry BYOK provider, add an explicit opt-in option to allow a gateway/proxy endpoint.

For example:

This endpoint is fronted by an enterprise API gateway

When this option is enabled, Copilot should skip strict hostname validation and validate the endpoint by making the actual protocol call instead.

Alternative option

Expose a Base URL field for Anthropic and OpenAI BYOK providers, allowing operators to configure any compatible endpoint.

For example, an Anthropic-compatible Messages API endpoint could point to:

https://api.example.com/anthropic/v1/messages

This would allow enterprise gateways, private proxies, APIM, internal model gateways, or regulated model brokers to work without requiring Copilot to support every gateway implementation explicitly.

Why this matters

In regulated enterprise environments, direct public exposure of Azure AI Foundry endpoints is often not acceptable.

An enterprise API gateway is not an optional convenience. It is part of the control plane.

It provides:

• Centralized identity brokering
• Managed Identity to Foundry
• No distribution of Foundry keys
• Per-consumer quota and cost attribution
• Centralized audit logging
• Rate limiting
• Policy enforcement
• Zero-trust isolation
• A stable enterprise endpoint independent from backend provider changes

Without support for gateway-fronted BYOK endpoints, regulated organizations are forced into bad options:

1. Create a separate Foundry account with relaxed security just for Copilot BYOK
2. Expose endpoints more broadly than internal policy allows
3. Duplicate quotas and split governance
4. Use a competing AI coding assistant that supports custom base URLs natively

Expected behavior

Copilot BYOK should support enterprise-controlled endpoints when they are protocol-compatible with the selected provider.

A gateway-fronted Microsoft Foundry / Anthropic-compatible endpoint should be accepted if:

• The admin explicitly marks it as a gateway/proxy endpoint
• The endpoint passes an actual validation request
• The configured authentication mechanism succeeds
• The response follows the expected provider format

Actual behavior

The endpoint is rejected before any outbound request is made because the hostname does not match the expected Microsoft Foundry / Azure OpenAI domain pattern.

No request reaches APIM during validation, which proves this is a preflight hostname validation issue rather than an API/runtime failure.

Why this is broader than one customer

This pattern is common in regulated industries:

• Financial services
• Insurance
• Healthcare
• Government
• Critical infrastructure
• Large enterprises with centralized API gateways

Many enterprise customers cannot let every AI-consuming tool connect directly to backend model providers. They need a central broker for governance, audit, security, and cost management.

Supporting custom/gateway-fronted BYOK endpoints would make GitHub Copilot custom models much more usable in enterprise zero-trust environments.

Requested feedback from GitHub

Could the Copilot product team consider adding either:

1. A gateway/proxy opt-in bypass for Microsoft Foundry BYOK hostname validation, or
2. A custom Base URL field for Anthropic/OpenAI/OpenAI-compatible BYOK providers in the enterprise BYOK configuration flow?

I would be happy to provide architecture diagrams, APIM policy examples, sanitized traces, and request/response samples if helpful.

Thanks!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[nyckosleducmanage]

For info : github/roadmap#1027

[richardchen874-sys]

This is a very valid enterprise BYOK requirement.

For regulated environments, the gateway is not just a networking detail. It is part of the control plane: identity brokering, audit logging, quota enforcement, rate limiting, cost attribution, policy enforcement, and backend isolation all depend on it.

So validating only by hostname pattern can block architectures that are actually more secure than direct provider access.

In my opinion, Copilot BYOK should probably distinguish between two checks:

1. Provider identity / protocol compatibility
2. Enterprise gateway trust boundary

If the admin explicitly marks an endpoint as gateway-fronted, the validation should be based on an actual protocol request and response shape, not only the public hostname.

A useful enterprise flow might be:

• admin enables “gateway / proxy endpoint” mode
• admin selects expected protocol: OpenAI-compatible, Anthropic Messages, Azure Foundry, etc.
• Copilot sends a real validation request
• validation checks auth, response schema, streaming behavior, and model availability
• audit / cost / rate-limit headers can optionally be surfaced
• hostname mismatch becomes a warning, not a hard blocker

This would support APIM, internal model gateways, regulated model brokers, and private endpoint architectures without weakening security.

For enterprise BYOK, custom base URL support is not only about flexibility. It is what allows central governance, cost attribution, and zero-trust model access to work.

[Jamonygr]

This looks like a product validation gap rather than an APIM problem.

Your architecture makes sense for a regulated environment: Copilot -> enterprise gateway/APIM -> managed identity -> private Azure AI Foundry endpoint. The issue seems to be that the BYOK setup flow validates the endpoint hostname before it ever reaches your gateway pattern. If the product only accepts direct Azure OpenAI or Foundry hostnames, then a valid zero-trust gateway URL will be rejected even though the backend API works.

For now, I would treat this as a feature request and include exactly what you already listed: required gateway hostname support, Entra/MI backend auth, audit logging, rate limiting, and private endpoint-only Foundry access.

Short term, the only reliable workaround is usually to use a directly supported endpoint pattern for Copilot BYOK, then enforce as much control as possible with Azure networking, identity, logging, and policy around that endpoint.