A service account with far more access than its job needs

What actually happens

Nobody grants a service account excessive privilege on purpose. It accumulates, one reasonable exception at a time, and every step in the chain was approved by someone competent.

A service account is created with the permissions it needs. Over the following months the systems around it change. A migration needs it to read one more bucket. An incident needs it to write to one more queue at two in the morning. A new integration needs a broader role because the narrow one did not exist yet.

Each of those grants was justified at the time. None of them was revoked afterwards, because revoking a permission requires someone to be confident nothing still depends on it, and nobody is ever confident of that.

The account now holds access substantially wider than its function requires. It is not compromised. It is a liability sitting there quietly, and its blast radius if it ever were compromised is much larger than the architecture diagram suggests.

This surfaces at review season. Someone is asked to attest that entitlements are appropriate, and to do that honestly they have to reconstruct months of changes from ticket history, change records and cloud audit logs across several systems. That reconstruction is weeks of work and it happens every cycle.

The attestation that results is usually accurate about the current state and silent about how it got there, which is the part an auditor actually asks about.

Privilege drift is not a security failure. It is the accumulated residue of a hundred correct decisions that nobody was assigned to reverse.

The same quarter, two ways

This one is not measured in minutes either. The unit is how long an over-permissioned account sits there before anyone can see it.

There is no incident in this scenario, which is exactly why it persists. Nothing fails, nothing alerts, and the cost is entirely in two places: the risk carried during the drift period, and the labour consumed at review season.

The labour is the number you can put to your CFO without any modelling. Take the person-weeks your last access review consumed and multiply by your review frequency.

The mechanism that makes revocation safe is usage evidence. The reason permissions are never revoked is that nobody can prove nothing depends on them. Sampling actual usage over months converts that from an opinion into a record, and revoking a permission the account has demonstrably never exercised is a much easier approval to get.

The honest limit: usage sampling proves a permission was not used in the observed window, not that it will never be needed. That is why the revocation carries an automatic rollback rather than being treated as final.

Who decides to press go

Revoking a permission from a live service account can break something at an unpredictable moment, so it is proposed with evidence rather than applied on detection.

Observation runs under policy: recording grants against intent, sampling usage, assembling attestation evidence. None of it changes an entitlement.

The revocation is raised and held with the usage evidence, the dependency analysis and the rollback path attached. The security owner approves before any permission is removed.

Every revocation carries an automatic rollback trigger, because usage evidence covers the observed window and nothing more. That is a limitation worth designing around rather than arguing with.

Entitlement grants accumulating on a service account across months. Each grant individually justified. Aggregate access materially wider than the account function.

Grants correlated against account intent, change records and sampled actual usage. Permissions the account has never exercised identified with evidence.

Action Ticket raised proposing revocation of unused grants, with usage evidence, dependency analysis and rollback path. Held for the security owner.

Entitlement widening promoted to a monitored signal per account. Attestation evidence assembled continuously so review season becomes a query rather than a reconstruction.

This is a platform capability, not a published customer deployment. The mechanism, which is correlated investigation across identity, change and telemetry followed by governed action with approval gating, is running in production today; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The security scenario above applies that same mechanism to an identity and access context. The timings shown are modelled, not measured at a named customer.