Azure Policy is Azure's rules engine for resource configuration. A policy definition describes a condition about a resource's settings and an effect — most commonly audit (record the violation and show it on a compliance dashboard) or deny (reject the create or update outright). An assignment binds the definition to a scope: a management group, a subscription, or a resource group. Once your organization runs Claude on Microsoft Foundry beyond a single team, policy is how "our standards" stops depending on everyone reading the wiki.
What's worth standardizing for Claude on Foundry
Good policy candidates come straight from Foundry's documented configuration surface:
Network posture. Foundry resources support disabling public network access and adding Azure Private Link private endpoints, or restricting the public endpoint to selected IP addresses. If your security baseline says "no publicly reachable model endpoints," a policy checking public-network-access settings on Foundry resources is the natural enforcement point — auditing violations at minimum, denying them where you are confident.
Region placement. Claude deployments are only available in supported regions — Microsoft documents Global Standard deployments in East US2 and Sweden Central, plus a US Data Zone Standard option for certain Hosted-on-Azure models — and your own data-governance rules may narrow this further. Azure's generic allowed-locations policy pattern covers resource placement; note that a Foundry deployment attempted in an unsupported region already fails with a "Region not available" error, so policy here mostly encodes your stricter subset, such as requiring Data Zone deployments for US-scoped workloads.
Tagging for cost attribution. Claude usage on Foundry bills as Claude Consumption Units through Azure Marketplace, appearing as a single CCU line in Azure Cost Management. Required-tag policies on the resource group or resource (team, cost center, environment) are what let you slice that spend later — see tags and cost attribution.
Audit first, deny later
The effect you choose changes the organizational dynamics. Audit is non-blocking: existing and new resources are evaluated, violations appear on the compliance dashboard, and platform teams follow up. Deny is a hard gate: the non-compliant deployment simply fails at creation time. The proven rollout sequence is audit first — run it for a few weeks, review what lights up, fix false positives in the definition — then flip the vetted rules to deny. Jumping straight to deny with an untested condition is how platform teams end up blocking a legitimate Friday-afternoon deployment and burning goodwill.
Writing and assigning the definitions
A definition is a JSON document: a condition block matching resource type and properties, plus the effect. Practical guidance:
Verify property paths empirically. Policy conditions reference resource properties via aliases, and neither Microsoft's nor Anthropic's Claude-on-Foundry documentation publishes a Claude-specific policy reference — this is generic Azure Policy applied to Foundry resources. Inspect an actual Foundry resource's JSON (the portal's resource explorer or CLI show you the real property names) and consult current Azure Policy documentation for the available aliases before writing conditions. Check Azure's built-in policy catalog first, too — built-ins for public-network-access, allowed locations, and required tags may cover you without custom JSON.
Assign at the highest sensible scope. A management-group assignment covers every current and future subscription beneath it; per-resource-group assignments invite drift. Use exclusions sparingly, and parameterize definitions (allowed regions as a parameter, for instance) so one definition serves multiple environments.
Watch the compliance view. Assignment without review is theater. Fold the compliance dashboard into an existing operational cadence, and treat a rising violation count as a signal that either enforcement or education is lagging.
One boundary to be clear-eyed about: Azure Policy governs Azure resource configuration — the management plane. It does not inspect prompts or responses, and it cannot see per-request behavior; those concerns belong to content-safety handling, RBAC, and diagnostic logging. Policy's job is narrower and extremely useful: every Foundry resource in the estate matches the network, region, and tagging standards you wrote down.
Where to go next
Define the standards themselves in private endpoints and Foundry regions, then automate provisioning with Terraform or ARM templates so compliant is also the easy path.