The auditor has 42 tabs open, and the one that matters is a spreadsheet of IAM roles nobody has touched in eight months. A contractor who left last spring still has write access to a production bucket. A service account created for a one-week migration in 2023 is now the identity behind a nightly job in finance.

None of it tripped an alarm. It surfaced because someone finally ran the report.

That's how most cloud incidents start now. Not with a zero-day, but with a permission that was reasonable the day it was granted and stopped being reasonable a few sprints later. The audit doesn't create the risk. It puts a name on the standing credentials, the forgotten service accounts, and the RBAC missteps that undermine cloud security. Once the names are on paper, a routine review can turn into an incident report before the week is out.

The Contractor Who Never Really Left

A contract wraps, the invoice gets paid, and the offboarding ticket goes to whoever is on rotation that Friday. HR removes the badge. IT disables the email. The SaaS admin console, the cloud console, the CI runner, and the analytics workspace get handled by four different people on four different schedules, and one of them is on vacation.

Standing access outlives the person more often than most teams want to admit. According to a CloudEagle analysis, roughly half of employees carry excessive access, and it's common for users including contractors to retain SaaS access after their assignments end. The auditor finds the account. The incident starts when they check whether it's been used.

The Junior Engineer Who Got Promoted Three Times

Someone joins as a junior on the platform team. They pick up on-call. They rotate through the data group for a quarter, then move to a staff role on a different product.

Every step added permissions. No step took any away.

This is the additive career, and it's the most common shape privilege creep takes inside a healthy engineering org. It looks like trust. On an audit, it reads as a single identity with the combined blast radius of three teams. Role reuse and overly broad defaults tend to be the mechanism, and the person everyone likes usually ends up holding the keys.

The Service Account With No Owner

Human accounts at least have a manager. Service accounts have a Confluence page from 2022 and a Slack channel that's been archived.

The credential sits in a secrets manager. The job runs. Nobody knows what would break if you rotated it, so nobody rotates it.

These identities collect scopes the way a coat pocket collects receipts. A new integration needs one more permission, so someone grants it to the existing role rather than making a new one. Two years in, the account can read production data, write to a staging bucket, and assume a role in a sibling account.

The auditor asks who owns it. Nobody answers.

The Break-Glass Role That Nobody Broke the Glass On

Emergency roles exist for a reason. The trouble starts when they stop being emergency roles. A senior engineer assumes the elevated role to debug a Sev-1 at 2 a.m., forgets to drop it, and the session token lives on in a shell they haven't closed.

The NIST definition of least privilege is almost boring in its clarity: restrict access to the minimum needed to do the assigned task. That word "assigned" is doing all the work, because a break-glass role still assumed after the incident has ended is a standing admin credential in an emergency costume.

What Actually Shortens the Distance Between Audit and Incident

The teams that turn audit findings into small tickets, instead of incident reports, tend to do a few unglamorous things well.

None of it stops permissions from drifting. Drift is what happens when real people ship real work under pressure. The goal is to shrink the distance between the moment a permission stops being needed and the moment it goes away, so the auditor's spreadsheet is short and the incident report never gets written.