Microsoft's November 5, 2026 Azure Policy guidance examines rules that evaluate the caller as well as the resource. The article explains existing identity-aware capabilities and highlights identity-based exemptions that have recently reached general availability. It is fresh implementation guidance rather than a launch of the entire identity-aware feature set. Microsoft guidance.
For a governance team, the practical question is whether a proposed rule produces the intended decision for the actual caller. My first pilot would combine a tightly scoped resource operation with a small, agreed identity matrix.
Identify What the Rule Is Checking
Microsoft Learn documents requestContext().identity fields including the caller type, client application ID, authentication context, and caller object identifier. It recommends handling missing identity fields with tryGet rather than assuming every request contains them. Caller identity reference.
I would have the rule author explain which identifier answers the team's security requirement. An application identifier and a caller object identifier describe different parts of the request; the review should name the one it intends to evaluate.
Keep production identifiers out of public examples. Within the approved internal record, associate each test identity with its owner and intended purpose so that the evidence remains understandable later.
Define the Expected Decision Matrix
My proposed matrix would include an approved deployment identity, an unapproved identity, an expected human-operated request, and a case with a relevant missing claim. Add another case where the resource itself violates the team's configuration requirement.
Write the expected outcome for each before testing. The reviewer should be able to connect the result to the intended caller condition and the resource operation in scope.
Use a deliberately disposable target in an isolated environment. If deletion protection is part of the design, agree on a separate test and recovery procedure for that action. Keep unrelated resources outside the exercise.
Use Request Evidence for Acceptance
The current identity-function guide says request-time enforcement still applies, while compliance scans for these policies are marked NotApplicable. It recommends narrow pilots and pairing caller-aware rules with resource-configuration policies. Evaluation boundary.
I would make that boundary explicit in the acceptance record. A reviewer needs the outcome of the relevant request and enough diagnostic context to identify the assignment and rule being evaluated.
Keep configuration-compliance reporting as its own review item. Give the operations team a short explanation of which evidence establishes caller-aware behavior and which evidence describes the resource's ongoing configuration.
Review Exemptions as Controlled Decisions
Microsoft documents identity-based exemption selectors for specific principals and security groups. Its exemption structure also supports an expiration time; the exemption object remains for record-keeping after that time, while the exemption stops being honored. Exemption structure.
My proposed exception record would identify the policy assignment, intended beneficiary, business reason, approver, and review date. Ask the service owner what should happen when the exception ends.
For an incident-response group, verify the intended member and a non-member against the same bounded scenario. Keep group membership ownership visible in the review, because the operational decision depends on who receives that exception.
Before setting an expiration, agree on how the workload will operate afterward. A date should reflect a reviewed transition plan with an accountable owner.
Rehearse the Change and Recovery Path
Microsoft's guidance discusses staged assignment controls and progressive exposure. Rollout guidance.
I would preserve the previous assignment settings and test the approved recovery procedure within the pilot. Record the observed request result after the configuration change rather than assuming a propagation time.
Expand only when the relevant application and deployment owners can explain the evidence. A new scope should bring its own identity inventory and operational checks, even when it reuses the same policy definition.
Practical Cloud Engineer Takeaway
Name the identity field that matches the intended requirement.
Test approved, unapproved, and missing-claim cases.
Use request outcomes to verify caller-aware enforcement.
Give exemptions an owner and an agreed exit plan.
Rehearse recovery before expanding assignment scope.
Who Should Care?
Azure governance engineers, platform security teams, and deployment owners introducing caller-aware controls into shared environments.
Bottom Line
The latest guidance gives teams a useful way to review who is making a resource change. A defensible rollout connects the caller condition, actual request result, exemption decision, and recovery evidence.
No policy definition, assignment, exemption, identity, resource, or Azure request was changed or executed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments