SaaS security is shifting from posture to identity control

At a glance

What this is: This analysis argues that modern SaaS security has moved beyond configuration checks to continuous visibility into identities, OAuth relationships, AI-enabled applications, and automated remediation.

Why it matters: For IAM, IGA, PAM, and security architecture teams, the key issue is that SaaS risk is now driven by identity sprawl and delegated access paths that traditional posture tools do not govern well.

By the numbers:

• Public SaaS attacks increased 490% year over year.
• The average enterprise now operates 3,891 SaaS and AI-connected environments.

👉 Read Grip Security’s webinar on SaaS security platforms for DevSecOps teams

Context

SaaS identity risk now sits at the intersection of applications, OAuth grants, service accounts, and embedded AI features. The primary governance gap is that many programmes still treat SaaS security as a posture problem, when the actual exposure is created by delegated access and unmanaged identity relationships. That is why SSPM is being evaluated less as a checklist and more as a control layer for identity sprawl.

The article’s core finding is that modern SaaS environments change too quickly for point-in-time review to keep up. New integrations appear without central approval, AI-enabled applications expand the data surface, and non-human identities accumulate permissions over time. For teams running IAM, IGA, or PAM, this is a familiar pattern: the control failure is not lack of visibility alone, but lack of continuous governance over who and what can act inside SaaS.

Grip Security positions the market as moving toward a SaaS Security Control Plane model, where discovery, identity visibility, OAuth governance, AI application detection, and remediation sit in one operational loop. The underlying problem is broader than SaaS misconfiguration. It is the inability of existing identity governance models to keep pace with systems that are increasingly connected by delegated trust rather than direct human login.

Key questions

Q: How should security teams implement identity governance in SaaS-heavy environments?

A: Start with a complete inventory of users, service accounts, integrations, and privileged entitlements across all major applications. Then enforce ownership, periodic review, and automatic deprovisioning when accounts become unused or unassigned. The goal is to make access changes traceable and reversible before stale privileges become a security issue.

Q: Why do SaaS security tools create identity risk for enterprises?

A: SaaS security tools often sit close to sensitive tokens, workflows, and investigation data, which makes their own admin paths and integrations part of the trust boundary. If access controls are weak or segmentation is poor, the platform can become a high-value control plane rather than a safe guardrail.

Q: What breaks when organisations rely on SSPM without identity governance?

A: They can detect misconfigurations but still leave excessive access in place. A platform may report that an app is exposed, but if OAuth grants, service accounts, or AI-connected integrations remain live, the attacker path is still open. In practice, posture visibility without access governance delays remediation instead of reducing risk.

Q: How do security teams know if SaaS identity controls are actually working?

A: Look for evidence that lower-assurance identities are fully segregated from sensitive backend paths, not just authenticated differently. A control is working when a breach at one trust tier cannot reach another tenant's data, administrative functions, or session context. If lateral reach remains possible, the control is cosmetic.

Technical breakdown

Why SaaS posture management no longer captures identity risk

Traditional SSPM focuses on configuration drift, such as insecure settings, missing controls, or policy exceptions. That works when the primary risk is a misconfigured SaaS tenant. It breaks down when the real problem is delegated identity, where access is granted through OAuth consent, service accounts, API relationships, and third-party integrations. In that model, the attack surface is not just the application state but the trust graph around it. Security teams need to understand which identities can create, extend, or inherit access across applications.

Practical implication: inventory SaaS access relationships, not just SaaS settings, so identity pathways are governed alongside configuration.

OAuth governance and non-human identities in SaaS

OAuth grants often create persistent access that survives normal user and application review cycles. Non-human identities such as bots, service accounts, and automation accounts compound the problem because they are frequently exempt from human lifecycle controls even though they can hold broad permissions. The article correctly frames this as an identity governance issue, not merely an application security issue. Once SaaS access is delegated, the security question becomes whether those grants are scoped, monitored, and revoked with the same discipline used for privileged human access.

Practical implication: apply access review, scope validation, and revocation workflows to OAuth-connected non-human identities on a recurring basis.

Why AI-enabled SaaS applications change the control model

AI-enabled SaaS tools introduce another layer of delegated trust because they may process sensitive data, trigger workflows, or interact with other applications through embedded automation. That does not make every AI feature autonomous, but it does mean the governance model must account for machine-mediated actions and data exposure. The relevant risk is not AI in the abstract. It is whether the application can expand access or move data without a corresponding identity control point that security teams can inspect and enforce.

Practical implication: require discovery of AI-enabled SaaS functions and map them to the identities and data sets they can touch.

Threat narrative

Attacker objective: The objective is to turn delegated SaaS trust into repeatable access across applications, data sets, and automation paths without triggering normal governance controls.

1. Entry occurs through unmanaged SaaS discovery gaps, where an application, integration, or OAuth grant is added outside centralized review.
2. Escalation occurs when excessive permissions, inherited trust, or non-human identities allow access to spread across connected SaaS systems.
3. Impact occurs when attackers or unauthorized workflows use that delegated trust to read data, move laterally across applications, or automate exfiltration.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

SSPM is becoming an identity control plane problem, not a configuration problem. SaaS misconfiguration remains relevant, but it is no longer the dominant failure mode in interconnected enterprise estates. Access now flows through OAuth grants, service accounts, browser extensions, and AI-connected integrations, which means the control surface is the trust relationship, not just the tenant setting. Security leaders should treat SaaS discovery and identity governance as one discipline.

OAuth scope debt is the SaaS equivalent of privilege creep. Once permissions are granted, they tend to persist long after the business justification has changed. Two-thirds of organisations containing risky OAuth permission scopes, as cited in the source report, is not a tooling problem alone. It shows that delegated access models are outliving their governance cycles, and practitioners need to rethink how recurring review applies to third-party consent.

Non-human identities are now central to SaaS exposure, not peripheral to it. Service accounts, bots, and automation accounts often sit outside the review cadence used for employees, yet they frequently hold the broadest access. That creates an identity blast radius that can exceed what human access reviews were designed to catch. The practical conclusion is that NHI governance must be built into SaaS control design, not appended after the fact.

AI-enabled SaaS applications widen the gap between discovery and control. The article’s shift toward a SaaS Security Control Plane reflects where the category is heading: discovery, identity visibility, AI assessment, and remediation are converging. That convergence matters because AI features often alter how data is accessed and moved without changing the visible application boundary. Practitioners should assume the old distinction between app security and identity security is now artificial.

Continuous remediation is becoming the governance standard, not a bonus feature. A posture-only model can report drift, but it does not reduce the operational burden created by rapidly changing SaaS estates. The market signal is clear: teams are moving toward controls that can revoke access, remove risky grants, and enforce policy continuously. Identity programmes that still depend on periodic review will keep finding issues after the damage is already distributed across SaaS systems.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, showing that governance gaps persist at the implementation layer.
• That execution gap is why the next control step is not more reporting, but tighter lifecycle enforcement across identities and secrets.

What this signals

Identity visibility is now the prerequisite for SaaS control. When organisations operate thousands of SaaS and AI-connected environments, the question is no longer whether posture can be audited, but whether access relationships can be continuously governed. That is the point at which SaaS security becomes a lifecycle problem as much as a discovery problem, and it is why identity teams need to own part of the control plane.

Oversight must extend to machine-mediated access paths. OAuth grants, service accounts, and embedded AI functions do not wait for quarterly reviews, which means governance must shift toward event-driven revocation and ownership validation. The practical signal for mature programmes is not the volume of alerts, but the speed at which stale trust is removed from connected systems.

More than 23,000 SaaS applications outside centralized IT visibility is not just shadow IT, it is shadow identity. When applications and integrations sit outside review, the organisation loses track of who can act, what they can reach, and how long that access persists. That is the operating condition under which identity blast radius expands faster than traditional SSPM can contain it.

For practitioners

• Map SaaS trust relationships, not just applications. Build an inventory that ties each SaaS app to OAuth grants, service accounts, integrations, and AI-enabled functions so governance can follow the access path.
• Extend lifecycle controls to non-human SaaS identities. Review service accounts, automation accounts, and bots on the same cadence used for privileged human access, with explicit ownership and revocation triggers.
• Set revocation rules for high-risk OAuth scopes. Define which permission scopes trigger immediate review or removal, especially when third-party apps can read mail, files, or workflow data.
• Require discovery of AI-enabled SaaS features. Classify embedded AI tools, note the data sets they can reach, and record which identities are permitted to invoke them or receive their outputs.
• Automate remediation for stale access paths. Connect detection to identity workflows so risky grants, unused integrations, and outdated permissions are revoked before they become persistent exposure.

Key takeaways

• SaaS security is now an identity governance problem because delegated access paths matter as much as application settings.
• The scale data points to structural sprawl, with 3,891 connected environments on average and more than 23,000 apps outside central visibility.
• Teams that want real risk reduction need continuous discovery, OAuth control, NHI governance, and automated revocation rather than posture-only reporting.

Key terms

• SaaS posture management: SaaS posture management is the continuous discovery, classification, and policy enforcement of cloud application risk. For AI-enabled SaaS, it extends beyond configuration checks to include data retention, model training permissions, delegated access, and automated remediation when behaviour drifts from policy.
• OAuth Governance: OAuth governance is the discipline of controlling delegated app access after consent is granted. It covers ownership, scope, review, revocation, and downstream propagation, because the real risk often emerges after the initial approval when connected systems inherit trust.
• 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.
• SaaS Security Control Plane: A SaaS Security Control Plane is an operating model that combines discovery, identity visibility, governance, and remediation across SaaS environments. It treats configuration, access, and automation as one control problem rather than separate security tasks.

What's in the full article

Grip Security's full webinar covers the operational detail this post intentionally leaves for the source:

• Evaluation criteria for SSPM and SaaS security platforms across visibility, governance, automation, and AI risk.
• Capability comparisons for identity visibility, OAuth governance, and automated remediation across platform types.
• Practical questions for DevSecOps teams assessing SaaS discovery, unmanaged applications, and connected identity paths.
• The webinar framing for when SSPM becomes a broader SaaS Security Control Plane model.

👉 The full Grip Security webinar covers evaluation criteria, capability comparisons, and the SaaS Security Control Plane model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.