OAuth supply chain risk is expanding across SaaS and AI agents

At a glance

What this is: This is an analysis of how OAuth-connected SaaS, scripts, and AI-adjacent tools expand the trusted access surface and create supply chain risk when credentials persist outside direct control.

Why it matters: It matters because IAM teams now have to govern external app trust, token lifetime, and machine access pathways together rather than treating them as separate problems.

👉 Read 1Password's analysis of OAuth supply chain risk and credential sprawl

Context

OAuth-based supply chain risk emerges when approved third-party access outlives the business need that created it. In practice, credentials move through SaaS apps, scripts, and automation workflows faster than most identity teams can inventory them, which leaves the access model blind to who or what now depends on those grants.

The governance gap is not authentication alone. The problem is that valid tokens can keep working after the original task has changed, the tool has been forgotten, or the external service has been compromised, so access control becomes a question of lifecycle, visibility, and revocation discipline across NHI-style connections and human-approved app consent.

For IAM and security teams, this is a control-plane issue. The exposure spans human consent, machine execution, and third-party trust, which means the access review model has to track actual usage rather than only approved connection state.

Key questions

Q: How should security teams handle OAuth-connected apps that outlive their original business need?

A: Security teams should treat every OAuth-connected app as a live entitlement with an owner, purpose, and expiry review. If the app is no longer needed, revoke access and confirm that the token cannot continue to act. The key is to manage the connection as part of identity lifecycle governance, not as a one-time approval.

Q: Why do overpermissioned third-party integrations increase supply chain risk?

A: They increase supply chain risk because a compromise in the external service can immediately inherit the scopes already granted by the organisation. The attacker does not need to defeat login controls if the token is still valid. That makes scope size, token lifetime, and vendor trust posture central to the risk decision.

Q: How do organisations know whether OAuth discovery and revocation controls are working?

A: They know the controls are working when the inventory is current, app ownership is clear, and stale connections are removed quickly after use stops. If forgotten tools, unknown scopes, or unauthorised connections keep appearing, discovery is lagging behind the actual trust graph. Effective governance should show shrinking blind spots, not just more reports.

Q: Who is accountable when a third-party OAuth token is abused?

A: Accountability is shared across the business owner who approved the tool, the identity team that governed the scopes, and the security function that monitored the connection. If the external service was not risk-assessed or the token was never reviewed, the failure sits in governance as much as in detection. Clear ownership prevents the problem from disappearing into vendor blame.

Technical breakdown

How OAuth consent becomes persistent third-party access

OAuth consent is often treated as a one-time user action, but the resulting token is a durable access artifact. Once granted, scopes can remain active until revoked or expired, and the connected app can continue acting without repeating the consent flow. That makes the access path especially dangerous when the app is later compromised, because the attacker inherits already-authorized permissions instead of needing to defeat authentication. In identity terms, the trust decision is front-loaded while the risk unfolds later, outside the user’s line of sight.

Practical implication: inventory every app granted OAuth access and review whether its token lifetime matches the business use case.

Why standing tokens create a wider blast radius

Standing tokens are problematic because they turn temporary work into durable privilege. If a token remains valid after the task is finished, the attacker does not need to escalate privileges or trigger suspicious logins; they simply use the existing permission set. That makes overpermissioned scopes, reused credentials, and forgotten app connections a compound exposure. The issue is not just secret leakage. It is that the token’s effective authority often exceeds the original operational need and persists long enough to be abused quietly.

Practical implication: shorten token lifetime where possible and separate production access from development and automation credentials.

Why valid API activity can evade normal detection

Most security telemetry is tuned to spot failed logins, impossible travel, or obvious abuse patterns. OAuth abuse often looks different because the requests are authenticated and the client is known, so the event stream appears normal at first glance. That makes behavioural baselines for machine identities essential, especially where approved integrations can read mail, files, or workspace metadata. Detection must focus on scope misuse, unusual access timing, and unexpected data paths rather than only on authentication anomalies.

Practical implication: build detections for unusual scope use and atypical machine-identity behaviour, not just login failures.

Threat narrative

Attacker objective: The attacker aims to inherit trusted workspace access and reach internal systems through a valid OAuth token rather than by breaking authentication.

1. Entry occurs when an employee grants a third-party tool Google Workspace OAuth access through a standard consent flow, creating a valid trust relationship.
2. Credential access follows when the third-party service is later compromised and the attacker obtains the token without needing to bypass authentication.
3. Impact occurs when the attacker uses the still-valid permissions to access internal systems and data from within approved trust boundaries.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth sprawl is now a supply chain governance problem, not just an app-management nuisance. Once external tools can act with valid workspace permissions, the risk shifts from local entitlement management to third-party trust lifecycle. That means the real control question is not whether an app was once approved, but whether the current access graph still reflects business intent. Practitioners should treat every connected app as part of the identity perimeter.

Standing OAuth consent was designed for human-paced review cycles. That assumption fails when access is granted in one click and then persists quietly while the external service changes risk posture. The implication is not simply that teams need more reviews, but that the review model itself must be built for access that can outlive its original purpose by months or years.

Credential sprawl creates an identity blast radius that most IAM programmes still under-measure. The article’s core warning is that scripts, environment variables, SaaS connectors, and AI-adjacent workflows all expand the same external dependency chain. In governance terms, that means blast radius is determined by hidden connections as much as by explicit privileges. Security teams should assume the true access surface is larger than the identity provider catalog.

Continuous discovery is becoming the baseline control for third-party access governance. Point-in-time inventories cannot keep pace with employees adding tools, broadening scopes, and abandoning old integrations. Visibility has to be continuous because the trust boundary changes continuously. The practitioner conclusion is straightforward: if discovery is periodic, the control is already behind the risk.

Machine-identity usage must be evaluated as behaviour, not only as entitlement. The article shows why valid credentials can still represent abuse when they are used in ways that do not match normal application patterns. That is especially important where human consent masks machine execution. Practitioners need governance that ties identity, scope, and usage together instead of certifying access in isolation.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader control baseline, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle patterns that help contain standing access.

What this signals

OAuth governance is converging with NHI governance because the same failure mode appears in both places: a credential exists longer than the task that justified it. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, many teams are still managing access by exception rather than by continuously refreshed trust state.

Ephemeral trust debt: this is the gap between a quick consent action and the long tail of access that action creates. As AI tools, SaaS connectors, and automation workflows become the default way to work, identity teams should expect that hidden dependencies, not just malicious actors, will drive the next wave of access incidents.

For practitioners

• Inventory all OAuth-connected applications continuously Review Google Workspace or Microsoft-connected apps as a live access set, not a quarterly snapshot. Track the user who authorised each connection, the scopes granted, and whether the app is still required. Remove forgotten tools and investigate any connection that broadens data access without a clear business owner.
• Reduce token lifetime wherever the workflow allows Set expiry policies for OAuth tokens and avoid long-lived credentials in scripts or automation paths. Where the platform supports it, prefer issued-at-use access over pre-distributed secrets so a stolen token has a shorter window of usefulness.
• Separate development, automation, and production credentials Do not let tokens used in testing or low-risk workflows carry over into production systems. Keep credential stores distinct and enforce environment boundaries so a compromise in one tier does not cascade into the rest of the estate.
• Tune detections for valid-but-unusual access patterns Build monitoring around scope misuse, abnormal request timing, and unexpected data paths from connected apps. A valid token can still be abusive, so focus on what the app is doing after authentication rather than only on whether authentication succeeded.

Key takeaways

• OAuth-connected apps turn everyday productivity choices into durable external trust relationships, which is why supply chain risk now sits inside identity governance.
• Valid tokens can outlive the use case that created them, so blast radius depends on lifecycle discipline as much as on scope size.
• Continuous discovery, shorter token lifetimes, and behaviour-based monitoring are the controls most likely to shrink the gap between approved access and actual risk.

Key terms

• OAuth-connected application: An OAuth-connected application is a third-party service that has been granted access tokens to act on behalf of a user or organisation. In identity governance terms, it becomes part of the trusted access surface and must be reviewed as a living entitlement, not just a signed-in app.
• Standing token: A standing token is a credential that remains valid beyond the immediate task that justified it. It creates ongoing authority for an app or workflow, which is useful operationally but risky when the token persists after the business need has ended or the external service has changed posture.
• Credential sprawl: Credential sprawl is the uncontrolled spread of secrets, tokens, and access artifacts across scripts, environments, SaaS tools, and automation flows. It matters because every additional copy increases the number of places an attacker can find valid access and makes lifecycle control harder to sustain.
• Identity blast radius: Identity blast radius is the amount of internal access that can be reached when one credential, token, or connected service is abused. The wider the blast radius, the more a single trust decision can cascade across systems, data, and workflows that were never meant to share one control boundary.

Deepen your knowledge

OAuth-connected apps, token lifetime, and third-party access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for SaaS sprawl and machine access, it is a strong fit.

This post draws on content published by 1Password: OAuth-based supply chain attacks and credential sprawl in SaaS and AI workflows. Read the original.