SaaS security is shifting from posture to identity control planes

At a glance

What this is: This is a webinar analysis of why SaaS security is shifting from CASB and SSPM toward SaaS Security Control Planes as identity and AI-linked access become the dominant risk surface.

Why it matters: IAM, NHI, and SaaS security teams need to treat delegated access, OAuth grants, service accounts, and AI-connected apps as one governed ecosystem rather than separate controls.

By the numbers:

• Public SaaS and AI-related attacks increased nearly 490% year over year, according to Grip Security's 2026 SaaS + AI Security Report.

Context

SaaS security now depends on governing identities and delegated access, not just monitoring cloud app usage or checking posture. CASB and SSPM each solved a narrower problem, but they do not fully address how OAuth grants, service accounts, non-human identities, and AI-connected apps create cross-application risk.

Grip Security frames the current problem as a control-plane gap: security teams can see applications and configurations, yet still lack continuous governance over the identity relationships that actually move data and permissions. That makes the primary question one of operating model, not tool count.

The article's framing is typical of modern SaaS environments, where identity sprawl and embedded AI features expand the number of access paths faster than manual review cycles can absorb.

Key questions

Q: What breaks when SaaS security stays focused on posture instead of identity control?

A: Teams miss the delegated access paths that actually move data and permissions across applications. A SaaS app can look secure in configuration terms while OAuth grants, service accounts, or connected AI workflows still expose the environment to abuse. The failure is not visibility alone, but incomplete governance over who or what can act inside the SaaS estate.

Q: Why do OAuth apps and service accounts create more risk than their user-facing setup suggests?

A: They create risk because the visible installation is usually less important than the permissions behind it. A single OAuth grant or service account can silently inherit access to mail, source code, tickets, or cloud resources. If those permissions are broad or poorly tracked, an attacker who steals the token gets immediate operational reach.

Q: How can teams tell whether SaaS governance is actually working?

A: Look for evidence that discovered applications can be assigned an owner, tied to an access policy, and removed through an enforced workflow. If the platform can only report on SaaS usage but cannot drive deprovisioning or entitlement review, governance is still fragmented.

Q: How should security teams govern AI features embedded in SaaS applications?

A: Treat embedded AI as a machine identity problem with data access implications. Inventory the feature, map the connected permissions, define what data it may use, and monitor retention and sharing paths. If the AI feature can read corporate content, it needs explicit approval, logging, and periodic review like any other privileged integration.

Technical breakdown

Why CASB visibility breaks down in identity-driven SaaS

CASBs were built to discover cloud app usage, monitor data movement, and enforce access policies at the perimeter of cloud adoption. That model assumes the main problem is knowing which apps exist and whether traffic should be allowed. In modern SaaS estates, the more important question is which identities, tokens, and delegated permissions can act inside those apps after initial access is granted. Once access is inside the SaaS layer, visibility alone does not explain relationship risk across dozens or hundreds of connected services.

Practical implication: security teams should stop treating app discovery as the end state and map the identity relationships behind each SaaS connection.

How SSPM leaves OAuth and service account risk partially governed

SSPM improves continuous monitoring of SaaS configuration drift, but configuration is only one layer of risk. A platform can be correctly configured and still expose the organisation through over-broad OAuth scopes, unmanaged service accounts, or non-human identities that act across integrated applications. Those identities often outlive the business process that created them, which means posture checks can pass while access pathways remain dangerous. The gap is not absence of configuration hygiene, but incomplete control over who or what is authorised to use the configuration.

Practical implication: pair posture monitoring with identity lifecycle control for OAuth grants, service accounts, and connected applications.

What a SaaS Security Control Plane changes technically

A SaaS Security Control Plane is an operating model that connects applications, human identities, non-human identities, OAuth integrations, service accounts, and AI-enabled applications into one governance surface. Technically, it shifts security from point-in-time inspection to continuous relationship analysis, where risk is evaluated across the full access chain rather than per product. That matters because the security failure often emerges from the interaction between systems, not from any one app or control. In practice, SSCP is about deciding which identities can act, where they can act, and how those permissions are continuously governed.

Practical implication: design SaaS governance around cross-app identity telemetry, not isolated posture dashboards.

Threat narrative

Attacker objective: The objective is to exploit trusted SaaS identity relationships to move across connected applications, access data, and operate under legitimate-looking permissions.

1. Entry occurs through legitimate SaaS access paths such as OAuth permissions, service accounts, or connected AI-enabled applications rather than classic perimeter compromise.
2. Credential or permission access expands when over-scoped grants, delegated tokens, or reused non-human identities provide broader reach than intended.
3. Lateral movement happens across SaaS applications when those identity links let the actor move from one business system to another without triggering traditional controls.
4. Impact is realised through cross-application data exposure, unauthorised automation, or abuse of the identity chain that underpins the SaaS environment.

Breaches seen in the wild

• 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.
• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

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

SaaS security is now an identity governance problem, not a visibility problem. CASB answered which apps were in use, and SSPM answered whether those apps were configured safely. Neither model fully governs how access is delegated, reused, or extended across SaaS, which is where modern risk accumulates. The practitioner conclusion is that the primary control surface has moved to identity relationships.

Control planes matter because SaaS risk is propagated through connections, not just applications. OAuth grants, service accounts, and AI-connected workflows create a mesh of delegated authority that can outlive the original approval decision. That means one risky integration can affect multiple systems without any single system looking obviously compromised. The field needs governance models that account for relationship drift, not only configuration drift.

Identity sprawl in SaaS is the new blast-radius problem. When thousands of applications and embedded AI services share access paths, the key question becomes how far one compromised or over-scoped identity can travel. This is why SSCP thinking is gaining traction: it reframes SaaS security around containment of delegated reach rather than per-app hardening. Practitioners should measure how quickly they can identify and revoke trust chains, not just how many apps they can catalogue.

AI governance and SaaS governance are converging. AI features inside SaaS platforms do not create a separate control problem so much as they intensify an existing one by adding more identity-bearing services and more opaque decision paths. That makes continuous governance essential across human users, non-human identities, and AI-enabled workflows. The conclusion for security leaders is straightforward: AI risk in SaaS is inseparable from identity control.

Continuous identity governance is becoming the defining design principle for modern SaaS security. The strongest programmes will treat OAuth permissions, service accounts, and AI connectors as lifecycle-managed identities, not as one-off integrations. That changes the operating model for IAM, IGA, and SaaS security teams alike. The implication is that governance must follow the connection, not the console.

From our research library:

• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity sprawl is now the organizing problem for SaaS security. Security programmes that still separate app posture, OAuth governance, and non-human identity oversight will keep finding gaps after the fact, because the risk lives in the relationship graph between systems. The practical shift is toward continuous control of delegated access, business ownership, and revocation paths.

AI governance in SaaS should be treated as identity governance by another name. When embedded AI features and AI-connected services inherit permissions, they inherit risk as well. 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, according to the 2026 Infrastructure Identity Survey. That gap will widen unless teams govern the identities behind the automation.

SaaS Security Control Plane: the useful concept here is cross-app identity governance. This means the control model follows the connection, not just the application. For practitioners, that translates into measuring delegated authority, review cadence, and revocation readiness across the full SaaS estate, not just within a single vendor console.

For practitioners

• Map SaaS identity relationships Inventory OAuth grants, service accounts, AI-enabled integrations, and non-human identities across the SaaS estate, then trace which applications each one can reach.
• Separate posture from authority Use posture findings to flag misconfiguration, but require a second control that validates delegated access scope, token exposure, and cross-app reach.
• Adopt continuous revocation paths Build a process to revoke risky grants and disable stale connected identities as soon as they exceed the approved business purpose or lifecycle.
• Treat AI-enabled SaaS as governed identities Classify embedded AI features and AI-linked workflows by the identities they consume, the data they touch, and the permissions they inherit.

Key takeaways

• SaaS security risk is shifting from isolated application posture toward governance of the identities and delegated permissions that connect the environment.
• OAuth grants, service accounts, and AI-linked workflows can create major exposure even when individual applications look properly configured.
• Practitioners need continuous identity governance across SaaS connections, because the control gap now lives in relationship drift rather than in app misconfiguration alone.

Key terms

• SaaS Security Control Plane: An operating model that connects SaaS posture, identity, access, and governance into one control layer. It aims to manage how applications, OAuth grants, service accounts, and AI-connected workflows interact, rather than treating each app as a separate security problem.
• Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.
• 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.
• 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 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.