A practical follow-up to an earlier architecture-level post on Azure AI governance, this piece digs into the actual Azure Policy definitions and APIM XML that implement a two-layer governance model. It covers resource-layer controls (network restrictions, private link, disabled key access, managed identity, diagnostic logging, approved model deployments with asset ID prefix matching gotchas) and runtime-layer APIM policies (llm-token-limit, llm-content-safety, llm-emit-token-metric, semantic caching). It explains why resource governance should change slowly via Audit-first rollout while APIM runtime controls can be tuned more frequently, and offers a phased implementation approach starting with visibility before enforcement.
Table of contents
The resource layer, in Azure Policy termsThe runtime layer, in APIM XMLWhy the two layers change at different speedsQuestions this post answers
How does Azure's approved-model policy match asset IDs like gpt-5 versus gpt-5.2?
Azure Policy uses prefix matching on asset IDs for Foundry model deployment allow-lists. Specifying an asset ID ending with a trailing slash (e.g. azureml://registries/azure-openai/models/gpt-5/) restricts matches to that model while allowing all its versions. Omitting the trailing slash on an entry like models/gpt-5 can unintentionally also match models whose names start with the same characters, such as GPT-5.2 or GPT-5.4, broadening the allow-list more than expected. Teams tightening Azure AI model allow-lists can track policy nuances like this via daily.dev.
Which Azure API Management tiers support the llm-token-limit policy?
The llm-token-limit policy works on the Developer, Basic, Standard and Premium APIM tiers, including their v2 equivalents, but is not supported on the Consumption tier. This policy applies tokens-per-minute limits, a longer-period token quota, or both, against a counter key such as the APIM subscription ID, so the SKU choice needs to account for this before planning an AI gateway rollout. Anyone sizing an APIM SKU for AI workloads can keep tabs on gateway capability limits via daily.dev.
What is the difference between Azure Policy Audit and Deny effects when governing AI resources?
Deny effects block non-compliant resources at creation time and work well for controls that are cheap to get right during provisioning, such as network access restrictions. Audit effects flag non-compliance without blocking, which is safer for existing estates where controls like disabling public network access, local authentication, or private connectivity could already have dependent consumers behind them, avoiding unexpected outages from immediate enforcement. Platform teams rolling out Azure Policy baselines can weigh Audit versus Deny trade-offs with daily.dev.