OAuth marketplace listings do not equal approval or safe access

At a glance

What this is: This research argues that official marketplace listing does not imply safety, and shows how OAuth apps can carry over-broad scopes, dead publisher infrastructure, and AI-driven write access.

Why it matters: It matters because IAM teams must govern OAuth grants as living access paths across human, NHI, and emerging autonomous workflows, not as one-time approvals.

By the numbers:

• 677 apps ask for at least one permission beyond their stated function, representing a combined 1.82 billion installs.
• 206 apps have dead publisher domains.
• 49 AI-powered apps with broad write access represent an 81.6M install footprint.
• 4.39 billion.

👉 Read Offroad AI's research on OAuth marketplace risk and standing grants

Context

OAuth marketplace listings are often treated as a proxy for trust, but the underlying grant is what matters. Once a user consents, the app can retain access long after the original install moment, and that access may span email, files, calendars, repositories, CI workflows, organization settings, and secrets. For identity security teams, that means the real control boundary is not the marketplace badge but the lifecycle of the grant.

The article focuses on a familiar IAM failure mode: consent is easy to create and hard to retire. That creates a standing access path that survives user turnover, publisher abandonment, or a shift in app behaviour. In NHI terms, this is not just third-party risk. It is persistent delegated access that needs inventory, review, and revocation discipline.

The research also points to a harder problem for modern identity programmes. Some OAuth apps are increasingly mediated by AI components, which changes how granted access is used. A scope screen may look identical, but the actor behind the grant may now choose actions dynamically, making traditional assumptions about deterministic app behaviour less reliable.

Key questions

Q: What breaks when marketplace-listed OAuth apps are treated as approved by default?

A: What breaks is the assumption that a marketplace badge means the app is safe, proportionate, or still accountable. OAuth consent creates standing delegated access, so a listed app can still carry excessive scopes, outlive its publisher, or continue operating after the original risk decision has changed. Governance has to follow the grant, not the badge.

Q: Why do OAuth apps create persistent identity risk for IAM teams?

A: OAuth apps create persistent identity risk because the access token or grant can remain active long after the point of approval. That makes them behave like non-human identities with lifecycle, review, and revocation requirements. IAM teams need to manage who owns the grant, what it can do, and whether it still needs to exist.

Q: How do security teams know whether an OAuth app is over-privileged?

A: Security teams should compare the app’s actual business function with the permissions it requests and then look for delete, admin, or cross-system scopes that are not essential. A useful test is whether the app could still do its job with narrower access. If the answer is yes, the current scope is excessive.

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

Standing OAuth grants and access persistence

OAuth consent creates delegated access that can outlive the moment of approval. The marketplace does not automatically expire that grant when the user leaves, the app changes hands, or the publisher disappears. In practice, the real exposure sits in the combination of scope breadth, grant duration, and lack of lifecycle controls. That is why OAuth must be treated as part of the identity estate, not just as an application permission model.

Practical implication: inventory active grants and build revocation into joiner-mover-leaver and third-party offboarding workflows.

Over-broad scopes and consent-screen blind spots

The consent screen shows requested permissions at the point of approval, but it does not explain whether the scope is broader than the app’s purpose or whether the platform forces overly coarse permissions. Some apps request delete-capable access even when they only need write access, because the scope catalog itself may not offer a narrower alternative. That makes the permission model structurally permissive before any administrator evaluates the app.

Practical implication: review scopes against actual app function, not marketplace presence, and challenge coarse scopes before approval.

AI-powered OAuth apps and runtime agency

An AI-powered app can behave differently from a deterministic utility even when the consent screen is identical. If the model monitors inboxes, drafts responses, and decides when to act, the grant is no longer just machine-to-machine access. It becomes a runtime decision path where the timing and rationale for each action may shift with prompts or model updates, which weakens assumptions behind conventional OAuth governance.

Practical implication: classify AI-mediated OAuth apps separately and require tighter monitoring, logging, and approval boundaries.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 presence is not a control, and treating it like one creates false assurance. Official listing only proves an app met marketplace submission rules, not that its scopes are proportionate, its publisher is still accountable, or its runtime behaviour remains stable. That gap is especially dangerous in OAuth, where the grant itself becomes the access path. Practitioners should treat marketplace trust as an intake signal, not a governance outcome.

Persistent delegated access is the real NHI failure mode here. OAuth apps behave like non-human identities once the grant exists, because the access can continue silently after installation and survive organizational churn. That makes lifecycle governance, not just initial approval, the decisive control plane. For identity teams, the key question is whether granted access can be inventoried, reviewed, and revoked with the same discipline applied to service accounts.

Over-broad scope catalogs create identity blast radius before an attacker ever arrives. When a platform cannot separate a legitimate write action from a delete-capable permission, it forces administrators to accept excess privilege at consent time. That is a governance design problem, not merely a developer mistake. The practitioner conclusion is clear: scope design and grant review must be treated as part of the security architecture.

AI-mediated OAuth access introduces runtime agency into a model built for static delegation. The article’s AI examples show why the same scope can carry very different operational risk when a model decides when to send, edit, or act. That shifts the issue from who clicked consent to what the actor does after consent. Governance now has to distinguish human-driven delegation from dynamic machine decision-making.

Ephemeral credential trust debt: OAuth was designed for delegated access that could be reasoned about at approval time, but that assumption breaks when consent persists, publishers disappear, and AI systems alter action timing after authorization. The implication is that practitioners must rethink access as a living, revocable relationship rather than a one-time approval event.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• The governance issue extends beyond this post, so review Ultimate Guide to NHIs , Key Challenges and Risks for the broader control patterns behind OAuth sprawl and over-privilege.

What this signals

Ephemeral credential trust debt: OAuth programs accumulate hidden risk when consent persists beyond the business context that justified it. That debt shows up as grants with no owner, no lifecycle review, and no clear retirement path, which is why identity teams need a grant-level inventory rather than a Marketplace-approved list.

With 70% of organisations granting AI systems more access than they would give a human employee performing the same job, according to the 2026 Infrastructure Identity Survey, the boundary between delegated access and autonomous execution is already blurring. Teams should expect OAuth governance to merge with AI governance, especially where models can trigger mail, file, or repo actions.

If your programme already struggles with third-party OAuth visibility, the next failure mode is not just sprawl. It is unowned access that survives role changes, publisher changes, and model behaviour changes, which means recertification, offboarding, and logging have to be redesigned as one control chain rather than three separate tasks.

For practitioners

• Reconcile every active OAuth grant against business need Build an inventory of all marketplace-connected grants, then compare each scope to the app’s current function and owner. Any grant without a named business owner, support path, or current usage should move to revocation review.
• Treat publisher infrastructure as part of the trust decision Check whether the publisher domain is active, supportable, and controlled before approving or renewing high-scope apps. Dead or buyable domains should trigger revalidation because publisher reachability is part of accountability.
• Separate AI-mediated grants from deterministic apps Flag OAuth apps that use AI to generate, schedule, or execute actions on behalf of users. Require tighter logging for mail sends, file edits, repo changes, and calendar actions when model decisions influence runtime behaviour.
• Restrict coarse scopes before installation Reject apps that request delete-capable or admin-level scopes when the business function only needs read or write access. Where the platform forces broad scopes, document the exception and schedule a shorter review cycle.
• Tie OAuth review to offboarding and recertification Add marketplace grants to access reviews, third-party offboarding, and user departure workflows so access does not persist after the original operator or publisher relationship changes.

Key takeaways

• Marketplace presence does not equal trust, because OAuth consent can create persistent delegated access long after installation.
• The research shows a large-scale privilege mismatch, with hundreds of apps requesting more access than their stated purpose requires.
• IAM teams should govern OAuth grants as living identity objects, especially where AI-mediated actions or abandoned publisher infrastructure increase exposure.

Key terms

• OAuth grant: An OAuth grant is the delegated authorization that allows an application to act on a user’s behalf without knowing the user’s password. In practice, it becomes a standing access object that can persist beyond installation and must be governed like any other identity entitlement.
• Publisher infrastructure: Publisher infrastructure is the domain, email, and account-recovery environment that ties a third-party app to a responsible operator. If that infrastructure dies, becomes unowned, or is compromised, the trust relationship behind the app weakens even when the app itself still appears to work.
• Consent-screen blind spot: A consent-screen blind spot is the gap between what a user can see at authorization time and the real operational risk of the grant. It hides whether scopes are overly broad, whether the publisher remains accountable, and whether the app’s runtime behaviour is deterministic or model-driven.
• Ephemeral credential trust debt: Ephemeral credential trust debt is the hidden risk created when a temporary-seeming approval becomes persistent access. The grant may start as a narrow convenience, but without lifecycle controls it accumulates exposure over time, especially when ownership, publisher status, or runtime behaviour changes.

Deepen your knowledge

OAuth grant lifecycle and over-privilege are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern marketplace-connected access at scale, it is worth exploring.

This post draws on content published by Offroad AI: Introducing OhAuth and the state of OAuth app exposure. Read the original.