Integration guide

Frontière models in Microsoft Foundry agents

Microsoft Foundry Agent Service can call models hosted outside Azure through a gateway connection — Microsoft calls it bring your own model. Frontière is exactly that: an OpenAI-compatible gateway. Point a connection at it and every live model in the catalog becomes selectable when you build an agent, while the inference itself keeps running on European infrastructure.

What this gives you

Your agents stay in Foundry — same project, same tools, same orchestration, same Azure identity and RBAC. Only the model changes: instead of a model deployed and served by Microsoft, the request leaves Azure and reaches Frontière, which routes it to the provider actually hosting the model (OVHcloud, Scaleway, or a dedicated EU server) and bills you per token from your prepaid balance.

This is the supported, documented path: a connection of type Model Gateway, created by an admin inside your own tenant. There is nothing to approve on Microsoft's side and no Marketplace purchase involved — you need an API key and about ten minutes.

Before you start

Four things:

• A Microsoft Foundry project in an Azure subscription.
• The Foundry User role (or higher) on the project, and Contributor on the resource group — the connection is deployed as a resource.
• A Frontière API key (dashboard → API keys), and a balance that is not at zero: an agent whose calls return 402 stops answering.
• The model IDs you want to expose, from the catalog — e.g. glm-5.2 or qwen3.5-397b.

# The catalog is public — the IDs you declare in Foundry come from here
curl https://getfrontiereai.eu/api/v1/models

# The chat endpoint needs the same key Foundry will carry
curl https://getfrontiereai.eu/api/v1/chat/completions \
  -H "Authorization: Bearer $FRONTIERE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"glm-5.2","messages":[{"role":"user","content":"ping"}]}'

1. Create the connection

In the Foundry portal, connections to external models are managed at the account level, not per project:

1. Sign in to the Foundry portal, select Operate, then Admin.
2. Open the All projects tab, find your project, and select the link in its Parent resource column.
3. Open the Admin-connected models tab and select Add.
4. On the Connection type page, choose Other source — the option for a self-hosted or non-Azure gateway — name the connection (the name becomes part of the model reference, so keep it short: frontiere), and enter the base URL below.
5. On the Authentication page, choose API key and fill in the three fields from the table.

On the Advanced page, leave API version empty and leave Include deployment name in URL path disabled: Frontière exposes the OpenAI-style path (/chat/completions), not the Azure OpenAI one with the deployment name in it. No custom header is needed.

If you provision infrastructure as code rather than by hand, the same connection exists as a Bicep template in Microsoft's foundry-samples repository, under the ModelGateway category — same fields, deployed with az deployment group create.

2. Declare the models

Still in the wizard, on the Model configuration page, add one entry per model you want your teams to be able to pick. In Name, put the Frontière model ID exactly as it appears in the catalog (glm-5.2) — that is the value sent in the model field of the API call. In Display name, put whatever reads well in the portal (GLM-5.2 — EU sovereign).

Each model you add becomes a deployment in Foundry, selectable when configuring an agent. Add only what you intend to use: the list is an internal catalog for your organization, and it is easier to add a model later than to explain a deployment nobody chose.

Our catalog endpoint only returns live models, so anything you copy from it is callable right now. Coming-soon models are deliberately excluded — declaring one would put a model in your agent picker that answers 409 in production. You can see them with ?include=all, but do not wire them up.

3. Use it in an agent

The only difference from a standard Foundry agent is the model deployment name: prefix the model with the connection name, separated by a slash. With a connection named frontiere and the model glm-5.2, the agent's model is frontiere/glm-5.2.

import os
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition
from azure.identity import DefaultAzureCredential

project = AIProjectClient(
    endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

agent = project.agents.create_version(
    agent_name="sovereign-assistant",
    definition=PromptAgentDefinition(
        model="frontiere/glm-5.2",  # <connection-name>/<model-name>
        instructions="You are a helpful assistant.",
    ),
)

client = project.get_openai_client()
conversation = client.conversations.create()
response = client.responses.create(
    conversation=conversation.id,
    input="Bonjour",
    extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}},
)
print(response.output_text)

Create the agent with the Agent SDK, then talk to it through the OpenAI client the project hands you. If the call comes back with model not found, the deployment name is almost always the cause — check the connection-name/model-name format before anything else.

Adapted from Microsoft's Agent SDK samples; check their repository for the current signatures, which move faster than this page. learn.microsoft.com

What it changes, and what it doesn't

Worth being precise, because this is the part a data protection officer will read twice. What changes: the model is no longer served by Microsoft. Inference runs on the provider hosting it — OVHcloud, Scaleway or a dedicated EU server — and the sovereign flag on each model tells you which jurisdiction that is. Weights, GPUs and the inference logs stay out of Azure.

What does not change: the agent still runs in Foundry. Prompts, tool calls and conversation history transit through Microsoft's orchestration before reaching us, so the orchestration layer keeps whatever jurisdictional exposure your Azure tenant already has. Microsoft states the counterpart plainly in its own documentation: with a bring-your-own model, you are responsible for reviewing the data shared with it, and Azure's safety systems and content filters no longer apply — the guardrails are yours to configure.

So this integration is the right answer to “our agents must not run on an American model”, and only a partial answer to “no American company may process our data”. If the second one is the requirement, call the Frontière API directly instead of routing through Foundry — the same key, the same models, without the Azure hop.

GDPR vs the CLOUD Act →

Troubleshooting

The failures worth knowing about before they happen:

FAQ