OAuth marketplace listings do not equal approval or safe access

At a glance

What this is: This research shows that OAuth marketplace listings can mask over-broad permissions, stale publisher infrastructure, and AI-driven write access, so listing status alone is not a reliable safety signal.

Why it matters: IAM and security teams need to govern OAuth grants as living access paths, not one-time approvals, because marketplace controls do not prevent persistent risk from over-privilege or publisher compromise.

By the numbers:

• The agent found 677 apps that ask for at least one permission beyond their stated function, representing a combined 1.82 billion installs.
• Offroad AI’s agent identified 206 apps with dead publisher domains and 89 apps whose publisher domain is currently available to buy.
• The agent flagged 49 AI-powered apps with broad write access, representing an 81.6M install footprint.
• On the Workspace side alone, the agent counts 281 apps with broad Drive access, 316 touching Sheets, and 220 reaching into Gmail.

Context

OAuth marketplace listings are often treated as a proxy for trust, but the security model behind them is much thinner than many organisations assume. A listing confirms publication, not that the app’s scopes are proportionate, the publisher is still accountable, or the grant will remain safe after installation.

For identity governance, the real issue is that OAuth consent creates a standing non-human identity path into SaaS, developer systems, and mailbox or file systems. Once granted, that access can outlive the user’s intent, the app’s usefulness, or the publisher’s infrastructure, which makes marketplace review only one small part of the control problem.

Key questions

Q: What breaks when an OAuth app listing is mistaken for an approval decision?

A: The control breaks because marketplace listing status says nothing about scope fit, publisher continuity, or the app’s behaviour after installation. A listed app can still hold excessive permissions, sit behind a dead domain, or act in ways the consent screen never described. Security teams need a separate governance process for the grant itself, not just the listing.

Q: Why do broad OAuth scopes increase breach impact?

A: Broad scopes turn one consent decision into multiple reachable resources, which gives an attacker a much larger blast radius if the app is compromised. Mail, drive, calendar, and directory access can expose credentials, internal documents, and organisational structure. The wider the bundle, the more likely the compromise becomes a workspace-level incident rather than a single-app event.

Q: What signs indicate an OAuth app should be reviewed or revoked?

A: Look for dead or parked publisher domains, permissions that exceed the app’s stated function, broad write or delete scopes, and apps whose behaviour depends on AI-driven actions. These are strong indicators that the grant no longer matches the trust assumptions behind the original approval and should be revalidated.

Q: How should organisations govern AI-powered OAuth apps?

A: Organisations should treat AI-powered OAuth apps as higher-uncertainty delegated actors because the model can decide when to act, not just what data to touch. That means stricter logging, narrower scopes, shorter review cycles, and explicit owner accountability for every high-risk action path such as sending mail or editing files.

Technical breakdown

Why marketplace presence is not an approval control

An OAuth marketplace listing is a distribution mechanism, not a security verdict. The consent screen exposes scopes at authorisation time, but it does not validate whether those scopes match the app’s actual function, whether the publisher still operates a reachable domain, or whether the app’s runtime behaviour has changed. That creates a gap between publication status and access assurance. In practice, the marketplace becomes an intake channel for persistent grants, while governance depends on separate controls for scope review, publisher verification, and ongoing grant monitoring.

Practical implication: Treat marketplace approval as an intake signal and apply separate governance to scope, publisher, and lifecycle risk.

How over-broad OAuth scopes create standing access risk

OAuth scopes are coarse by design, so a legitimate use case can force apps to request permissions that exceed their immediate need. The article highlights a structural problem in some ecosystems where there is no narrower scope for write without delete, which means the permission catalogue itself can force overreach. Once approved, those permissions persist as standing grants until revoked. That makes OAuth less like a temporary transaction and more like a durable access relationship, especially when the app touches mail, files, calendar, repositories, or secrets.

Practical implication: Review granted scopes against actual business use and revoke any grant that depends on excessive platform-level permissions.

Why AI-powered OAuth apps change the trust model

An AI-powered app can make runtime choices about when to send mail, edit files, or manage calendar events, even when the consent screen looks identical to a deterministic app. The risk is not only over-privilege, but delegated action timing and intent drift inside the grant. That makes audit trails harder to interpret because the action may appear to be user-like even when the decision came from a model. For identity teams, the key issue is that consent no longer maps cleanly to predictable behaviour.

Practical implication: Require tighter governance for AI-driven OAuth apps because the same scope can produce materially different behaviour at runtime.

Threat narrative

Attacker objective: The attacker objective is to turn a trusted marketplace grant into persistent, high-value access that can be abused at scale across customer environments.

1. Initial access begins when a user or organisation authorises a third-party OAuth app through a marketplace listing that appears legitimate.
2. Credential access follows through the standing OAuth grant, which gives the app persistent permission to act inside mail, files, calendars, repositories, or workflows.
3. Escalation occurs when over-broad scopes or compromised publisher infrastructure let the app do more than the user intended, including delete, edit, or access secrets.
4. Impact is realised when the granted access becomes a supply-chain path into business systems at scale, turning one authorised app into broad tenant exposure.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

NHI Mgmt Group analysis

Marketplace listing is not an identity assurance control: this article shows that publication in an official marketplace does not prove scope correctness, publisher continuity, or runtime trust. The listing only says the app exists in the catalog, while the actual risk lives in the durable OAuth grant behind it. Practitioners should stop treating marketplace status as evidence of safe access.

OAuth consent creates a governed NHI, not a one-time permission event: once an app is authorised, it behaves like a persistent non-human identity with access to core business systems. That grant can survive staff turnover, app neglect, and publisher disappearance, which makes lifecycle oversight the real control boundary. The implication is that OAuth grants belong in the same governance conversation as service accounts and other standing access paths.

Over-broad scope catalogues create structural privilege inflation: the article’s examples show that some apps request permissions broader than their stated function, and some platforms do not offer sufficiently narrow alternatives. That is not just developer sloppiness; it is a permission model that forces risk into the grant itself. The practical conclusion is that scope design, not only app review, shapes exposure.

Publisher infrastructure is part of the trust chain: dead or buyable domains mean the identity behind a marketplace app can outlive the organisation that was supposed to stand behind it. That creates a stale accountability problem where the visible publisher record no longer matches a controllable security boundary. Identity teams should treat domain continuity as part of OAuth governance, not a separate web hygiene issue.

AI-driven OAuth apps expose an intent gap in consent design: traditional OAuth assumes the grantee behaves in a predictable, user-directed way, but an AI model can decide when and how to use granted permissions. That breaks the assumption that a scope map fully describes future behaviour. The control implication is that consent review must account for runtime decision-making, not only declared functionality.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

Consent review has to move beyond the marketplace catalog: governance teams should treat OAuth grants as live access objects, not static approvals. The important questions are whether the permissions still match the use case, whether the publisher remains accountable, and whether the app’s runtime behaviour has changed since the first click.

OAuth grants and service-account governance are converging: both create durable access that outlives the moment of approval, which means lifecycle controls matter as much as initial authorisation. For IAM and IGA teams, that shifts the programme from one-time app vetting toward continuous entitlement hygiene across SaaS and developer systems.

For practitioners

• Inventory all OAuth grants across marketplaces Map every approved third-party app to the scopes it holds, the publisher domain behind it, and the business systems it can reach. Prioritise grants touching mail, files, repositories, calendar, secrets, or CI workflows.
• Challenge over-broad scopes at approval time Compare requested permissions with the app’s stated purpose and reject grants where the scope set is materially wider than the use case. Pay special attention to write, delete, and organisation-level permissions.
• Verify publisher domain continuity Check whether the domain behind the app is still active, owned, and supportable before leaving a grant in place. Dead or buyable domains should trigger immediate review because they weaken accountability and recovery trust.
• Place AI-powered apps under tighter grant review Require additional scrutiny when a granted app can make its own runtime decisions about sending, editing, or managing content. The same scope is materially riskier when a model decides when to use it.

Key takeaways

• Marketplace listings are not a trustworthy proxy for OAuth app safety because the real risk lives in the scopes, the publisher, and the post-consent behaviour.
• This research found widespread over-privilege, stale publisher infrastructure, and AI-driven write access, showing that OAuth grants can remain risky long after installation.
• The practical response is to govern OAuth grants continuously, with tighter review for scope breadth, publisher continuity, and model-driven runtime actions.

Key terms

• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Over-Privileged App: An application that requests or retains more permission than its stated purpose requires. In OAuth and NHI governance, over-privilege increases blast radius because any compromise, misuse, or publisher change can expose systems the app never legitimately needed to reach.
• Publisher Accountability: The practical ability to identify, contact, and trust the party behind a third-party app for the full lifetime of its access. When domains are dead, parked, or for sale, accountability weakens and the grant becomes harder to defend or recover.

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.