OAuth trust chains expose the hidden risk in SaaS access

At a glance

What this is: This is an analysis of how delegated OAuth trust chains can turn a routine sign-in path into a path to internal systems and customer data.

Why it matters: It matters because IAM, PAM, and NHI programmes often govern direct access well but miss the inherited trust and lifecycle risk created by third-party and delegated connections.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.
• 17 minutes

👉 Read Arcon's analysis of the Vercel OAuth breach and hidden trust chains

Context

OAuth trust chains are the linked authorisations that let one identity or application act through another without a fresh, direct login at every step. In this case, the core IAM issue is not the sign-in button itself but the delegated access path it opens across external and internal systems.

For identity teams, this is a governance problem as much as an access problem. Human SSO, third-party application consent, and non-human service integrations can all inherit trust in ways that are hard to see, review, and revoke once the original relationship changes.

Key questions

Q: What breaks when OAuth trust chains are not governed properly?

A: The main failure is that delegated access outlives the business reason for it. A consented application can keep reaching internal systems even after the owner, vendor relationship, or use case has changed. That creates hidden standing privilege, weakens auditability, and makes revocation reactive instead of controlled.

Q: Why do delegated SaaS permissions increase identity risk?

A: Because they move access decisions away from direct human login and into durable grants that can be reused across sessions and services. If those grants are not reviewed, a third-party app can retain access far longer than a user session would, expanding the blast radius of a compromise.

Q: How do teams know whether OAuth token governance is actually working?

A: Look for short token lifetimes, tested revocation, no tokens in logs, and a clean mapping from each integration to an accountable owner. If disconnected apps still retain access, or if nobody can explain which scopes are approved, the programme is functioning on paper only.

Q: Who is accountable when a SaaS integration exposes customer data?

A: Accountability sits with the organisation that owns the delegated access path, even if the token originated from a third-party service. Security, application, and SaaS owners all need a defined revocation process and an incident playbook. If the integration can reach customer data, it must be governed like any other privileged identity.

Technical breakdown

How OAuth trust chains expand the blast radius

OAuth is designed to delegate access without sharing user passwords. That delegation is safe only when scopes are narrow, consent is well understood, and downstream application trust is continuously bounded. In practice, a single connected identity can fan out into multiple API calls, session tokens, and service permissions. The risk is not just token theft. It is trust propagation, where one authorised relationship becomes an entry point into systems that were never intended to be directly exposed. That makes consent management, scope review, and token lifecycle control part of the attack surface, not just the authentication stack.

Practical implication: review delegated application scopes and token lifetimes as part of access governance, not as a one-time onboarding task.

Why delegated access is harder to govern than direct login

Direct login gives identity teams a clearer subject, session, and policy boundary. Delegated access blurs those lines because a third-party app, a human user, and a backend service may all participate in the same trust chain. Once tokens are issued, revocation and forensics become more difficult if the platform does not log consent lineage and token exchange paths. This is where NHI governance and IAM overlap: machine-to-machine permissions and user-consented app access can both create standing pathways that outlive the business need that created them.

Practical implication: require lineage-aware logging for OAuth grants so teams can trace which app, user, and service actually carried the trust.

Why customer data exposure often follows trust sprawl

Customer data exposure in these cases usually follows access accumulation, not a single broken control. Applications gain broader scopes over time, vendors retain stale entitlements, and revocation is delayed because no one owns the full relationship lifecycle. The result is a governance gap, not just a technical flaw. Once the trust chain is embedded in business workflows, it is difficult to separate convenience from necessity. That is why SaaS access reviews must include consented apps, federated integrations, and dormant service relationships, not only named users.

Practical implication: fold delegated SaaS connections into recertification cycles and remove stale app consents on the same schedule as user access.

Threat narrative

Attacker objective: The attacker wanted to exploit delegated trust to reach internal systems and extract customer data without having to defeat primary authentication directly.

1. Entry occurred through a delegated OAuth trust path, where a routine sign-in or consent flow created access into internal systems.
2. Escalation followed when the trusted connection allowed broader access than the original business function required, expanding reach into customer or internal data stores.
3. Impact was the theft of customer data from systems that depended on inherited trust rather than tightly scoped, continuously reviewed access.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

Delegated access is now an identity perimeter problem, not a login problem. OAuth and SSO were built to reduce password risk, but the real governance exposure sits in the trust chain they create. When one identity can authorise another application to act on its behalf, security teams inherit a perimeter made of consent, scopes, and revocation discipline. The implication is that IAM programmes must govern delegated relationships with the same seriousness they apply to primary credentials.

Consent lineage is the missing control in many SaaS environments. Most teams can tell you who logged in, but far fewer can explain which app consent created the downstream access path that later touched sensitive data. That gap is especially dangerous when business ownership, security ownership, and vendor ownership are split. The practical conclusion is that access reviews must follow the trust chain, not just the user account.

OAuth trust chains create standing privilege through delegation, even when no password is shared. The broken assumption is that federated access is inherently low-friction and low-risk because it avoids credential reuse. In reality, the durable object is the grant itself, and grants often persist long after the operational need has changed. Practitioners should treat consented applications as governed identities with their own lifecycle.

Runtime governance gap: this class of breach shows that authorisation decisions made at onboarding are not enough when trust can be re-used across services at runtime. The security model has to account for what happens after the first consent, especially in environments where data and workflow automation depend on third-party integrations. That means governance must extend into revocation, monitoring, and periodic re-authorisation.

Third-party integrations are part of identity architecture, not an adjacent risk. Once external platforms can move data or trigger actions inside enterprise systems, they belong in the identity model alongside human users and NHI accounts. The implication is clear: security teams that keep vendor integrations outside IAM and IGA controls will continue to miss the main source of exposure.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which suggests that once identity governance fails, it often fails repeatedly rather than as a one-off event.
• For a broader control perspective, the 52 NHI Breaches Analysis shows how recurring lifecycle gaps turn identity exposure into repeatable incident patterns.

What this signals

Consent governance is becoming a core identity programme metric. As SaaS ecosystems expand, the real question is no longer whether users can log in, but whether the organisation can explain and revoke every delegated trust relationship that touches sensitive data. Teams that do not inventory consent lineage will keep finding access paths after the fact, not before them.

With 72% of organisations already experiencing or suspecting a non-human identity breach according to The 2024 ESG Report: Managing Non-Human Identities, the boundary between human SaaS access and machine trust is collapsing into one governance problem. The practical response is to treat application grants, service credentials, and federation paths as one lifecycle.

Identity blast radius: the next governance gap is not initial authentication, but the amount of access a single delegated relationship can unlock across connected systems. Security leaders should prepare for access review processes that prove lineage, not just possession, and for offboarding workflows that revoke grants as rigorously as they disable user accounts.

For practitioners

• Inventory delegated OAuth grants across SaaS applications Create a register of every consented application, API grant, and federation path that can reach sensitive systems. Tag each relationship with owner, business purpose, scope, and revocation authority so stale trust chains are visible before they become incidents.
• Add delegated access to access review cycles Include third-party SaaS consents, service-to-service tokens, and federated app permissions in periodic recertification, not just human user accounts. Where the business purpose is unclear, require re-approval or remove the grant.
• Shorten the lifetime of standing OAuth trust Reduce token duration, restrict refresh token exposure, and require re-authentication for high-risk scopes. Pair this with logging that records consent lineage so revocation can target the exact trust path rather than guessing at the affected app.
• Bind third-party integrations to formal offboarding Treat vendor changes, contract ends, and application decommissioning as identity offboarding events. Remove API grants, service permissions, and cached tokens at the same time, using a documented deprovisioning runbook.

Key takeaways

• OAuth trust chains can turn a simple sign-in flow into a hidden access pathway into internal systems and customer data.
• The evidence points to a governance failure in delegated consent, revocation, and lineage visibility rather than a single broken login control.
• Practitioners need to bring third-party grants, service permissions, and offboarding into the same identity lifecycle as human and NHI access.

Key terms

• Identity Trust Chain: The sequence of trust decisions that connects a message, user, application, model, tool, and credential into one working path. When any link is weak, an attacker can move from content manipulation to access abuse without needing a separate breach at each layer.
• Consent Lineage: Consent lineage is the traceable history of which permissions were requested, approved, exercised, and revoked for a non-human identity. It matters because agentic access can expand across tools and tenants over time, and review processes fail if they cannot reconstruct that path.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Arcon's full analysis covers the operational detail this post intentionally leaves for the source:

• The original incident framing and how the trust chain was established across connected applications
• The article's discussion of the Vercel breach context and why delegated OAuth access is difficult to unwind
• The vendor's broader risk commentary on third-party integration governance and access control
• Implementation-oriented context around privileged access and identity management capabilities referenced by Arcon

👉 Arcon's full post covers the Vercel context, delegated access risk, and the identity control gaps behind the breach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.