Over-Scoped Tokens: Five Ways One Compromise Becomes Many

A lot of breaches involve attackers gaining access to a secret, often an access token for a service. The more access those tokens have, the greater value they have during an attack. Reducing the scope of access your tokens have is a key part of an effective defense, especially as AI accelerates attack timelines.

Access tokens are a bigger deal than AI tokens

Breach reports tend to put a lot of attention on how clever or capable the attacker was, or make broad claims about how AI made the attack possible. The reality is often less exciting, because it boils down to an attacker gaining a credential that can do far more than it should. In developer environments especially, an over-scoped token can open the door to everything from your organization’s repositories to your production and operations infrastructure.

Public incident response data makes this clear. Mandiant’s M-Trends 2026 report, which draws on its 2025 investigations, concludes that the vast majority of intrusions still came from human and systemic failures. The report also describes attackers moving from a source code management (SCM) account or developer workstation, using personal access tokens (PATs) to find hardcoded integration tokens in repositories. That pattern turned a small compromise into a big problem for a company’s customers.

But over-scoped tokens aren’t just one problem. They’re a pattern of weakness that we can break into five specific issues, and each has a least-privilege fix.

Five over-scoped token patterns

Each pattern below describes a way a credential ends up more powerful than it should be, and a path to a fix based on the principle of least privilege (give every identity the minimum access it needs, for the minimum time it needs it).

Throughout, we’ll borrow examples from the M-Trends 2026 report produced by Mandiant. That means these are based on real incidents, even though the data comes from Mandiant’s own incident response engagements, which skew toward larger organizations that were breached.

Personal access tokens that can reach everything

In the incidents described, a compromised SCM account (like a GitHub account) or developer workstation gave attackers a PAT, and the PAT gave them the ability to search repositories for more credentials. A broad, long-lived PAT turns one stolen desktop or CI session into a search engine over your entire codebase, or worse.

The fix:

• prefer fine-grained tokens limited to specific repositories and permissions,
• enforce expiration dates by organization policy,
• use short-lived credentials for automation instead of PATs wherever your platform supports it.

Integration tokens hardcoded in repositories

Hardcoded tokens are part of what makes the first pattern (PATs) pay off. If a repository holds a working integration token, anyone who can read the repository can use it, regardless of how well the integration itself is protected.

The fix:

• move secrets into a dedicated secrets manager,
• scan for secrets in code before it gets committed; use pre-commit hooks with tools like the open-source 2ms (Too Many Secrets) and the centrally-managed Checkmarx secrets detection product.

Integration keys with more scope than the integration needs

A token created for one narrow task is often given broad permissions because that was faster than working out the minimum, and nobody revisits it later. When these leak, they can end up not only handing attackers significant access, but they can be much more disruptive to revoke and rotate.

The fix:

• don’t reuse tokens: use different tokens for different use cases,
• grant only the scopes each use case actually needs,
• review and attest the scopes on a schedule; short expiration times can force this process,
• if a vendor’s setup guide asks for broad access, ask whether a narrower option exists before you accept it.

Wildcard API keys

A wildcard application programming interface (API) key is the extreme case of over-scoping: it is valid for any resource or action in the service it belongs to. These keep turning up in investigated incidents. If a wildcard key leaks, the attacker inherits everything it covers, with no further hurdle. Arguably, this is a case of “more scope than needed,” but it’s taken to an extreme: the scope is everything.

The fix:

• avoid wildcards in key permissions; audit with configuration management tools,
• restrict keys to named resources and specific actions,
• add network restrictions such as IP allow-lists or secondary device authentication (like mTLS, IPSec, and so on) where suitable, to make it harder to use a leaked token.

Long-lived OAuth and refresh tokens that sidestep multi-factor authentication

Multi-factor authentication (MFA) is an important control that makes it harder to sign in with a stolen credential. But when that sign-in produces OAuth and refresh tokens that have long lifetimes, an attacker who steals one can often skip the MFA prompt entirely. Your strong sign-in system doesn’t protect you if the tokens it produces last for months and have significant privileges.

The fix:

• keep ephemeral token lifetimes short,
• limit the scopes granted to each application,
• revoke tokens explicitly on logout actions or access changes,
• monitor for token use from unexpected locations or at unusual times.

Why even a “minor” token can become a major incident

Attackers aren’t just interested in the initial breach, but in lateral movement and elevation of access. Tokens often grant access that can be chained into revealing further tokens or exposing more attack surface. The activity tracked as UNC6395, also called the Salesloft Drift incident, covered in M-Trends, is an example

: a compromise that began in a repository became a supply chain event reaching a vendor’s customers. Every access token is potentially a bridge into someone else’s environment, and the width of that bridge is set by the token’s scope.

The same stolen credential, with and without least privilege.

Chains of access are only as strong as their weakest link, so tightening controls around all five patterns above is essential in mounting an effective defense, especially as AI tools continue to accelerate attacker behaviors.

This isn’t a “buy a tool” problem

The temptation after reading about incidents like these is to go shopping for something new. Resist it. Most of these breaches come from boring failures, and boring failures respond to boring fixes that scale.

This week, pick one integration your developers rely on heavily and inventory every token it uses. For each token, answer four questions: who owns it, what can it do, when does it expire, and where is it stored? Then flag the tokens with broad scopes and long (or no) expiration times. Odds are good that at least one has no clear owner, can do far more than its job requires, and never expires. Fix that one first, then repeat for the next integration.

Token inventory for one integration. Flag broad, ownerless, never-expiring tokens first.

Next, provide a consistent layer of defense: start using secret scanning and secret-detecting pre-commit checks across every repository, set shorter expiration defaults for new tokens, and put token review on the calendar next to patching.

Taking these steps can do a lot to shut down a key threat vector for attackers.