Testing for the case nobody designed for
Ordinary testing verifies that a system behaves correctly against the scenarios its designers anticipated: the right user gets the right access, the wrong user gets denied. A red team approaches the same system with an adversarial goal instead — not whether it works as intended, but what happens if someone deliberately tries to make it fail — probing for the gap between what the designers thought they built and what they actually built.
For authorization specifically, this means actively trying the things a threat model identifies as possible: escalating from a low-privilege account, exploiting a confused-deputy pattern, replaying a token past its intended window, crossing a tenant boundary that should be closed. These are exactly the failure modes that are easy to reason about in the abstract and easy to miss in the concrete implementation.
Findings are only useful if they change the design
A red team exercise that produces a report nobody acts on is theater. The value is in feeding findings back into the system's design — closing the specific gap found, and more importantly asking whether the same class of gap exists anywhere else the exercise didn't specifically probe. Treating each finding as an isolated bug to patch, rather than a symptom of a pattern to check for elsewhere, tends to leave the next instance of the same mistake in place.