Azure AI Foundry Joins Anthropic and OpenAI
July 11, 2026 · InfraScout Team
Two weeks ago you gained a second model vendor alongside Anthropic. Today you gain a third option that changes not just which model answers, but where it runs: you can now point an AI provider connection at Azure AI Foundry. Chat, Agentic Workflows, Task Agents, and diagram rendering all work on a Foundry connection. Anthropic stays the default, and nothing changes unless you add one.
Why run inference on Foundry
An Anthropic or OpenAI connection sends your assessment conversation to the model vendor directly. That is fine for most tenants, and it stays the default. But if your organization has already made Azure the boundary for where workloads run and where data lands, calling a model vendor from outside that boundary is an exception you have to justify.
A Foundry connection removes the exception. Inference runs on models you deployed into your own Foundry resource, which means it runs under your Azure tenancy, on your Azure billing, in the regions you chose when you created the resource. The assessment conversation is unchanged — the AI still works through the same InfraScout tools, opens sessions against your agents, queries Microsoft Graph and Azure, and saves findings. Only the place the model executes moves.
Foundry appears as two provider choices
When you create a connection, Foundry shows up twice: Azure AI Foundry (Claude) and Azure AI Foundry (OpenAI). This is deliberate, not a duplicate.
A single Foundry resource can serve both Claude models and GPT models, but it serves them through two different surfaces, and those surfaces behave differently. Rather than hide that behind one label and have the connection fail at chat time, InfraScout makes you pick the surface that matches the models you actually deployed. If your Foundry resource hosts Claude deployments, choose the Claude option; if it hosts GPT deployments, choose the OpenAI one. The model dropdown then scopes to that surface, so you only see models you can genuinely select. Nothing stops you from registering both against the same resource if you deployed both.
What a Foundry connection needs
Beyond the usual name and model, a Foundry connection takes two things: the endpoint URL of your Foundry resource and the key for it. As with every other provider, the key is stored encrypted and belongs to that one connection — there is no shared key behind the scenes.
The endpoint is validated when you save. InfraScout accepts only genuine Microsoft-owned Foundry hostnames, so a connection can never be pointed at an arbitrary host, whether by mistake or otherwise. If you paste something that isn't a Foundry endpoint, the save is rejected before the connection is ever used.
Capabilities differ by provider
This is the part worth reading twice. The four providers do not all support the same optional features, and InfraScout no longer lets you configure a connection as though they did.
| Provider | Web research | Data region | Batch processing |
|---|---|---|---|
| Anthropic | Yes | Yes | Yes |
| OpenAI | Yes | No | No |
| Azure AI Foundry (Claude) | No | No | No |
| Azure AI Foundry (OpenAI) | Yes* | No | No |
Read this as a statement about optional capabilities, not about quality. Core chat is the same everywhere: the AI streams its answer, runs the full agentic tool loop, shows its reasoning, and keeps long conversations in bounds. What varies is whether it can also reach the public web, whether you can pin inference to a region, and whether the connection can run work on the batch engine. A Foundry (Claude) connection is a fully capable assessment connection that happens not to offer web research — if a review depends on consulting an external advisory mid-conversation, run it on a connection that has it.
Web research on Foundry (OpenAI) depends on your workspace
The asterisk is real. Web search on the Foundry OpenAI surface is enabled per Foundry workspace, in your Azure subscription — not by InfraScout. If your workspace has web search disabled, the connection saves without complaint and then web research fails when the model actually tries to use it during a chat. If you plan to rely on web research through Foundry, confirm your workspace allows it first.
Because Agentic Workflows need the batch engine to queue work, workflows on a Foundry connection fall back to sync execution automatically, the same way they already do on OpenAI. Scheduled and webhook triggers still fire — the run just executes inline rather than queuing.
Memory rollup now demands a batch-capable connection
Batch processing sounds like an implementation footnote until you notice what depends on it: your tenant's Memory rollup. Rollup is the background pass that reviews idle conversations and folds their durable facts into persistent memory, and it runs on the batch engine. Today, that means the connection you designate for rollup must be an Anthropic connection.
Previously, nothing stopped you from designating a connection that could not batch. The save went through, and the rollup then quietly failed — for the whole tenant, because only one connection carries the rollup designation. InfraScout now enforces the requirement in both places it matters. Marking a non-batch connection as the rollup connection is rejected at save time, with an explanation, and the rollup path itself checks before it runs. A misconfiguration can no longer silently switch off memory rollups tenant-wide.
The same work fixed a related bug worth knowing about if you already run more than one provider. Rollups now always run on the connection you designated for rollup, never on whichever connection a conversation happened to be chatted on. Before this change, a tenant with a perfectly good Anthropic rollup connection would still lose the rollup of any conversation held on an OpenAI connection. That is fixed: the designation is what decides, every time.
Try it
Deploy a model into a Foundry resource in your own Azure subscription, then have an admin add a connection in the AI Providers view — pick the Claude or OpenAI Foundry option to match your deployment, paste the endpoint URL and key, and choose your model. Open a chat against it and give it real work: a tenant security review, a fleet sweep, a playbook run. It behaves the way you already expect, on infrastructure you already own.
See the AI provider connections guide for managing connections and the Memory guide for how rollup builds persistent knowledge. Questions or feedback? Reach us at info@infrascout.cloud.