A dollar-based over-provisioning control cannot see access that is free. If your only guardrail is a cost budget, you can hand out tens of thousands of permissions nobody needs and the budget will read zero.
On one client, a tail catch-all add-on role handed out 76,276 grants that users did not already hold, spread across about 102 users. The over-provisioning budget flagged none of it. Every one of those grants was a Team Members privilege, which is free on a seat the user is already paying for, so in dollar terms the budget was correct. It just was not measuring access at all.
Why a cost budget is blind here
An over-provisioning budget asks one question: does this extra access push a user into a more expensive license tier? If the answer is no, the budget is satisfied. A Team Members privilege handed to a user who already has an Activity or Full seat adds no cost, so it passes the budget every time, no matter how many of them there are.
Tail catch-all add-ons are the worst case for this blindness. They exist to sweep up the leftover privileges that did not cluster cleanly into a role, and they tend to be large. Pointed at a user as a convenience, a catch-all can deliver thousands of privileges the user never had, every one of them free, every one of them invisible to a cost control. The budget reports a clean run while least privilege quietly collapses.
Least privilege and cost are different objectives
This is the core confusion worth naming. "Cheap" and "minimal" are not the same goal, and optimizing for one does not deliver the other.
Cost optimization asks: what is the smallest license bill that still covers what people actually do. Least privilege asks: what is the smallest set of permissions that still lets people do their job. A free privilege is invisible to the first question and fully in scope for the second. A user loaded with 700 free grants they never use is a least-privilege failure and a cost non-event at the same time.
If the only number anyone watches is dollars, the organization will systematically drift toward "everyone can touch everything, as long as it is free." That is an audit finding and an attack-surface problem, and the cost dashboard will stay green the whole way.
You need a non-dollar guardrail
The guardrail that actually catches this is not a budget. It is an explicit list of grants not held today: for every assignment a package would ship, the specific privileges it would deliver that the user does not already have. That list does not care what a privilege costs. It counts access, which is the thing least privilege is about.
In practice that means two things:
- - For an add-only delivery, build a scenario that does not include a tail catch-all at all, so the leftover privileges are not swept onto users wholesale.
- - Run an access-level check that produces, per user, the grants they would gain that they do not hold today, and the access that would not carry forward into the new design. Put both lists in front of a human for sign-off.
The 76,276 number only became visible because someone counted grants instead of dollars. That is the whole lesson. The control has to measure the thing you are trying to protect.
Bottom line
A cost budget polices your license bill, not your access. Free over-provisioning is real over-provisioning, and it will sail through a dollar-based control untouched. Keep the budget for what it is good at, and add an explicit "grants not held today" list as a separate, non-dollar guardrail. If nobody can tell you how many permissions a change hands out for free, nobody is watching least privilege.
Frequently asked questions
If the extra access is free, why does it matter?
Because access is risk, independent of cost. Every unnecessary grant widens what a compromised or misused account can do and enlarges what an auditor will question. Free in dollars is not free in exposure.
Can we just raise the over-provisioning budget's sensitivity?
No. The budget measures cost. No sensitivity setting makes a zero-cost grant show up as a cost. You need a different metric, one that counts access, running alongside it.
What is a tail catch-all add-on and why use one at all?
It is a role that collects the leftover privileges that did not fit any clean role. It exists for convenience, to avoid leaving loose ends. The point here is that convenience is exactly where free over-provisioning hides, so an add-only delivery should avoid it.