TL;DR: SSPM was built to find SaaS misconfigurations, but Grip Security says modern risk increasingly sits in identities, permissions, OAuth links, AI agents, and non-human identities instead. That makes identity visibility, not posture alone, the decisive control for SaaS governance.
At a glance
What this is: This is a Grip Security webinar analysis showing that SaaS risk has shifted from configuration posture to access-driven exposure across human and non-human identities.
Why it matters: It matters because IAM, IGA, PAM, and NHI teams need visibility into permissions and delegated access, not just application settings, to understand actual SaaS exposure.
By the numbers:
- AI-related attacks increased nearly 490% year over year, according to Grip Security's 2026 SaaS + AI Security Report.
Context
SSPM was built to answer a configuration question: is the SaaS application set up securely? That model breaks down when the primary exposure comes from who and what can access the application, especially when access is delegated through OAuth, service accounts, and AI-connected services. The primary keyword is SSPM, but the governance problem is now identity-centric SaaS exposure.
Grip Security's argument is that a securely configured application can still be a high-risk environment if dormant users, excessive OAuth grants, or overprivileged non-human identities remain active. For IAM and NHI programmes, the operational shift is from posture checks to continuous access governance across the SaaS estate.
This is not an argument to discard SSPM. It is a reminder that posture controls and identity controls answer different questions, and modern SaaS risk requires both to be true at once.
Key questions
Q: What breaks when SSPM is used as the only control for SaaS security?
A: SSPM breaks down when the main risk is not a misconfiguration but an identity with too much access. A SaaS app can be fully compliant on settings while OAuth grants, service accounts, and AI integrations still expose sensitive data. Teams need identity visibility to see effective access, not just configuration state.
Q: Why do shadow SaaS and unmanaged OAuth grants create so much risk for enterprise environments?
A: Shadow SaaS and unmanaged OAuth grants create risk because they often bypass the normal login and governance paths that security teams depend on. Users can connect applications directly, grant broad access, and leave persistent tokens in place. That combination makes it easy for attackers to move through email, files, and chat data without triggering traditional endpoint or network defenses.
Q: How can organisations tell whether SaaS access governance is actually working?
A: They should look for three signals: low numbers of orphaned accounts, consistent entitlement recertification, and rapid revocation when users change roles or leave. If access remains valid across apps after a lifecycle event, governance is not working even if dashboards look complete.
Q: Should teams treat non-human identities differently from human SaaS users?
A: Yes. Non-human identities often carry high privilege, operate continuously, and bypass human-oriented review rhythms. They should be inventoried, scoped, and offboarded with explicit lifecycle ownership because their access patterns can expand SaaS blast radius far faster than ordinary user accounts.
Technical breakdown
Why SSPM posture checks miss effective access
SSPM measures the state of an application configuration, such as MFA settings, sharing controls, logging, and compliance flags. Those checks can all pass while an environment still exposes data through delegated permissions, dormant privileged users, or inherited access across connected services. The technical gap is that posture is static and application-scoped, while exposure is relational and identity-scoped. Once access is granted through OAuth or service identities, the risk sits in the permission graph, not in the settings panel. Practical implication: security teams need identity-level access mapping, not just configuration reporting, to understand SaaS exposure.
Practical implication: pair SSPM findings with continuous visibility into effective access, delegated permissions, and identity relationships.
OAuth grants and delegated permissions create hidden SaaS risk
OAuth changes the security model by allowing applications to act on behalf of users or organizations without sharing passwords. That improves interoperability, but it also creates durable delegated access that can outlive the original business need. Excessive scopes, stale integrations, and third-party apps with broad permissions can all remain invisible if teams only look at the parent SaaS application's configuration. The real control boundary is the grant itself, including who approved it, what scope was given, and whether that access still matches the current business use case. Practical implication: govern OAuth connections as first-class identities, not as one-time app integrations.
Practical implication: review OAuth scopes and delegated permissions as lifecycle objects with ownership, expiry, and revocation.
AI agents and non-human identities expand the SaaS attack surface
AI assistants, autonomous agents, service accounts, API keys, machine identities, and browser-based AI extensions now operate as active participants in SaaS environments. They can hold privileges similar to human users, but they often sit outside traditional review and offboarding processes. That creates an identity management problem, not simply a new software category problem. If an AI-connected service or non-human identity has broad access, the exposure is not captured by configuration hygiene alone. Practical implication: extend identity discovery and access governance to every non-human actor that can authenticate into SaaS.
Practical implication: inventory every non-human actor in SaaS and govern it with the same access visibility applied to human accounts.
Threat narrative
Attacker objective: The objective is to exploit legitimate access relationships inside SaaS so sensitive data or downstream systems can be reached without breaking the application perimeter.
- Entry occurs through delegated access paths such as OAuth grants, service accounts, or AI-connected identities rather than through a misconfigured SaaS control alone.
- Credential or permission abuse follows when an identity with broader-than-needed scope can read, modify, or move data across connected SaaS services.
- Impact occurs when attackers or rogue integrations use that access to reach sensitive data, extend lateral movement across applications, or persist through stale permissions.
Breaches seen in the wild
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
- GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.
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
SSPM misses the control plane where modern SaaS risk now lives: application posture is only one layer of exposure, but identity and permission relationships decide whether data is actually reachable. A SaaS app can be compliant, logged, and MFA-protected while still exposing business data through stale grants and overprivileged identities. For practitioners, the real question is not whether the app looks secure, but whether access is still justified.
OAuth governance has become an identity lifecycle problem: delegated permissions behave like standing access unless they are reviewed, bounded, and revoked on a lifecycle basis. That makes OAuth grants closer to NHI governance than to classic application configuration management. Teams that treat OAuth as a setup task instead of an access relationship will keep missing the risk window.
Non-human identities now define the SaaS blast radius: service accounts, API keys, AI agents, and machine identities can all widen exposure faster than app settings can reveal it. This is where OWASP-NHI becomes relevant, because the failure is not simply weak configuration but unmanaged identity scope across SaaS. The implication is that SaaS security programmes must govern actors, not just applications.
Identity-centric SaaS exposure: the industry needs a sharper model for risk because the dangerous object is no longer the app alone, but the access graph around it. That graph includes human users, third parties, and autonomous or semi-autonomous systems operating through delegated credentials. Practitioners should treat identity visibility as the primary control and SSPM as a supporting one.
AI access governance is now part of SaaS security architecture: once AI-connected services can transact across enterprise applications, access review cadences built for human users become too slow and too shallow. The field is moving toward continuous identity governance because the privilege boundary is now shared across humans and non-human actors. Teams that do not extend governance into AI-linked access will undercount exposure.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs — What are Non-Human Identities
What this signals
Identity-centric SaaS exposure: the shift away from posture-only thinking means security programmes need visibility into delegated access, effective permissions, and non-human actors across every connected SaaS service. SSPM still matters, but it can no longer be the only lens on risk.
The governance problem is now lifecycle-based: access is granted through OAuth, service accounts, and AI-linked identities, then forgotten until it becomes an incident. Security teams should align review cadence, offboarding, and privilege scoping across human and non-human identities instead of managing them in separate silos.
For practitioners
- Map effective access, not just app posture Build an inventory of who and what can reach SaaS data, including human users, OAuth-connected apps, service accounts, and AI-linked identities. Use that map to identify privileged relationships that never appear in configuration-only reports.
- Treat OAuth grants as governed access objects Assign ownership, business justification, and revocation criteria to every third-party OAuth connection. Review granted scopes on a schedule and remove integrations that no longer support an active business process.
- Extend identity discovery to non-human actors Inventory service accounts, API keys, machine identities, and AI agents that authenticate into SaaS platforms. Classify them by privilege, data reach, and dependency so hidden access does not outlive the workload that created it.
- Use SSPM and identity governance together Keep SSPM for configuration drift and compliance posture, but add identity governance for permissions, delegation, and access review. The two controls answer different questions and should be operated as complementary layers.
Key takeaways
- Modern SaaS exposure is increasingly driven by identities and delegated permissions rather than by misconfigured application settings alone.
- AI agents, service accounts, and OAuth-linked services widen the blast radius because they can carry access that posture tools do not fully surface.
- Security teams need identity visibility and access governance alongside SSPM if they want to understand actual SaaS risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party SaaS integrations and AI-connected services can retain broad delegated access. |
| NHI-05 — Overprivileged NHI | The article centers on excessive permissions held by service identities and connected apps. | |
| NHI-09 — NHI Reuse | Long-lived OAuth links and reused service identities create hidden exposure across SaaS environments. | |
| Recommendation — Inventory third-party NHI grants and revoke any integration that no longer has a current business owner. Scope NHI permissions to the minimum access actually required and review effective privilege regularly. Eliminate reused machine identities and replace them with separately governed, purpose-bound access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether entitlements still match business need across SaaS applications. |
| Recommendation — Continuously review entitlements and revoke access that no longer matches the approved use case. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Delegated SaaS access can be abused to reach data and move across connected services. |
| Recommendation — Map SaaS delegated-access abuse to credential access and lateral movement to improve detection coverage. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Posture-only thinking misses security gaps when access relationships are not governed. |
| Recommendation — Use API security reviews to validate that service-to-service access is not broader than intended. | ||
Key terms
- Identity-centric SaaS security: An approach to SaaS security that treats users, service accounts, OAuth grants, and AI-connected actors as the real control surface. It combines configuration visibility with continuous entitlement governance so teams can see what each identity can actually do across applications.
- OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
- 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.
- Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org