Scope sprawl occurs when identities, applications, or tokens accumulate broader permissions than they need to perform their intended tasks. It often stems from weak internal standards, unclear documentation, or pressure on engineering teams to move quickly. For example, consider the following scenarios.

A developer wires an integration, requests a broad OAuth token scope because the narrower one is poorly documented, and then moves on to the next task. A continuous integration and continuous delivery (CI and CD) pipeline gets a GitHub token with read and write across every repository because the default was too permissive, and the deadline was too tight. A SaaS connection to the company CRM is granted admin-level access because leadership pushed a Jira ticket with the comment “just make this happen today.” None of these decisions were malicious — but they all contributed to scope sprawl.

Today, we’re going to dive into this scope sprawl — we’ll define what it actually is, dig into how damaging it can be, and look at some solutions for mitigation.

So What Is Scope Sprawl, Exactly?

Simply defined, scope sprawl is the accumulation of excessive, underscoped, overscoped, or inadequately governed permissions across a set of identities, both human and machine. Under scope sprawl, these permissions materially exceed what is actually necessary for the work being done. It’s essentially the permission equivalent of technical debt — a slow gathering of bad decisions that cost nothing in the immediate, yet become horrifically expensive to remediate once something inevitably goes wrong.

To put a finer point on this, in 2024, GitHub detected over 39 million leaked secrets on its platform. And if you think it’s gotten better, think again — GitGuardian’s State of Secrets Sprawl 2026 report found that 28.65 million hardcoded secrets were added to public repositories in 2025.

And that’s all bad enough — but when those leaked tokens carry write access, the scope problem isn’t just theory, it’s practical and observable. To be clear, scope sprawl is a permission problem, not a credential management problem. The credentials might be perfectly tracked, rotated, and stored in the right vault, but the real issue is in what they grant.

And this isn’t a problem of standards or auth frameworks either. The OAuth scope model was designed with good intentions — scopes define the minimum set of API permissions a client needs for a specific task, and the granularity is there if you use it. The problem is what happens under pressure. Developers request broad scopes because narrower ones are poorly documented, or the feature they’re rolling out is so critical that they just want to get it done. Even properly permissioned tokens are left with a long time-to-live, meaning tokens just drift into the wild, valid forever, creating new exposures and weaknesses in your defense posture.

Real-World Examples

With scope sprawl defined, let’s take a look at some real examples in the wild. Scope sprawl is not abstract. It’s something that is hitting real teams at scale.

Over-Permissioned GitHub Tokens

When a GitHub Actions pipeline does not explicitly define permissions in its YAML, the GITHUB_TOKEN inherits defaults that, in older repository configurations, grant read and write across all scopes. This is a default behavior that is intended to allow for faster velocity in development, but it’s also a critical scope sprawl weakness that opened up a ton of developers to some pretty huge losses.

The tj-actions/changed-files supply chain attack in March 2025 compromised a widely used GitHub Action present in over 23,000 repositories, dumping CI and CD runner memory and exposing secrets from workflows that had granted these excessive default permissions. This started with a simple problem — tokens that were overly permissive for what they were actually meant to do — but it created an attack surface that is still being untangled today, exposing critical secrets and services at a huge scale.

Overly Long-Lived API Keys

In theory, API keys should have a definitive end-of-life point. Even well-structured keys shouldn’t live in the wild forever. Unfortunately, GitGuardian found that 70% of secrets detected in public repositories in 2022 were still active in 2024. Many organizations provision keys with multi-year lifespans because they lack the automation to rotate them, and a single engineer can end up managing dozens of non-human identities with indefinite lifespans. This adds up to a long-term problem that is hard to detect, hard to remediate, but highly damaging to the service itself.

This attack might sound theoretical, but there was a clear attack escalation in 2024 that took advantage of this exact issue. The Snowflake incident in 2024 saw threat actor cluster UNC5537 access approximately 165 Snowflake customer environments using credentials harvested from infostealer malware dumps. These were not fresh credentials — they were long-lived authorized accounts, often lacking MFA, designed to persist indefinitely. The data exposed included customer information from AT&T, Ticketmaster, and Santander, and these organizations are still working to mitigate this exposure due to both the depth and breadth of the breach.

Broad SaaS OAuth Integrations

Enterprises routinely manage hundreds of cloud applications, many of which are connected to core systems via OAuth tokens. The problem is that, often, these tokens were granted broad permissions during initial setup and then were never reviewed after that.

The Salesloft/Drift breach in August 2025 made this concrete — threat actor UNC6395 stole OAuth tokens used for Drift’s integrations with Salesforce and Google Workspace, and those tokens then provided access to more than 700 organizations’ customer data, contacts, and AWS keys. Salesforce subsequently confirmed that attackers also used OAuth tokens from Gainsight-published apps to access customer data. The tokens were not exploited through a technical vulnerability — they were used as intended, because their scopes had been granted broadly and their access was never time-limited.

These overly broad integrations are a huge threat because they grant access to the most critical business functions. This is made all the more frustrating by the fact that, for such critical resources, they seem to be treated as having a low value.

JWT Overscoping

A fine-grained permission system creates a matrix of resource types and operations that quickly reaches dozens or hundreds of scope combinations. Injecting all of these into a JSON Web Token (JWT) is technically impossible due to HTTP header size limits, and logically wrong even if it were possible, because the JWT is minted at login and represents a snapshot that may be hours out of date by the time a request is made.

Where this becomes problematic is in the chaining of these tokens. When a coarsely scoped JWT is passed to the next provider down the line, this can create a sort of domino effect where each service in the microservices chain becomes another link in the lateral movement threat.

The fix is decoupling. Scopes handle coarse-grained limits at the token level, claims handle context-aware authorization at the request level, and a centralized authorization service handles fine-grained, real-time policy evaluation.

The Scope Sprawl Defense Toolkit

Scope sprawl is not fixed by a product — it is the result of a set of engineering habits that, taken together, drastically increase the probability and likelihood of every core issue we just discussed. The good news is that mitigating this can be done, but it requires both willpower and dedication to a better path.

Least Privilege

This entire issue is at least in part a visible case of failure to enforce least privilege. This concept states that every identity, human or non-human, should hold the minimum permissions required to accomplish its current task and nothing more. This is not a new idea, but it’s consistently violated anyway, because breadth is easier to provision and less likely to break something at 11 PM.

Least privilege is not a configuration you set once — it is a condition you maintain. Permissions that were appropriate for a task last quarter may not be appropriate today, and as such, mitigating this is as much about enforcing during the build process as it is about consistently auditing and reviewing access.

The fix: Enforce least privilege readily and constantly audit to ensure adherence to policy.

Fine-Grained Authorization

Fine-grained authorization operates at the resource and context level. It doesn’t just answer “can Bill access the Shipments API?” but “can Bill access this specific shipment, and under what conditions?” Implementing fine-grained authorization means implementing tighter controls that have less flexibility, but in turn, more security at scale.

The guidance from industry-leading identity specialists on AI agents is explicit: use scopes for coarse-grained limits and claims for fine-grained, context-aware authorization. Scopes belong in the token, and policy decisions around resource ownership, user context, and real-time state belong in a centralized authorization service queried at request time. For microservices and multi-agent chains, restrict tokens by audience so that a token stolen from one component cannot be reused against another.

The fix: Leverage fine-grained authorization to build a layered defense.

Runtime Access Control

One of the best ways you can hardcode some defensive posturing into your systems is to enforce access control at run time actively. Permissions set at configuration time represent a prediction about what will be needed in the future — and as such, when these needs shift, mutate, and change, such access controls are often inadequate or, in the inverse, overly permissive.

Runtime access control means making the authorization decision at the moment of the request, not at the moment the credential was issued. There’s a ton of great frameworks for doing this right, with solutions like OPA (Open Policy Agent) or Cedar offering methods to deploy policy-as-code to evaluate authorization decisions in real time against dynamic context.

To be clear, these are not replacements for solutions like OAuth — they’re an additional layer that allows for more flexible authorization that is responsive to the realities of deployment and production, not what was assumed many months ago during the initial build state.

The fix: Don’t set and forget — make room for evolving solutions for auth that reflect the current reality, not the imagined needs of last month or last year.

Short-Lived Credentials

It’s important to remember that tokens aren’t just a fire-and-forget affair, and what makes sense today may not make sense in the long run. Accordingly, ensure that your tokens are short-lived. An access token that expires in 15 minutes cannot be replayed after 15 minutes — and while this doesn’t prevent a compromise, it does severely limit the time window where it can occur.

Do be cautious, however, that tokens aren’t able to mint new tokens. Scope sprawl can come from overly permissive token generation, especially in agentic workloads. So make sure that your token cannot create new vectors over time. Similarly, consider a just-in-time and limited-scope token process that is tightly bound to an action. In essence, this allows you to limit the token to a specific action and thereby reduce the potential damage by making sure only one small aspect can ever be threatened by that token, even if the window of time for vulnerability is small to begin with.

The fix: Reduce the potential risk vector of token misuse by making sure that the token itself is highly limited, time-bound, and purpose-oriented.

Permissions Are a Promise, Not a Default

Scope sprawl is the natural outcome of treating permissions as a default rather than a deliberate commitment. And these over-permissioned tokens result in long-lived exposure and broadening threat vectors at scale.

The pattern is reversible, but it takes sustained, low-level engineering discipline rather than a single intervention. This involves auditing scopes against actual usage, implementing time-bound credentials, deciding authorization at request time rather than configuration time, and giving each identity only what it needs for the task at hand.

This is a real problem with real impact — and it’s impact you can measure against breaches suffered by orgs like Snowflake, GitHub, Home Depot, Salesloft, and more. These are not exotic attacks — they are the direct consequence of scope sprawl at scale. Inaction is not an option, and neither is maintaining the broken status quo.