Provider access stays separate from application control.
01
Keep Azure details out of application code
Applications call an AI Gateway HQ alias with a scoped workload key. The gateway owns the Azure resource endpoint, deployment mapping, and provider credential, so administrators can rotate access or change an eligible deployment without redistributing secrets.
02
Apply the same ceiling everywhere
Attach dollar budgets, request and token rates, concurrency limits, and fallback rules to each workload. The policy boundary follows the application even when an administrator changes the eligible Azure deployment behind its alias.
03
Test the exact deployment boundary
A connection check validates the configured Azure resource before production traffic is admitted. Route eligibility remains explicit because a model name, API version, and deployment name are separate concerns in Azure environments.
Current shared controls
Status determines what can be configured.
Write-only, encrypted BYOK for implemented provider connections Stable model aliases and protocol-eligible route targets Organization and key budgets, RPM, TPM, and concurrency hard limits Observe, Shadow, Enforce, reason codes, and metadata-only evidence
Beta connections require customer validation against the exact model, payload, streaming mode, region, and provider account before production use.
Applications keep a stable gateway URL and model alias while an administrator changes eligible provider accounts and models.
Implemented boundary
Only documented protocols become eligible.
Choose Azure OpenAI, enter the resource endpoint and API key in the write-only credential form, verify the model boundary, and map a stable route alias to the intended Azure deployment.
POST /v1/chat/completions GET /v1/models connection test Azure resource endpoint and deployment mapping
Compatibility is bounded to the provider's current published interface. Review the provider documentation before approving a production model.