
Hoplite Labs

The Quiet SaaS Risks Nobody Tracks
Hoplite Labs
A team spins up a new reporting function that integrates a SaaS tool into the environment. OAuth scopes are approved, API permissions are granted, and identity trust is extended so that the workflow functions properly. Nothing about the process feels reckless.
The new project goes live. The teams involved move on.
Over time, organizations change. People get reorganized, and project ownership shifts. Yet access survives and becomes operational infrastructure rather than an actively reviewed decision.
Most companies don’t intentionally preserve risky access. It simply survives longer than expected.
That challenge compounds as organizations grow. The average company now runs over 100 SaaS applications, while IT often directly owns only a fraction of them. Business units buy tools independently. Integrations accumulate across departments. The old reporting connector survives because nobody wants to discover during quarter close that finance still depends on it.
Eventually, access relationships grow faster than anyone can consistently track or review them.
That gap presents a growing attack surface.
Attackers Rely More on Trust Than Exploits
Modern cloud intrusions now rely on abusing legitimate trust relationships instead of forcing direct access through traditional intrusion paths. Many of these intrusions rely on legitimate identities, sessions, and inherited permissions through mechanisms like:
Stale credentials
Session theft
OAuth misuse
Overprivileged service accounts
Inherited application permissions
Third-party integrations and inherited permissions now play a larger role in expanding these attack paths. Verizon’s DBIR found that in 2025, the percentage of breaches where a third party was involved doubled from 15% to 30%. Google’s Cloud Threat Intelligence research also found weak or absent credentials contributed to nearly half of investigated incidents.
These patterns don’t depend on exotic exploitation. All it takes is access that already exists.
If nobody is validating those access relationships, attackers can operate through trust the environment already recognizes as legitimate.
SaaS Risks Grow Quietly
As SaaS adoption expanded, governance and visibility rarely kept pace. When organizations connect over 100 SaaS applications to business workflows, identity systems, and shared data stores, visibility naturally degrades.
While teams often have resources to vet new tools, the more persistent risk usually comes from older integrations nobody wants to accidentally break.
Over time, older integrations gradually drift away from active governance:
Original ownership changed hands.
Broad setup permissions remained in place long after deployment.
Service accounts stopped being actively reviewed.
Old synchronization tooling became part of the environment.
If those relationships are never revisited, the environment gradually accumulates access that nobody fully understands anymore.
The recent Vercel compromise shows how quickly trusted third-party integrations can expose companies to downstream risk. Early indications show the intrusion started from a compromised third-party AI tool with OAuth permissions. That access allowed attackers into portions of Vercel’s Google Workspace environment.
The important detail wasn’t simply credential theft. Legitimate trust relationships granted broad downstream access once the OAuth token was compromised. The environment behaved exactly as configured.
Modern SaaS compromises increasingly look like authorized activity occurring within inherited trust relationships.
How Mature Teams Protect Environments
Teams in mid-market organizations have probably seen these challenges before. The issue is usually one of structure, not negligence.
These teams often run lean while procurement and SaaS adoption spread across the organization. When incidents arise, visibility is fragmented: identity logs sit in one platform, SaaS telemetry in another, and support workflows somewhere else entirely. In high-pressure environments, teams also hesitate to disturb working systems tied to reporting, finance, or operational workflows.
These teams aren’t understaffed relative to older infrastructure models. They’re understaffed relative to the number of trust relationships modern SaaS creates.
From our experience, mature teams handling these challenges well don’t govern everything equally. They approach the problem through disciplined validation.
Strong programs keep inventories of trust relationships, not just vendors. They routinely review OAuth grants and application permissions. They treat service accounts and machine identities as real identities with ownership, purpose — and retirement expectations.
They also focus on effective permissions instead of vendor documentation alone. Documentation may not explain what access currently exists within the environment, whether the integration is still required, and how broadly permissions are scoped. Those answers usually come only through recurring reviews of identity, permissions, integrations, and cloud posture.
Mature teams focus less on collecting every possible log and more on maintaining enough visibility to answer a few important questions quickly:
Who granted the access?
What scopes exist today?
Is the token or integration still active?
Who owns it operationally?
Has anyone used it recently enough to justify keeping it?
The strongest programs rarely rely on complicated governance structures. They continuously revisit old trust assumptions before attackers do.
Authorized Access Still Creates Exposure
Someone legitimately approved most modern SaaS exposure at some point. The problem is that legitimacy rarely expires on its own. Attackers increasingly operate through existing permissions and trust relationships because the environment already recognizes them as legitimate.
The most dangerous SaaS exposure today is often already-authorized access that nobody has validated recently.
—
Mature organizations continuously revisit old trust assumptions before attackers do. Recurring identity and posture reviews bring those trust relationships back into visibility before they become incident response problems.