Borrowing a technique from deployment for policy specifically
A canary deployment releases a change to a small, limited subset of traffic before rolling it out everywhere, so that a problem shows up on a bounded scale rather than being discovered only once it's already affecting the whole system. This is standard practice for application code in many organizations. Authorization policy changes carry an analogous risk — an unintended consequence that's much cheaper to catch small than to catch after it's already applied to every request — and the same technique applies directly.
A policy change is often treated differently from a code change, deployed all at once on the theory that policy is 'just configuration' rather than something that needs the same deployment discipline. But an incorrect policy change can be just as consequential as a code bug, sometimes more so, since it can grant or deny access at a scale a code bug in one feature typically wouldn't touch.
Choosing a canary subset that would actually catch the problem
The canary subset for a policy rollout has to be chosen deliberately, broad enough to include the categories of request the change might plausibly affect — not so narrow that a real problem simply doesn't happen to appear during the limited exposure. A canary that never touches the part of the system the bad change actually affects provides false confidence rather than real protection.