On September 3, 2026, the Microsoft Foundry Blog described the architecture behind Fireworks on Microsoft Foundry. The update is not simply another model listing. It surfaces the questions enterprise teams often compress into one sentence: who owns identity and governance, who runs the GPUs, where prompts cross a boundary, and which compliance commitments do not apply.
The system is easiest to understand as two planes. Microsoft Foundry is the control plane for Microsoft Entra ID, Azure RBAC, quotas, Foundry guardrails, endpoint management, auditing, metering, and billing. Fireworks is the inference provider for GPUs, model weights, gateway routing, workload isolation, retention, and inference observability. Models appear in the Foundry catalog and can be deployed and managed through Azure, but inference runs in the Fireworks Inference Cloud.
That division lets a customer keep its Azure identity, policy, and billing workflow while accessing newer open models, custom weights, serverless consumption, and provisioned throughput. Microsoft says a separate Fireworks account or contract is not required for the Foundry consumption experience. For teams evaluating models, handling bursty workloads, or moving in stages toward production, one management entry point can reduce operational friction.
The most important sentence is the boundary disclosure: a prompt travels from the Microsoft Foundry endpoint across the Microsoft-Fireworks boundary, and customer data is sent to the Fireworks inference cloud. Microsoft says that portion of processing is governed by Fireworks controls. That does not make the architecture unsafe; it makes the risk legible. A model being in the Foundry catalog does not mean all data remains inside the customer's Azure tenant.
Microsoft lists controls including default zero data retention for inference, transient prompts and completions, no training or fine-tuning on customer data, TLS 1.2 or later, AES-256, logical isolation, least-privilege access, and restricted production access. The article also calls out a configuration difference: the Foundry Responses API can retain conversation state for 30 days when store=true. Teams seeking stateless operation should use store=false or delete the response record. That setting directly changes a sensitive-data risk review.
The compliance boundary is not presented as universal. Microsoft says Fireworks on Foundry is outside its EU Data Boundary commitments, does not have FedRAMP, is unavailable in Azure Government, and is not applicable to PCI DSS workloads. Customers remain responsible for evaluating model safety, quality, responsible-AI characteristics, and fitness for use. Those exclusions matter for financial, healthcare, public-sector, and region-bound workloads.
Deployment options include Data Zone Standard, a serverless per-token path for evaluation and variable demand, and Global Provisioned Throughput for predictable, high-volume, latency-sensitive workloads. Teams should test latency, quality, retention, and geographic routing with representative data before reserving capacity or bringing their own weights. Open-model choice is not evidence that every production policy is satisfied.
Fireworks on Foundry matters because it turns open-model adoption into an auditable data-flow diagram. Azure identity and governance can remain in place, while inference, retention, and part of the compliance responsibility sit across a disclosed third-party boundary. For agent workflows, that is more important than having many models behind one endpoint: the approval question is where each prompt, tool call, response, and storage setting goes.
