SaaS integration abuse is exposing secrets across connected apps

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Bishop Fox's blog post: Two active threat patterns use OAuth phishing, overprivileged SaaS integrations, and stolen secrets to expand from one cloud app into others.

Why it matters: It matters because SaaS integrations now behave like identity pathways, so teams need visibility into tokens, app permissions, and cross-app trust before attackers turn one compromise into broader access.

Context

SaaS integration abuse is a governance problem as much as an intrusion problem. When third-party apps, OAuth grants, and service credentials are loosely scoped, attackers can move from one trusted application into others without needing to break the underlying cloud platform.

The article’s focus is on two concurrent threat patterns: one built around phishing and credential theft, the other around deeper abuse of SaaS integrations and harvested secrets. For IAM and NHI teams, the key issue is that these integrations often function as non-human identities with privileges, persistence, and access paths that are poorly inventoried.

The article also makes clear that the control gap sits with customers, not just the SaaS provider. That is typical of modern SaaS environments, where the owning organisation often lacks full visibility into where secrets live, what each integration can access, and how far one compromised token can travel.

Key questions

Q: What breaks when organisations leave standing privilege in SaaS integrations?

A: Standing privilege turns a stolen or abused token into a long-lived access path. If the integration stays authorised after the task is complete, the attacker can keep using it until someone notices. That breaks containment, widens blast radius, and makes secret exposure more likely. The control gap is not only authentication, but the failure to expire access when risk changes.

Q: Why do stolen SaaS tokens create such a large breach impact?

A: Stolen tokens often bypass the strongest login controls because they represent already-approved sessions or delegated access. That means the attacker can act inside trusted workflows, sometimes with the ability to read data, send messages, or perform bulk actions without a new authentication challenge.

Q: What are the signs that a SaaS-to-SaaS integration has been compromised?

A: Look for unusual query volume, bulk data exports, unexpected changes to integration behavior, and access from unfamiliar infrastructure. In a Salesforce-linked incident, suspicious activity often shows up in API logs as repeated query bursts rather than interactive logins. Because trusted integrations blend into routine operations, anomaly detection has to focus on access patterns, not just failed authentication events.

Q: Who is accountable for securing SaaS integrations that create blind spots across an organisation?

A: Accountability sits with the organisation that approves, connects, and monitors the SaaS environment, not with the connectivity alone. Security, identity, and application owners should define minimum control expectations for every integration, including access scope, logging, review, and revocation. Where vendors publish inconsistent data, internal governance must compensate with standards, evidence collection, and ongoing oversight.

Technical breakdown

How OAuth phishing turns a SaaS login into downstream access

OAuth phishing exploits user trust in consent flows rather than cracking passwords directly. If a user approves a malicious or overbroad application, the attacker receives delegated access tokens that can operate inside the SaaS tenant with the permissions granted. In practice, that means the attacker inherits the reach of the approved integration, which may include reading data, exporting records, or chaining into other connected services. The risk rises sharply when the tenant does not separate human sign-in from machine-to-machine authorisation. This is where SaaS apps start to resemble an identity estate, not just a software stack.

Practical implication: review OAuth grants as privileged access paths and revoke any app that can request more scope than its business function requires.

Why overprivileged integrations become a lateral movement path

A SaaS integration becomes a lateral movement path when it can authenticate across multiple applications or APIs using long-lived secrets, broad scopes, or reused service accounts. The article shows an attacker harvesting secrets, tokens, and credentials, then using them to pivot from one SaaS environment into others, including infrastructure such as AWS. That is a classic identity chaining problem: one compromised non-human identity opens multiple adjacent systems because the trust boundary is defined by convenience rather than lifecycle governance. If the integration can query objects or export data it never needs, it is already overexposed.

Practical implication: treat integrations as non-human identities with explicit scope limits, separate credentials, and lifecycle ownership.

Why detection fails when attacker activity blends into normal cloud traffic

These campaigns are harder to spot because the malicious activity often originates from commercial cloud hosts and uses legitimate-looking API or web application traffic. That makes simple anomaly detection less effective, especially when security teams only monitor for mass exfiltration or obvious malware indicators. The real signal is often in the pattern of access, such as unusual object queries, secret harvesting, or integration behaviour that does not match the approved business use case. In other words, the attacker is not bypassing the platform so much as abusing its identity model.

Practical implication: monitor SaaS logs for unusual API scope use, secret access, and integration behaviour that diverges from declared purpose.

Threat narrative

Attacker objective: The objective is to turn one trusted SaaS foothold into reusable access across multiple applications, enabling data theft and broader compromise.

1. Entry occurs through OAuth phishing or compromise of the SaaS integration layer, giving attackers a foothold inside trusted business applications.
2. Credential access follows when the attacker harvests secrets, tokens, and credentials from connected apps or misconfigured integrations.
3. Escalation and lateral movement happen as those stolen credentials are reused across other SaaS applications and even infrastructure such as AWS.
4. Impact is data theft, ransomware pressure, and wider tenant compromise across connected environments.

Breaches seen in the wild

• Snowflake breach: Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Integration abuse is now an identity problem, not just a SaaS problem. The article shows attackers using OAuth grants, tokens, and service credentials as reusable access rather than as one-off session artefacts. That changes governance expectations because each integration must be treated as a non-human identity with scope, ownership, and revocation requirements. For practitioners, the right control lens is lifecycle and privilege, not only application hardening.

Secret discovery is the real containment failure. The article’s warning that most SaaS customers do not know where these secrets are stored is the critical point. If teams cannot inventory where tokens, credentials, and secrets live, they cannot scope blast radius after compromise. This is a classic secret visibility gap that turns normal SaaS sprawl into a governance blind spot. Practitioners need to assume hidden secret repositories until proven otherwise.

Least privilege must extend to connected apps and service identities. The examples in the article show integrations querying objects and moving across systems that they never needed for legitimate work. That is the definition of overprivileged NHI behaviour inside SaaS. In NHIMG terms, the named concept here is SaaS identity sprawl: unmanaged integration identities that accumulate reach across tenants and adjacent services. Practitioners should measure every integration against actual business purpose, not inherited platform defaults.

Detection has to move from exfiltration volume to access pattern analysis. The article makes clear that attackers can blend into commercial cloud traffic while targeting a small set of high-value secrets. That means volume-based alerts alone will miss the activity. Teams need to look for uncommon object access, secret harvesting, and integration behaviour that does not match declared workflows. For practitioners, the monitoring question is whether logs can distinguish legitimate automation from identity abuse.

Customer responsibility is the governance breakpoint. The article explicitly states that prevention and detection configurations sit with the customer, not the SaaS provider. That puts SaaS access governance squarely into IAM, PAM, and NHI programmes, especially where integrations are granted broad cross-app reach. The practical conclusion is that SaaS assurance has to be owned as part of the identity programme, not delegated to the application vendor.

From our research library:

• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.

What this signals

SaaS identity sprawl: connected applications increasingly behave like unmanaged non-human identities, and the governance gap is no longer only about who can log in. The harder problem is knowing which integrations hold tokens, what they can reach, and how to revoke them without breaking business workflows.

For identity programmes, this pushes SaaS governance into the same operational category as machine identity management. Access reviews that only cover human accounts will miss the credentials that matter most when attackers are harvesting secrets and moving laterally across connected apps.

For practitioners

• Inventory all SaaS integrations as non-human identities Build a register of every OAuth app, service account, and API credential across your SaaS estate, including who owns it, what it can access, and when it was last reviewed.
• Reduce integration scope to the minimum required objects Remove broad object-level access, shared integration profiles, and inherited admin-style permissions from SaaS connectors that do not need them.
• Restrict SaaS and integration access by IP and known hosts Apply IP restrictions to user and integration access wherever the platform allows it, and reject vendors or connectors that cannot support fixed egress ranges for their automation.
• Monitor for secret harvesting and unusual integration behaviour Alert on token export, secret access, atypical object queries, and integrations that start behaving like data collection tools instead of narrowly scoped business automation.

Key takeaways

• The article shows that SaaS compromise now often travels through integrations, OAuth grants, and stolen secrets rather than only through direct account takeover.
• The main control failure is poor visibility into where tokens and credentials live, which makes containment and scoping difficult once an integration is abused.
• IAM and NHI teams need to govern connected apps as non-human identities, with least privilege, IP restrictions, and stronger monitoring of secret use.

Key terms

• OAuth App Consent Phishing: A social engineering technique that tricks users into granting a malicious application access to their accounts or data. The app appears legitimate, but the consent flow is used to gain foothold, collect tokens, or redirect the victim into a credential capture page that can lead to account takeover.
• SaaS Integration Abuse: The misuse of trusted cloud application connectors, service accounts, or API-linked automations to move data or access between platforms. It becomes a governance issue when those integrations hold broad permissions, long-lived secrets, or undocumented reach across the SaaS estate.
• Secret Harvesting: Secret harvesting is the extraction of credentials, tokens, or keys from an execution environment rather than from an authentication flow. It often targets files, memory, environment variables, and local configuration, which makes trusted developer and CI contexts high-value targets.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.