Forum Discussion

KrisPark's avatar
KrisPark
Occasional Reader
Nov 05, 2026

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

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

Access Management
Authentication
Conditional Access
Identity Management
identity protection
microsoft entra
Microsoft Identity Manager

2 Replies

  • KrisPark's avatar
    KrisPark
    Occasional Reader
    Nov 09, 2026

    Thanks, Jamony. I agree with the distinction between identity validation and the resource API's final authorization decision.

    Your point about loading current resource state is particularly relevant. I think there is another boundary worth examining: what happens when the resource state changes after AuthorizeAsync evaluates the operation but before the application performs the actual write?

    For example, if the resource version, ownership, reporting relationship, or relevant business attributes change during that interval, should the application bind the authorization decision to the resource version it evaluated and reject execution if that version has changed?

    I'm interested in whether resource-based authorization is typically combined with optimistic concurrency or another execution-time consistency mechanism to close that gap.

    Thanks for the practical implementation perspective.

  • Jamony's avatar
    Jamony
    MCT
    Nov 06, 2026

    Yes. A workload can retain a valid access token while losing permission for a particular operation because application-specific conditions have changed. The responsibility is shared, with the resource API making the final authorization decision.

     

    Entra establishes identity and evaluates applicable identity policies. The API must validate the access token and enforce the required application roles or delegated scopes, plus access to the specific resource. A previous approval should not replace that resource-level check.

     

    For implementation, load the current resource state, evaluate the operation's authorization requirements, and reject execution when those requirements no longer hold. ASP.NET Core supports this through resource-based authorization with IAuthorizationService.AuthorizeAsync.

     

    Continuous Access Evaluation helps with supported identity changes, but its workload-identity support currently covers Microsoft Graph and eligible single-tenant service principals; managed identities are excluded. It does not automatically enforce your custom business conditions. Test revocation and context changes explicitly.