Review and decide exception requests

A workflow for AI Agent Security

Governance that only says no gets worked around. When a policy blocks an action that was legitimate, such as an agent helping during a production incident, the alternative to an exception is someone turning the policy off. Exception requests give you a third option: the requester asks, an approver decides, and the access granted is scoped, time-bounded, and audited. This workflow shows you how to work the approval queue.

Scope of this guide

This workflow covers reviewing and deciding exception requests as an approver, and checking approvals afterward. It does not cover the requester's side of the flow or writing the policies that generate the requests.

Prerequisites

You have administrator access to the tenant.
At least one policy is at Block or Require Approval, so blocked actions can generate requests.

Steps

Step 1: Read the queue

Go to Protection > Exception Requests.
Read the summary cards. Pending is the work in front of you, Oldest pending is how long the longest-waiting request has waited, and Median time to answer is how quickly requests are being decided. Approved today and Denied today count the decisions already made today.
Select the Pending tab.

The other tabs show All requests, Approved ones, Self-approved ones, and Denied ones. A Self-approved request is one a developer approved themselves, which a policy at Require Approval allows.

Step 2: Review a request

Read the request's row. Agent and Host show which agent was blocked and on which machine, Blocked call shows what it tried to do, and Blocking policies shows which policies stopped it.
Select the request to open its details panel.
Read the requester's justification against the blocked call. The justification explains why the requester wants the action; the blocked call is what they would actually be granted, and the two are not always the same size.
Check Requested, which is how long the requester asked for the exception to last.

Step 3: Decide the request

To deny the request:

Select Deny.
Enter a Denial reason. A reason is required, and it is the only thing the requester sees, so say what to do instead.
Select Deny again to confirm. Denying closes the request, and the requester may submit a new one.

To approve the request:

Select Approve.
Check the Grant window. It starts at the length the requester asked for; shorten it if the work needs less.
Enter an approval note if you want one. It goes to the audit trail.
Select the approve button again. It now names the window, such as Approve for followed by the duration.

The approval reaches the endpoint shortly after you approve.

Step 4: Revoke an approval you no longer need

Select the Approved tab and open the request.
Select Revoke grant.

Revoking reaches the endpoint in around 15 seconds. A self-approved grant is managed on the endpoint and cannot be revoked here.

Verify the results

Confirm the decision appears against the request under the Approved or Denied tab, and that the Approved today or Denied today card has moved.

Before concluding the queue is clear, check the tab and your filters. An empty list describes the current tab and filters, not the whole queue.

Next steps

Review the Self-approved tab regularly. Those grants were never seen by an approver, so check that each one was reasonable.
Review the policy behind any repeatedly requested call. A call that generates frequent exceptions may need a policy change rather than another exception.
Agree with your team what a sufficient justification looks like, so decisions are consistent between approvers.