CNAPP visibility stops at the SaaS boundary

At a glance

What this is: This article argues that strong cloud security does not eliminate SaaS breach risk because the most important attack paths now run through integrations, OAuth, and non-human identities outside CNAPP visibility.

Why it matters: For IAM and security teams, the message is that cloud posture tooling and SaaS ecosystem governance solve different problems, and the integration layer now needs its own identity controls.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Vorlon's analysis of CNAPP limits in SaaS security

Context

CNAPP tools were built to give security teams visibility into cloud workloads, identities, misconfigurations, and attack paths. That model works when the primary risk lives inside AWS, Azure, GCP, or Kubernetes, but it weakens when business-critical data and access move through SaaS integrations, OAuth tokens, and non-human identities that sit outside the cloud boundary.

The primary governance gap is not a lack of cloud telemetry. It is that enterprise access now extends into a SaaS ecosystem where approval, usage, and data movement can occur without cloud-native monitoring seeing the full chain. For identity teams, that turns SaaS integrations into an identity governance problem as much as a cloud security problem.

The article's starting position is typical for modern enterprises: cloud controls are mature enough to create confidence, while the most consequential risk has shifted to the integration layer they do not own end to end.

Key questions

Q: Where does CNAPP fail in SaaS environments?

A: CNAPP fails when the important access path is not inside the cloud boundary. SaaS-to-SaaS movement, OAuth delegation, and vendor-managed integrations can all be legitimate while still creating abuse paths that cloud-native tooling cannot fully observe. The gap is architectural, not cosmetic.

Q: Why do SaaS misconfigurations cause so many breaches?

A: They cause breaches because access and visibility errors often expose data directly, without requiring an exploit chain. In SaaS, a confused permission model, a permissive default, or a missed logging setting can create immediate impact. That makes configuration quality a core control, not a cosmetic one.

Q: How should security teams govern third-party OAuth access for SaaS integrations?

A: Treat third-party OAuth grants as NHI assets with owners, scopes, and lifecycle rules. Require approval for high-risk permissions, inventory refresh-token use, and define revocation triggers for staff changes, app changes, and anomalous activity. The goal is to make delegated access visible enough to review and fast enough to remove.

Q: What is the difference between CNAPP and SaaS security?

A: CNAPP secures cloud infrastructure, workloads, and cloud identities. SaaS security governs the access paths, integrations, and data movement that happen between business applications, often through OAuth tokens and non-human identities. They are complementary, but they answer different risk questions.

Technical breakdown

Why CNAPP visibility stops at SaaS integrations

CNAPP platforms are optimized for infrastructure signals, workload relationships, and cloud identity exposure inside a defined cloud boundary. They can show misconfigurations, attack paths, and privilege relationships in the environment they can observe, but SaaS-to-SaaS access is mediated by vendor-managed applications, OAuth grants, and external data flows. That means the security event may not look like a cloud compromise at all. The control plane is still useful, but it is blind to the integration layer where access can persist and data can move without a cloud workload being touched.

Practical implication: map where your SaaS integrations begin and end, then treat that boundary as a separate identity control domain.

OAuth tokens and third-party apps as an identity layer

OAuth is the connective tissue of modern SaaS, but it also creates durable delegated access that is easy to forget once approved. Tokens can outlive their business purpose, permissions can be broader than intended, and dormant third-party apps can keep moving data long after the original approval looked harmless. In identity terms, this is not just an application risk. It is a non-human identity problem because the access is exercised by a credential or token, not by a person. Traditional cloud IAM views the grant as legitimate; the abuse happens in how that grant is used.

Practical implication: inventory OAuth grants and third-party app entitlements as NHI assets, not just application settings.

AI agents change the SaaS risk model further

AI agents operating across SaaS tools are also non-human identities, but they introduce a higher operational tempo than ordinary integrations. They can chain actions, call multiple tools, and continue operating without human intervention, which makes simple access reviews less informative. The important issue is not whether an integration exists. It is whether the actor using it can decide when and how to act across multiple systems. That pushes governance beyond static approval toward runtime observability and identity-aware policy enforcement across SaaS workflows.

Practical implication: classify AI-driven SaaS workflows separately from conventional service accounts and review their delegated scope as a distinct identity class.

Threat narrative

Attacker objective: The attacker wants persistent, low-friction access to SaaS data and workflows without triggering cloud security controls.

1. Entry occurs through a legitimate SaaS approval path, most commonly an OAuth grant or trusted third-party integration.
2. Escalation happens when the granted token or integration is over-permissioned, forgotten, or reused across multiple applications.
3. Impact follows when sensitive data moves between SaaS tools outside cloud-native visibility, allowing quiet abuse without a cloud workload compromise.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

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

NHI Mgmt Group analysis

CNAPP was designed for cloud-origin risk, not ecosystem-origin risk. That assumption fails when the most sensitive business workflows live in SaaS applications that exchange data through OAuth, APIs, and third-party integrations. The implication is that cloud security maturity can coexist with blind spots at the integration layer, so practitioners must stop treating cloud coverage as a proxy for SaaS governance.

OAuth delegation has become a standing NHI exposure pattern. Once an application is approved, the access often persists long enough to be forgotten, reused, or overextended across adjacent tools. This is not a patching problem or a misconfiguration problem alone. It is a lifecycle and accountability problem for non-human access, and it belongs in the same governance conversation as service accounts and workload identities.

SaaS ecosystems now create identity blast radius outside the cloud boundary. The article's core insight is that the risk is no longer contained to a single platform but distributed across vendors, integrations, and machine identities acting on behalf of the enterprise. That makes the blast radius harder to see and harder to certify, which means identity governance has to follow the data path, not just the infrastructure path.

AI agents amplify the SaaS governance gap because they shorten decision cycles. A human approval model assumes a reviewable grant and a stable operator, but an AI agent can chain actions across tools continuously. That does not make every agent autonomous, but it does mean runtime behaviour can escape the cadence of traditional access review. Practitioners should treat AI-driven SaaS access as a distinct governance class, not a variant of normal integration management.

Vorlon's central point is not that CNAPP is obsolete, but that its job is narrower than many security programmes assume. Cloud-native controls still matter inside the boundary they can observe, yet enterprise identity risk increasingly lives in the layer between cloud and SaaS. Identity teams should interpret that boundary as a programme design issue, not a product gap, and then align controls to where delegated access actually operates.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• That pattern is why The 52 NHI breaches Report remains a useful next reference for understanding recurring access failure modes.

What this signals

SaaS identity governance now needs its own control plane. Cloud posture and SaaS governance are converging only in the sense that both depend on identity, but they operate at different layers. Teams should expect more blind spots until they separate cloud workload visibility from SaaS integration visibility and assign ownership accordingly.

Identity blast radius is expanding beyond infrastructure. When OAuth grants, third-party apps, and AI-driven workflows can move data between vendors, the material risk is no longer limited to a single environment. That makes lifecycle review, entitlement scoping, and access ownership central to SaaS security planning.

With 72% of organisations reporting or suspecting an NHI breach, the broader lesson is that unmanaged machine access is already normalised in many environments. Security programmes that stop at cloud infrastructure will keep missing the places where delegated access actually accumulates.

For practitioners

• Define the SaaS identity boundary List the SaaS applications, OAuth grants, and third-party integrations that sit outside your CNAPP coverage and assign ownership for each one. Use that inventory to distinguish cloud risk from ecosystem risk and to identify the non-human identities that can move data without cloud telemetry.
• Review durable delegated access Audit tokens and integrations that were approved once and never revisited, especially where permissions exceed the current business need. Focus on dormant access, cross-application permissions, and any integration that can reach sensitive data or trigger downstream automation.
• Treat AI-driven workflows as a separate identity class Separate conventional service accounts from AI agents that can chain tool calls across SaaS applications. Record where runtime behaviour can change the order, timing, or combination of actions, then apply tighter approval and monitoring to those flows.
• Extend access reviews beyond cloud IAM Add SaaS integrations, API keys, and vendor-managed access paths to recertification so reviewers can see who or what is actually moving data between applications. Cloud-only access reviews miss the integration layer where these risks accumulate.

Key takeaways

• Cloud security visibility does not eliminate SaaS breach risk when the real attack path runs through delegated access and integrations.
• The strongest evidence in this article is architectural: OAuth tokens, third-party apps, and AI agents operate in a layer CNAPP was not built to govern.
• Practitioners need separate identity controls for SaaS integrations, because lifecycle, ownership, and runtime behaviour all differ from cloud-native access management.

Key terms

• SaaS Integration: A SaaS integration is a trusted connection between cloud services that moves data or actions through authenticated APIs. From an identity perspective, each integration creates a non-human access path that needs ownership, scope control, monitoring, and revocation just like any privileged account.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• CNAPP Boundary: The CNAPP boundary is the portion of cloud risk a CNAPP platform can actually observe and prioritize. It includes workloads, cloud identities, and infrastructure signals, but not the wider SaaS ecosystem where OAuth, third-party applications, and data movement may continue unchecked.

What's in the full article

Vorlon's full article covers the operational detail this post intentionally leaves for the source:

• A breakdown of SaaS-to-SaaS visibility gaps and where CNAPP coverage ends.
• Examples of OAuth and integration abuse patterns that security teams can use for investigation planning.
• A closer look at how non-human identities and AI agents change the SaaS threat model.
• The vendor's view of where ecosystem security complements cloud-native controls.

👉 Vorlon's full article covers the SaaS integration boundary, OAuth exposure, and ecosystem visibility gaps.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.