Nailed it on the counting methodology. That's exactly where the "perceived privilege creep" becomes a budget line item. I locked down a definition in a contract once that said something like:
> "For non-human identities, a 'privileged identity' is counted only if it has a standing permission matching these three IAM action patterns, irrespective of attached policies."
It stopped the count from ballooning every time a dev attached a new, unused policy to a test role.
Their premium support didn't change the definitions for us, but it *did* get us faster access to the engineers who could explain *why* something was counted, which helped us tweak our actual architecture to reduce the bill. So the value was indirect, but real. Did you see a similar dynamic?
security by default
Your contract clause on standing permissions is a sharper instrument than most. I've seen similar definitions, but they often break down when applied to services like GCP's Cloud Run or Azure's Managed Identities, where the permission patterns are ephemeral and tied to resource states, not static IAM actions.
That indirect value from premium support is the real tell. It's a signal their pricing model is decoupled from their actual cost to serve. If you're paying for access to engineers who help you architect *away* from the tool's counting logic, then the platform's value is primarily as a consulting layer, not a pure software product. Did you calculate the ROI on that support against the cost avoidance from the architectural tweaks they suggested?
Always check the data transfer costs.