AI
Microsoft launches dedicated Azure API gateway tier built for AI model governance
Azure API Management now offers a purpose-built gateway tier that centralizes control over models, MCP tools, and cost governance—though questions remain about agent lifecycle handling and migration paths.
InfoQ
Microsoft has announced a new dedicated AI Gateway tier for Azure API Management, entering public preview with a fresh architectural approach: rather than layering AI capabilities onto an existing API gateway, this tier reorganizes its control plane entirely around models, MCP servers, and tools.
The move reflects a shift in how teams now operate. Where traditional API management handled a single backend, modern AI systems often coordinate multiple model providers—OpenAI, Anthropic, Mistral, AWS Bedrock, Google Vertex AI, and others. The new tier treats this multi-provider reality as a first-class design principle.
How it works: Models and tools as first-class entities#
The gateway supports publishing models from Foundry (OpenAI, Anthropic, Mistral), AWS Bedrock, Google Vertex AI, and direct OpenAI endpoints. All OpenAI-compatible providers route through a single endpoint path, with routing decided by matching the model name field. Anthropic is integrated via a custom provider using Messages API passthrough.
For tools, the gateway can federate from three sources: a remote MCP server by URL, an OpenAPI specification, or built-in connectors covering over a thousand SaaS applications. Each backend's operations become published tools. Authentication is configurable per backend—none, API key, OAuth 2.0, or managed identity.
Governance is expressed as portal cards rather than XML and policy expressions, covering token and request limits, quotas, Content Safety policies, and model fallback logic. Deployment takes about a minute with no scale unit planning required. Telemetry exports as OpenTelemetry metrics to Application Insights, Datadog, Grafana, or customer-controlled destinations.
Organizational split: Center vs. teams#
The intended operating model separates platform stewardship from application team autonomy. A central platform group connects approved models and tools, then publishes them. Application teams can explore offerings in a test console and build against them without routing every change through a gatekeeping process, while the platform group maintains guardrails and visibility.
Where questions remain#
Community reaction has been broadly positive on consolidation, but several governance and operational ambiguities have surfaced:
