DevOps moves fast, but access control still thinks it’s 2012

If you want to understand modern identity risk, don’t start with policies or frameworks. Start with a cloud engineer on a normal Tuesday.

Not a breach. Not an audit. Just a working day inside a fast-moving DevOps team, juggling infrastructure changes, pipelines, incidents, and the quiet background noise of access that rarely behaves in the way anyone expects.

“To see what is in front of one’s nose needs a constant struggle.” 
- George Orwell [1946]

This is where identity problems are born.

08:45: Stand-up ends early (a good sign)

Our cloud engineer starts the day with what passes for normal now:

• A bucket of Espresso worthy of Mordor
• Multiple cloud providers
• Infrastructure defined in code
• CI/CD pipelines are deploying continually
• Shared environments across teams

From an access perspective, a lot is already in motion. Roles exist. Permissions are attached. Service accounts are running jobs created months ago. Machine identities and AI agents do whatever it is they do. Nobody touched access this morning, yet plenty of access already exists.

For a cloud engineer, this feels efficient. For security, it’s invisible risk.

Standing privileges are active before the first coffee.

09:30: A “small” change blocks a deployment

A pipeline fails. Nothing dramatic. One missing permission.

Maybe it’s listing a single storage bucket. Maybe restarting a resource group. Maybe reading logs from a production service. All very reasonable tasks for a cloud engineer doing their job.

What usually happens next is predictable:

In most orgs, a request is submitted via a login to a ticketing system and filing a ticket.

Someone approves it quickly.

A broad breakglass role is granted “just to unblock things.”

The role works. The deployment succeeds. Everyone moves on.

But that Espresso hasn’t kicked in yet, and the access sticks around.

This is where access quietly drifts from task-based to permanent, because roles are easier to reuse than to remove. Over time, engineers accumulate privileges they no longer need, not out of carelessness, but well-meaning convenience.

11:00: Infrastructure changes faster than identity

‘Terraform apply’ creates new resources. Old ones disappear. Names change. Environments evolve. Identity rarely keeps pace.

IAM roles are static by nature. Cloud infrastructure is not. This mismatch creates what many teams now recognize as identity debt: permissions that made sense once, still exist, but no longer align with reality.

For a cloud engineer, this isn’t visible in dashboards. Everything works. Pipelines are green. No alerts fire. But access is now detached from intent.

13:00: Lunch, dashboards, and unanswered questions

Ask a simple question at this point:

• Who can access production right now?
• Which permissions were actually used today?
• What would an attacker inherit if a token leaked this afternoon?

In the bulk of organizations, nobody can answer this confidently.

Traditional IAM answers questions about roles and groups. Cloud engineers need answers about effective access: what is active, scoped, and usable at this moment in time.

That gap matters.

15:30: An incident that isn’t a breach (yet)

A third-party integration misbehaves. Logs show valid API calls. Nothing exploited. No malware. Just behavior nobody expected.

This is common.

Most modern cloud incidents don’t start with a vulnerability. They start with credentials that worked exactly as designed, long after the original need disappeared.

Often, the root cause looks like this:

• A service account granted broad access during a project
• Tokens never rotated
• Permissions never reduced
• Nobody remembered it existed

For a cloud engineer, this is frustrating rather than shocking. The system allowed it. The workflow encouraged it.

17:45: The workday ends (access should too)

The cloud engineer logs off. Their laptop closes. Their access, however, often doesn’t.

Standing privileges remain overnight. Service accounts continue running with the same scope. Temporary fixes quietly become permanent fixtures. Access creep, where users accumulate privileges they no longer require, begins. 

This is the moment modern access models are trying to fix.

Not by slowing engineers down, but by aligning access with how cloud engineers already work.

What “Good” Actually Looks Like for a Cloud Engineer

In teams that have modernized access properly, a few patterns stand out:

• Access is requested via the same tools engineers already use, i.e., Slack or Teams.
• Permissions are scoped to the exact task and resource
• Access is time-bound, by default, through just-in-time access
• Human and non-human identities are treated consistently
• Unused access expires automatically

Crucially, engineers don’t need to remember to clean up. The system does it for them.

This shifts access from something engineers hold to something they use.

Identity Needs to Behave Like Infrastructure

Cloud engineers already understand this model. Infrastructure is:

• Declarative
• Ephemeral
• Auditable
• Reversible

Access should behave the same way.

Instead of asking “who should be in this role?”, modern teams ask “what access is needed right now, for this task, in this environment?”

That mindset reduces blast radius without slowing delivery.

Why This Matters Now

Cloud-native operations amplify small access decisions. A single over-scoped permission can touch dozens of services across regions in seconds. For cloud engineers, the challenge isn’t security awareness. It’s tooling that respects how fast and fluid their work actually is. The best access models don’t fight DevOps. They follow it. Because in modern cloud environments, the problem isn’t that engineers have access. It’s that access outlives intent.

A cloud engineer’s day is difficult enough. Let’s be careful out there.