The problem with flat access models in cloud environments
In a SaaS app, access is a finite list: “Salesforce Admin,” “Jira Reporter on Project X.” You can sync every entitlement upfront and review them all in a campaign. Consider two real requests: a developer who needs Contributor access on one resource group for a four-hour deploy, and an AI agent that needs read access to a single Key Vault for one pipeline run. In a governance tool that flattens cloud entitlements into a list of identical-looking rows, neither request can be expressed precisely. The tool grants Contributor on the subscription, Reader on the management group. The blast radius of every grant grows because the tool can’t express anything narrower. Azure defines access as a (role, scope) pair, where a role assigned at a parent scope automatically flows down to every resource beneath it. Tools cope in one of two ways: materialize every inherited combination upfront (which produces thousands of identical entries and breaks at enterprise scale), or sync less and accept ungoverned blind spots. Neither option solves the problem. Representing this as a flat list causes real problems:- Sync failures and database bloat from trying to materialize every combination
- Unusable UIs where end users and reviewers face thousands of identical-looking entries with no hierarchy context
- Rubber-stamp access reviews where reviewers bulk-approve because the volume is unmanageable
- Governance blind spots from workarounds that restrict which resources get synced
How cloud infrastructure access works
Instead of pre-materializing every role-scope combination, C1 now stores access as bindings — one record per role assignment, at the scope it was granted. The resource hierarchy (management groups → subscriptions → resource groups → resources) is stored with parent-child relationships intact. Effective access is computed on demand rather than enumerated upfront. This means:- A role assigned at a subscription scope covers every resource beneath it, and C1 knows this — without creating millions of pre-materialized rows
- End users navigate a resource tree to select the scope and role they need, with breadcrumb navigation showing where they are in the hierarchy
- Reviewers evaluate the bindings that actually exist, not an explosion of inherited copies — a review that might have produced tens of thousands of identical line items now shows the handful of bindings that matter, each with its scope and inherited reach visible