In a quarterly access review, how does the management-API audit record tell you which granted permissions a principal has actually used?

## Why the record is the right instrument Access reviews fail in a predictable way: a reviewer is shown a list of permissions and asked whether each is still needed, has no way to tell, and approves the lot. The management-event record replaces the guess with an observation. It contains, for the review period, every management operation each principal actually performed, so the question becomes *what has this identity done*, which is checkable, instead of *what might this identity need*, which is not. The comparison is a set subtraction: - **granted** — the actions the principal's permissions allow - **used** — the distinct operations recorded as performed by that principal in the window - **candidates** — `granted` minus `used`, the permissions that exist but have not been exercised - **blocked** — operations the principal attempted and the access model refused, collected separately That last set is the one reviewers forget, and it is the most actionable. A refusal is either a legitimate caller with a missing grant — usually a broken job somebody has been working around — or a caller reaching past its remit. Either way it is a finding, not noise. ## The window is the whole design The single most damaging mistake is a review window shorter than the estate's slowest honest cycle. Real work has periods measured in months: 1. A quarterly financial close that touches an export pipeline four times a year. 2. An annual recovery drill that exercises restore permissions once. 3. A certificate or key rotation on a yearly schedule. 4. A seasonal capacity change run twice a year. Revoke on a thirty-day observation and the first three of those vanish, and their absence is discovered at the worst possible moment — during the close, during the drill, at expiry. So the window must be at least as long as the longest legitimate cycle you can name, and where it cannot be, the reviewer must be told that the evidence is weak for that class of permission rather than shown a confident "unused". ## Where the evidence is genuinely weak Three limits should be stated whenever the output is handed to someone who will act on it: | limit | why it matters | |---|---| | operations on data may not be recorded | if only management events are captured, a principal that reads stored contents all day can look idle | | a shared identity collapses attribution | one automation credential used by several teams produces one merged usage set, and none of it maps to a person | | the record shows the operation, not the grant | one action can be authorised by more than one permission, so removing the obvious one may change nothing | The third is subtle and worth stating precisely: the audit record answers *which operation was called and whether it succeeded*. Which permission permitted it, and whether another permission would have permitted it anyway, is a question you answer by reading the access model, not the events. Treating usage data as a map of the permission graph is the error that produces removals with no effect and a false sense of progress. ## Making the removal safe Because the evidence is good but not complete, the removal is staged rather than immediate: 1. **Produce the candidate list** from the window, per principal, with the observed usage attached so a reviewer can see the basis. 2. **Narrow before deleting** where the platform allows it — reduce a broad action to the specific operations observed, or add a condition, rather than removing the grant outright. 3. **Watch the refusals for a full cycle.** Denied operations after a tightening are exactly the feedback the review needs, and they arrive in the same record. This is the step that makes the whole thing safe, because the mistake announces itself as a denial rather than as a silent breakage. 4. **Then delete**, and record the date, so the next review starts from a known baseline instead of re-deriving everything. ## What this is and is not evidence of Used correctly, the record is evidence that a permission has not been exercised in a stated window by a stated identity. That is a strong argument for removing it, and it is not the same claim as "this permission is not needed" — which is a judgment made by a human who knows what the identity is for. Reviews that present the first as if it were the second get their removals reversed after the first outage, and the next review is treated as noise. The credibility of the process is worth more than any individual permission it removes.