The Accumulation Problem: Auditing Access Before Incremental Permissions Become a Systemic Liability

Imagine a contractor who is granted building access for a two-week project. The project extends. A new project starts. The contractor moves to a full-time role. Years pass. The original access level, provisioned for a temporary engagement, is still active — and has been supplemented by a dozen additional grants made over the course of their tenure. Nobody made a reckless decision. Every individual permission had a justification at the time it was issued. And yet the cumulative result is an access profile that no security policy would have approved if it had been requested all at once.

This is the anatomy of permission creep, and it is one of the most underestimated exposure vectors in modern infrastructure. At JFDP Labs, we have observed that the organizations most vulnerable to this pattern are not the ones with weak security cultures — they are the ones with strong delivery cultures where access friction is treated as a productivity tax and access reviews are treated as a compliance formality.

The Mechanics of Drift

Permission creep does not require negligence. It requires only that access grants be easier to create than they are to revoke, and that the organizational context for each grant erodes faster than the grant itself.

In practice, this means that access is provisioned in response to immediate needs — a developer needs read access to a production database to diagnose an incident, a product manager needs export permissions to prepare a quarterly report, an automated service account needs elevated privileges to complete a migration. Each of these requests is evaluated on its own merits, approved, and logged. What is rarely tracked is whether the need that justified the grant has since expired.

Over time, this creates what security practitioners sometimes call an access archaeology problem. The current permission state of any given user or service account reflects not who they are or what they need today, but the entire history of every role they have ever occupied and every task they have ever been asked to complete. Reconstructing the rationale for any individual grant — let alone the aggregate — requires digging through ticketing systems, Slack archives, and the institutional memory of employees who may no longer work at the company.

Why Audits Alone Do Not Solve It

The standard organizational response to permission creep is the periodic access review: a scheduled process in which managers attest to whether their direct reports still need the access they have. In theory, this is a reasonable control. In practice, it has several structural weaknesses that limit its effectiveness.

First, access reviews are typically scheduled at intervals — quarterly or annually — that are far too infrequent to keep pace with the rate at which access is granted. In a fast-moving engineering organization, meaningful permission drift can accumulate within weeks.

Second, the review process places the burden of judgment on managers who often lack the technical context to evaluate whether a specific permission is still warranted. A manager can confirm that an employee still works on the team. They cannot easily determine whether that employee's AWS IAM role grants more than the principle of least privilege would allow.

Third, and most critically, the default behavior in most access review processes is to approve existing access rather than to question it. The cognitive load of investigating each permission is high, the organizational cost of over-revoking is visible and immediate, and the cost of under-revoking is invisible until it isn't. Inertia consistently wins.

A Framework for Security Archaeology

Recovering from significant permission drift requires a more systematic approach than the standard review cycle provides. The following framework is designed to make the problem tractable without requiring a full halt to development operations.

Establish a permission age baseline. For every active access grant in the environment, record when it was created and when it was last actively used. Many identity and access management platforms, as well as cloud providers, surface this data natively. Access that has not been exercised in ninety days is a strong candidate for revocation regardless of its stated justification.

Separate human and machine identities. Service accounts and automated pipelines often accumulate permissions more aggressively than human users because their access is rarely tied to an individual's employment status. Treat machine identities as a distinct audit category and apply the same least-privilege standards that govern human access — with the added requirement that every service account be associated with a specific, documented function.

Implement just-in-time access for elevated privileges. Rather than maintaining standing access to sensitive resources, require that elevated permissions be requested, approved, and automatically revoked after a defined window. This shifts the default from persistent access to time-bounded access and eliminates the category of grants that persist past their useful life.

Create a deprecation queue. Access that cannot be immediately justified should not be immediately revoked if doing so carries operational risk. Instead, flag it for deprecation within a defined timeframe — typically thirty days — and assign ownership for the resolution. This creates accountability without creating a crisis.

Balancing Security and Delivery Velocity

The most common objection to rigorous access management is that it slows teams down. This is a legitimate concern, and it deserves a direct response rather than dismissal.

The goal of access hygiene is not to introduce friction into every permission request. It is to concentrate friction where it belongs: on the grants that carry the most risk and persist the longest. Routine, time-bounded access to low-sensitivity resources should be fast and easy to provision. Standing, elevated access to production systems and sensitive data should require deliberate justification and carry an automatic expiration.

Organizations that implement this tiered model consistently report that the security overhead decreases over time as the access landscape becomes more predictable and more auditable. The archaeology problem does not disappear, but it stops compounding.

The alternative — treating access management as a compliance exercise rather than an engineering discipline — leaves the organization in a position where the most significant security risks are not the ones anyone is actively watching. They are the ones that have been accumulating, one reasonable request at a time, for years.