The entitlement creep problem nobody has time to fix

High-growth companies don’t choose to break least privilege. They get there the same way they get to $10m ARR: by moving fast, copying what works, and dealing with consequences “later”. Then “later” shows up as an email during dinner: “Does anyone know why this service account can delete production buckets?”

NIST’s definition of least privilege is clean and unforgiving: restrict access to the minimum necessary for users (and processes acting for them) to do their tasks. The problem is that scale-ups rarely fail on intent. They fail on operational physics.

1) Growth Turns IAM into a Copy-Paste Machine

In early stages, access control is tribal knowledge and a handful of admin accounts. At 50–500 people, you scale by cloning:

• Terraform modules with “temporary” IAM blocks
• Kubernetes RoleBindings copied from the last service
• Cloud roles assigned at subscription/project scope because it’s quicker
• SaaS “Admin” granted because the integration needs it right now

This isn’t incompetence. It’s throughput.

And the environment itself is working against you. Hybrid and multi-cloud are now normal (not “future plans”), meaning your identity surface area multiplies. CSA found 63% of organizations use more than one cloud provider, 82% run hybrid, and 59% cite insecure identities and risky permissions as the top cloud risk. 

That’s the first failure mode: least privilege is designed once, but permissions multiply daily.

2) Entitlement Creep is The Natural State of Fast Teams

The nastiest part of “least privilege in the cloud” is that permissions aren’t just “roles”. They’re entitlements: the effective actions an identity can perform across cloud services, data platforms, and SaaS apps.

Two things make entitlement creep inevitable in scale-ups:

A) Nobody owns removal.

Granting access is a visible action tied to delivery. Removing access is invisible work tied to the risk of breaking production. Guess which one wins sprint planning.

B) Stale credentials survive because nothing screams loudly enough.

In AWS, 59% of IAM users have an active access key older than one year, and over half of those credentials haven’t been used in 90+ days. That’s dormant capability and corporate identity threats sitting around like an unlocked shed full of power tools.

AWS is effectively acknowledging the same operational challenge: IAM Access Analyzer now flags unused access and suggests policy refinements, because manual clean-up doesn’t scale. But there’s friction. These analyses rely on AWS CloudTrail and related data sources, which means you’re paying for the logging, storage, and queries that make those insights possible. Costs that rise quickly in large or busy environments. The output isn’t plug-and-play either: recommendations are often broad, require context on how identities are actually used, and can be risky to apply without careful validation. In practice, teams still need to interpret, test, and stage changes, which limits how often this gets done and how far it really reduces excess access.

3) The Psychology of Access Hoarding is Rational (and Annoying)

If you want a least-privilege program that survives growth, you need to stop treating developers and SREs like villains.

People hoard access because:

• They fear being blocked during incidents (“I’m on call; don’t nerf me.”)
• They don’t trust approvals to be fast and sane
• They’re rewarded for shipping, not for shrinking blast radius
• They’ve been burned by “security says no” with no alternative path

In short: access is experienced as speed, and removal is experienced as risk. Unless you change that experience, your “least privilege” initiative becomes a politely ignored poster.

4) Why “RBAC Cleanup Projects” Fail in Scale-Ups

Classic least privilege programs often look like:

1. Inventory roles
2. Redesign RBAC
3. Run quarterly access reviews
4. Trust everyone at their word

But scale-ups don’t have stable job functions, stable systems, or stable teams. Joiner-mover-leaver is a game of whack-a-mole with contractors, consultants, and leavers not in HR systems. The org chart is basically a time-lapse video.

If you want Least Privilege In The Cloud to work during growth, you need guardrails that match how teams actually operate.

5) Guardrails That Don’t Kill Speed

The winning pattern is not “remove all privilege”. It’s: remove standing privilege and make access measurable.

A) Just-In-Time Access And Zero Standing Privileges

UK NCSC frames Privileged Access Management around Just-In-Time and Just-Enough administration. CISA/NSA guidance also recommends time-based access for privileged accounts (JIT provisioning when needed). 

This is the unlock for scale-ups: give engineers what they need when they need it, with expiry by default, rather than permanent admin “just in case”.

What it looks like in practice:

• Time-boxed elevation (minutes/hours, not weeks)
• Step-up auth (MFA, device checks)
• Approvals that can be policy-based (auto-approve low-risk, escalate high-risk)
• Full audit trail that compliance teams can actually query

B) Organization-Level Guardrails, Not Team-by-Team Heroics

Put the hard boundaries at the top:

• Forbidden actions blocked centrally (so nobody can “accidentally” create super-admin everywhere)
• Permission boundaries / constraints so roles can’t grow past a cap
• Breakglass accounts that are monitored, rotated, and used only under strict rules

This keeps teams fast inside a safe sandbox.

C) Stop Using “Basic/Broad” Roles In Production

Google Cloud is blunt: basic roles, like Browser, include thousands of permissions and shouldn’t be granted in production unless there’s no alternative; use limited predefined or custom roles. 

This matters because broad permissions are the fastest route from “minor compromise” to “full environment remodel”.

6) What a Modern Solution Needs

If you want least privilege to survive high growth, you need a platform approach that does three things continuously:

1. Continuous Entitlement Visibility
   Not “who has access to the app”, but “who can do what right now, across cloud and SaaS, including non-human identities.”
2. Entitlement-Aware Workflows
   Approvals and self-service that understand the specific permissions requested, with time limits, auto-revocation, and evidence capture, so engineers don’t wait days for the access they need in minutes.
3. Automated Right-Sizing And Proof
   Detect unused privileges, stale keys, and over-privileged identities; recommend safe reductions; produce audit-ready reports that show least privilege improving over time.

This is where scale-ups stop arguing about philosophy and start proving outcomes.

And the outcomes matter. IBM’s Cost of a Data Breach report puts the average global breach cost at $4.88M. If over-privilege turns a small compromise into a big one, least privilege isn’t a “nice-to-have”. It’s a cost-control mechanism.

Give ‘em What They Need

Least privilege fails in high-growth companies because it’s treated as a one-off design exercise, while growth creates a constant stream of new entitlements. The fix is not “more reviews”. It’s operational guardrails: zero standing privileges, just-in-time access, continuous entitlement visibility, and automated right-sizing. Security should be a speed enabler, not the department of “computer says no”.