When Authorization Changes Before Execution, Who Is Responsible for Validating Authority?

I've been exploring an architectural security question at the intersection of Microsoft Entra Workload Identity, Conditional Access, and Zero Trust.

The question is:

Can an identity remain successfully authenticated and authorized while the authority to perform a specific action becomes invalid because the execution context has changed?

Consider a practical scenario:

1. A workload identity is successfully authenticated.
2. Authorization is granted for a particular operation.
3. Before the operation executes, the surrounding conditions change.
4. The application proceeds toward execution using previously established authorization.

At that point, who is responsible for validating that the action is still authorized under the current execution context?

Is that responsibility primarily held by:

• Identity layer: Establishing and maintaining the identity and its credentials?
• Policy enforcement layer: Evaluating changing conditions and authorization policies?
• Application layer: Validating authority immediately before executing an operation?
• Shared responsibility: Coordinating enforcement across all three layers?

I'm not suggesting that Microsoft Entra currently fails to address this scenario, nor am I assuming that one layer should own the entire problem.

I'm interested in understanding how the Microsoft community approaches the architectural boundary between:

• Workload identity lifecycle
• Delegated authorization
• Continuous evaluation of context
• Runtime policy enforcement
• Execution-time action validation

This question becomes particularly interesting as organizations introduce autonomous AI agents and increasingly delegate operations to workloads that can act across multiple services.

My question to the community:

After authentication succeeds and authorization is granted, where should responsibility for validating continued authority reside when the execution context changes before an action occurs?

Is this fundamentally an identity problem, a policy-enforcement problem, an application responsibility, or a combination of all three?

I'd particularly welcome perspectives from Microsoft Entra engineers, identity architects, Conditional Access practitioners, and developers working with workload identities and AI agents.

I'm interested in both practical implementation experiences and broader architectural principles.

Thanks for sharing your perspectives.

Kris Park
Master Combine | Sovereign Engine Assurance Group