In cybersecurity, the old adage "trust but verify" emphasizes that granting trust should always be accompanied by oversight. Yet, with software-as-a-service (SaaS), organizations often stop at the "trust" part and never get around to the "verify."

SaaS environments in 2025 run on implicit trust. Once a user or app is authenticated and given access, it's largely trusted indefinitely. Tokens issued to third-party apps rarely expire, integrations often get more permissions than they truly need, and automations execute with minimal human oversight.

We talk about Zero Trust principles, but in practice, many SaaS platforms grant one-time approval and then assume all is well thereafter. The result is a growing security gap, where credentials and connections are implicitly trusted far beyond what's safe, creating fertile ground for breaches and abuse.

Implicit Trust in the SaaS Ecosystem

Every SaaS integration or API token represents an implicit trust relationship between your organization and some third-party service. Once a user clicks "Allow" and grants an app access to their corporate account, that app is effectively treated as a trusted extension of your environment. This wouldn't be a problem if that trust were continually examined, but it usually isn't.

Consider OAuth tokens that never get revoked or rotated: many can remain valid for months or even years, and in some cases, unless explicitly revoked by an admin, they may never expire at all. That means a connected app from last year, perhaps a marketing tool or a productivity plugin, could still have unfettered access to your data today, even if no one is actively using it.

Moreover, these third-party apps are often given far more permissions than necessary. It's common for an app to request broad scopes (sometimes the infamous "allow all" access), and busy users will grant them just to get the tool working. If an app only needs read access to a calendar, it might still ask for edit and delete permissions, and receive them.

This implicit trust extends to automation as well. Businesses sometimes rely on automation bots and scripts to perform tasks across cloud apps, pulling data, integrating systems, auto-generating reports, and so on. These automations run using API keys or tokens (machine credentials) that carry a lot of privileges. But once they're set up, they tend to run with minimal oversight.

The Zero Trust Gap – Verification Only Happens Once

The irony amongst all of this is that many organizations tout the Zero Trust philosophy, "never trust, always verify," but their SaaS practices amount to "trust once, then never verify again."

If an employee installs a third-party SaaS app, there's an initial OAuth authorization screen, the one time that permissions and identity are verified. After clicking Allow, the verification stops. The app receives a token and now has persistent access in the background. There is typically no built-in mechanism to re-check that token's legitimacy or intent with each use.

In effect, OAuth and API tokens grant persistent trust between apps with no further verification. Your Single Sign-On (SSO) and MFA might protect the front door for user logins, but these tokens bypass those controls entirely. There's no pop-up to re-authenticate when a connected app uses its token to query data, the app just presents the token, and it's assumed valid.

In many cases, once an integration is approved, there isn't even an annual review to ask, "Do we still need this access?" or "Is this app behaving as expected?" The "verify" step of "never trust, always verify" effectively ends on day one. After that, it's an honor system, which cybercriminals are more than happy to exploit.

Tokens and Apps - The New Blind Spot in Security

All of these unmonitored tokens and over-privileged apps have created a glaring blind spot in security programs. Security teams traditionally excel at monitoring user logins, endpoint activity, and network traffic, but SaaS tokens and integrations often fly below the radar of these tools.

We've seen this play out in multiple breaches over the years.

In early 2023, for instance, Slack revealed that cybercriminals stole employee tokens and used them to access internal code repositories, bypassing the need for any password login. Around the same time, CircleCI suffered an incident where malware on an engineer's laptop snagged a session token, allowing intruders to impersonate that engineer and steal sensitive customer secrets. In both cases, one token in the wrong hands undermined the usual security controls.

Fast forward to 2025, and attackers have gotten even bolder. The Salesloft/Drift breach is a prime example: cybercriminals breached a SaaS chatbot provider (Drift) and stole OAuth tokens for its integration with Salesforce. Those tokens, meant to let the chatbot access Salesforce data on behalf of customers, were turned into skeleton keys.

Another group, ShinyHunters, took a more social route: they tricked employees via phishing/vishing to obtain OAuth access to companies' SaaS accounts. In mid-2025, they hit firms like Google and Workday by convincing insiders to authorize a malicious app or reset a password, thereby granting the attackers a foothold in Salesforce without hacking the platform's code.

Once inside, the malicious app behaved like any other connected app, pulling data until it was discovered. Again, there was no continuous check on what that app was doing beyond the initial "yes, I trust this app" click.

Continuous Verification - Behavior Over Credentials

In a genuine Zero Trust model, access serves as a continuous assessment rather than a single checkpoint. Ongoing verification is concerned with the distinction between observed and granted privilege.

The term "granted privilege" describes the initial access we granted a user or token, such as "this API key can read customer data." The term "observed privilege" describes how that access is actually used. For example, "this API key usually reads 10 records from a particular IP range every day between 9 a.m. and 5 p.m". By keeping an eye on the behavior, we can spot instances in which a token or application deviates from its intended use or pattern.

If that customer-data API key suddenly tries to export the entire database at 2 a.m., that's a huge red flag. If a normally quiet integration service account begins accessing sensitive finance records it has never touched before, that's cause for immediate investigation. In essence, continuous verification is about continuously asking: "Does this behavior make sense for this identity?"

Gartner's CARTA (Continuous Adaptive Risk and Trust Assessment) model encapsulates this approach: "never trust, always verify" continuously, in real time, adapting to what the system observes. The goal is to move from our current static trust model to one where trust is constantly earned and re-earned through good behavior.

Conclusion - Trust, But Continuously Verify

The problem with "trust but verify" today is not that the motto is wrong; it's that we haven't been truly following it. We trusted, and then we forgot to verify. To close this security gap, we should think about embracing the notion that trust is not a one-time decision.

Every access, whether human or machine, should be subject to questioning: Is this request normal? Is this use of privilege justified? This mentality turns Zero Trust from a slogan into an operational reality, and this is exactly where Reco closes the loop.

Reco continuously analyzes granted privileges versus observed behavior across SaaS identities, tokens, and third-party apps. It identifies when behavior drifts from what is normal, expected, or safe. Instead of relying on blind, persistent trust, Reco shows you overprivileged apps, misused tokens, and integrations that begin to operate outside their baseline.

It brings real-time verification to the parts of the SaaS ecosystem where verification has been historically missing.

Click here to get started today: Request a Demo: Get Started With Reco.

About the Author: Gal is the Cofounder & CPO of Reco. Gal is a former Lieutenant Colonel in the Israeli Prime Minister's Office. He is a tech enthusiast, with a background of Security Researcher and Hacker. Gal has led teams in multiple cybersecurity areas with an expertise in the human element.

Gal Nakash — CPO and Cofounder at Reco https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuQWbnqXQszfF7Ro1ckEfpJAt4R_6RI4pi_EParenaMvBTPNTZ5vs91QXTU7w_7mZukKntRojMFYpgQRTBFYFTFRnP9zaj8KrlfFrkG8Rwo_GjkEFsNt4pbGhmI2aoJHB-ENuTVLOKGQUDy_hxD3Fiy4dSlhRlnZA5jyqfkyKbUpdUx6ZCD8op9n6uo90/s728-rw-e365/Gal.png
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter and LinkedIn to read more exclusive content we post.