The Azure Policy Baseline That Protects MSP Customers from Themselves

Why Guardrails

Azure has almost infinite capabilities. When I started the shift in migrating all my clients from on-prem VMware to Azure, I realized one thing: I need to set up guardrails for what we are doing.

At the time the major issues were people setting up crypto infrastructure on your dime. Now it's things like AI automation being hosted on your dime. These things can bankrupt a company. It's not always attackers. Sometimes it's internal employees by accident.

This is why part of building a good Azure landing zone is building the guardrails. What VMs can my staff deploy? In what regions? How do I ensure logging and backup aren't forgotten? How do I protect against accidental modifications? Every part of these questions needs to have intention behind it.

I posted recently about FaceCheck being needed and my Azure Policy blocking me. This was a great example. I'm setting up a paid service that needs to be intentional, otherwise cost can run rampant in my infrastructure very quickly: lnkd.in/p/e-7KevrE

Shortly after I came across this thread on Reddit. This is another reason why these settings have to be controlled. It's not that every aspect is controlled directly through a policy, but it aids in the system that has to go in place to prevent and defend against these. It's one step of many involved in controlling and alerting on this behavior.

r/AZURE: Azure account compromised: $550k charged for unauthorized Claude usage from Azure Marketplace.

It's not that every aspect is controlled directly through a policy, but it aids in the system that has to go in place to prevent and defend against these. It's one step of many.

Section 2: The Azure Policy Initiative: General Governance (Policies 1–15)

Policies 1–15 were part of the original objectives and build. These apply to every managed customer regardless of industry and cover the foundational questions: location controls, compute guardrails, backup, tagging, monitoring, and resource protection.

Section 3: HIPAA Controls (Policies 16–35)

This is where the HIPAA controls come in. These were driven by working in the medical industry. For non-healthcare customers the security rationale still holds. The regulatory citation just does not apply.

Section 4: Policy 16 Is a New One

Policy 16 was added after realizing how critical it would be to secure AI. This was not part of the original build. It came from watching the threat landscape shift from crypto mining to AI inference workloads. The attack surface changed. The policy had to change with it.

After coming across the Reddit thread, I went into my own tenant to test this theory. I wanted to see if this policy would successfully block the kind of deployment that generated that $550k bill. The video below walks through the full test.

The resource providers in scope:

Section 5: The Safety Net

Anyone who knows me or has read my Conditional Access logic and theory knows this: you are only as good as the safety net you build.

Policy is the start. But you also need budget alerts and detection that let you know if something was deployed that shouldn't have been and somehow got around things, if someone attempted to deploy something they shouldn't have (great training exercise), or if budgets are climbing too fast and you need to evaluate and reduce spend. Each of these could have stopped or severely diminished that $550k bill.

A billing alert setup that actually works has three layers:

Budget alerts at multiple thresholds

In Cost Management, create a budget for each subscription with alerts at 50%, 80%, and 100% of expected monthly spend. Set recipients to include both the subscription owner and a shared MSP operations mailbox. The 50% alert is not a panic trigger. It's an early warning that something has changed. Investigate it.

Anomaly alerts

Azure Cost Management includes anomaly detection that fires when spending deviates significantly from the predicted pattern. Enable it at the subscription scope for every managed customer. A subscription that normally spends $200/month and suddenly spikes to $2,000/day will trigger an anomaly alert before it hits the 50% budget threshold, because the rate of change is the signal, not the absolute number.

Enable it under Cost Management, Cost alerts, Anomaly alerts. Set the threshold sensitivity to Medium for most customers and High for any subscription with a debit card or no EA spending cap.

Action groups that do something

An alert that sends an email is better than nothing. An alert that sends an email, fires an SMS, and triggers a Logic App or Azure Automation runbook that disables the subscription is a safety net. Build the action group once and reuse it across all customer budget alerts.

Weekly spend alert from Azure Cost Management, the kind of signal that would have caught the Reddit post's $550k bill before it became unrecoverable.

Section 6: Detecting the Block

Policy 16 blocks the deployment. That's the lock. But knowing someone tried the door is equally important, and this is where most baselines stop short.

After extensive testing against a live LAW with all diagnostic categories enabled, the finding is this: Azure Policy deny events do not appear in AzureActivity when you filter on CategoryValue == "Administrative". Every guide, every example query, and every detection article filters on Administrative. They all miss the blocked attempts entirely.

Policy deny events log under CategoryValue == "Policy" with OperationNameValue == "MICROSOFT.AUTHORIZATION/POLICIES/DENY/ACTION". That combination is where the signal lives.

Production Alert Query

AzureActivity
| where TimeGenerated >= ago(30d)
| where CategoryValue == "Policy"
| where OperationNameValue == "MICROSOFT.AUTHORIZATION/POLICIES/DENY/ACTION"
| extend Props            = parse_json(Properties)
| extend Policies         = parse_json(tostring(Props.policies))
| mv-expand Policy        = Policies
| extend
    PolicyFullPath        = tostring(Policy.policyDefinitionId),
    ResourceFullPath      = tostring(Props.entity),
    ResourceType          = tostring(ResourceProviderValue),
    ResourceLocation      = tostring(Props.resourceLocation)
| extend
    PolicyName            = tostring(split(PolicyFullPath, "/")[-1]),
    AttemptedResource     = tostring(split(ResourceFullPath, "/")[-1]),
    AttemptedType         = tostring(split(ResourceFullPath, "/")[-2])
| project
    TimeGenerated,
    Caller,
    CallerIpAddress,
    ResourceGroup,
    ResourceType,
    AttemptedResource,
    AttemptedType,
    PolicyName,
    ResourceLocation,
    SubscriptionId,
    CorrelationId
| order by TimeGenerated desc

Live results from IAC-AZE2-AAD-LAW: four blocked AI Search deployment attempts, each showing the caller, resource group, attempted resource name, service type, and policy that blocked it.

IAC-AZE2-PolicyDenied-Alert fired September 25, 2026 at 13:50 UTC. AttemptedResource: test-ai-search. AttemptedType: searchServices. Caller: Jhope@conditionalaccess.tech. End-to-end proof the detection works.

The policy is the lock. This query is the camera. Running Policy 16 without this alert is knowing the door is locked but never checking the footage.

Section 7: What Policy Doesn't Cover

Azure Policy intercepts ARM deployment requests. It does not control what a user does inside a Marketplace web session that never touches ARM, and it does not block SaaS offers purchased directly through an ISV's portal using an Azure payment method attached at the billing account level.

The complete control stack for AI spend risk has three layers. Policy 16 covers only one of them.

Billing-level controls: For MCA accounts, set the Marketplace purchase policy to "Free" or "No" under Cost Management + Billing, Billing profiles, Policies. For EA accounts, enterprise administrators can set Marketplace to "Free/BYOL SKUs only." These controls block SaaS subscriptions that do not go through ARM. (Microsoft Learn: Purchase control options)

Private Marketplace: Private Marketplace restricts which offers are visible and purchasable for your tenant. Combined with billing controls and Policy 16, it closes the remaining gap. Enable it under Marketplace in the Azure portal and explicitly approve the offers your customers are permitted to use.

Policy 16 catches ARM-deployed resources. Billing controls catch Marketplace SaaS subscriptions. Private Marketplace catches portal browsing. The Reddit post's $550k charge would have been stopped by billing controls before ARM policy even applied, because a Marketplace SaaS subscription often does not create a Microsoft.SaaS/resources ARM object until after the billing relationship is already established.