TL;DR: CASB and SSPM address different parts of SaaS security, according to Grip Security, but Shadow AI and OAuth-connected non-human identities now make application discovery alone insufficient. The practical shift is toward continuous control of identities, permissions, integrations, and posture, not just sanctioned versus unsanctioned apps.
At a glance
What this is: This analysis says CASB and SSPM cover different parts of SaaS security, but neither is enough once Shadow AI, OAuth connections, and non-human identities blur application boundaries.
Why it matters: IAM and security teams need to govern identities, grants, and posture together because SaaS risk now lives inside the relationships between apps, users, tokens, and AI functions.
Context
CASB and SSPM each solve part of the SaaS security problem, but they start from different assumptions. CASB is strongest where the question is which applications are being used and how access is being governed, while SSPM is stronger where the question is what configuration, permission, and posture risks exist inside a known SaaS environment. The gap appears when the environment contains OAuth grants, embedded AI functions, and non-human identities that extend far beyond app discovery.
Shadow SaaS is no longer just an inventory problem. Once SaaS tools, integrations, and AI features can act through human and machine identities, the real governance question becomes who or what can operate through each application, what it can reach, and whether those permissions are still justified. That is why this topic sits at the intersection of SaaS security, IAM, and NHI governance.
Key questions
A: Security teams should treat OAuth grants as standing access paths that need continuous review, not one-time approval. Prioritise discovery across identity, browser, inbox, and connected apps, then apply policy-based analysis to identify excessive scopes, unusual app combinations, and dormant high-risk access. Remediation should be human-in-the-loop, so revocations match business context and avoid unnecessary disruption.
Q: When does OAuth create more risk than it reduces in SaaS environments?
A: OAuth becomes high risk when scopes are broad, tokens are long-lived, and the organization cannot see how the credential is reused across connected apps. At that point, convenience outweighs control, and a stolen token can preserve trusted access without repeated authentication.
Q: Where do CASB and SSPM fail when shadow AI is embedded inside sanctioned tools?
A: They fail when teams assume the app boundary is the security boundary. A sanctioned SaaS application can still expose risky AI behaviour through inherited permissions, integrations, or machine identities. The failure is not lack of visibility alone, but lack of identity-aware governance over what the embedded AI can do.
Q: When should organisations prioritise SaaS identity risk management over posture-only controls?
A: They should prioritise it when app adoption is decentralised, contractors or business teams can create their own access paths, or the environment contains shadow SaaS and shared credentials. In those conditions, posture-only controls reduce misconfiguration risk but leave the larger problem of unmanaged access untouched.
Technical breakdown
Why application discovery no longer tells the whole story
Traditional CASB workflows assume that identifying an application tells you something meaningful about risk. In modern SaaS environments, that is incomplete because the application may be sanctioned while the dangerous behaviour sits inside embedded AI, connected apps, or delegated OAuth access. The security problem is not just whether the app exists, but what runtime permissions and downstream relationships it has accumulated. Visibility therefore has to move from application presence to identity-bearing control points, including tokens, scopes, service accounts, and AI-driven actions.
Practical implication: Treat application discovery as the start of review, not the control objective.
How OAuth grants and non-human identities change SaaS exposure
OAuth creates persistent delegated access that can outlive the user’s immediate session. When a user authorises an app, the resulting token or grant can continue operating on behalf of that user or connected service, often without repeated interaction. That makes OAuth-connected SaaS a machine-identity problem as much as a user-access problem. Non-human identities such as integrations, automation accounts, and AI agents can inherit access paths that normal SaaS inventories do not expose, which is why posture monitoring must include identity lifecycle and consent governance.
Practical implication: Inventory OAuth grants, tokens, and service identities as first-class access objects.
Why Shadow AI turns posture into an identity governance issue
Shadow AI often appears inside approved SaaS platforms rather than as a separate banned tool. That means the control challenge shifts from blocking an application to governing the AI functionality, the identities it can use, and the data or systems it can touch. If an AI assistant can act through a user’s permissions, the security issue becomes delegated authority, not just software classification. This is where SaaS security, IAM, and NHI governance converge: the platform may be allowed, but the reachable actions may not be.
Practical implication: Evaluate AI features by the identities, permissions, and integrations they can activate.
Threat narrative
Attacker objective: Exploit trusted SaaS and AI relationships to gain persistent, low-friction access to data and workflows without triggering traditional app-discovery controls.
- Entry occurs through sanctioned SaaS adoption, embedded AI features, or OAuth-connected applications that enter the environment without full security visibility.
- Credential and permission exposure follows when grants, scopes, and persistent tokens extend access beyond the original user interaction.
- Escalation happens as integrations, service accounts, and AI agents inherit broad permissions across connected SaaS tools.
- Impact is unauthorized data reach, policy blind spots, and governance failure across otherwise approved applications.
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
Shadow SaaS has become an identity governance problem, not just a discovery problem. Application visibility still matters, but it no longer answers the decisive question of who or what can act through the application. OAuth grants, API keys, service accounts, and AI agents create a second layer of control that CASB-only thinking tends to miss. Practitioners should treat SaaS discovery as incomplete until identity context is attached.
Persistent delegated access is the real control gap behind many SaaS and AI risks. Once an application or agent receives a token, scope, or integration grant, the access path can continue long after the original user action. That creates a standing-privilege style problem inside systems many teams still think of as user-centric. The governance failure is assuming that app approval equals access containment; it does not.
Embedded AI creates a new category of shadow exposure inside sanctioned tools. The article’s most useful insight is that Shadow AI can hide inside approved SaaS rather than arriving as a separate application event. That means the security boundary moves from allow or block to continuous assessment of what the AI can do, which identities it borrows, and which systems it can reach. Practitioners should expect the control plane to shift toward identity-aware governance of AI functionality.
Continuous posture without identity lifecycle control will remain incomplete. SSPM can tell teams what is misconfigured, and CASB can show what is being used, but neither on its own resolves the lifecycle of grants, tokens, and machine identities. The named concept here is identity-linked SaaS exposure: risk that persists because the relationship between user, app, and agent remains active. Security teams should govern that relationship directly, not just the application label.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Identity Security Programme Guide
What this signals
Identity-linked SaaS exposure: the useful mental model here is that risk now persists in the relationship between app, consent, token, and agent rather than in the app name alone. Teams that still classify SaaS by sanctioned versus unsanctioned will keep missing the higher-value control point, which is delegated access.
The next programme decision is whether visibility tools are feeding lifecycle governance. If discovery does not lead to revocation, scope reduction, or offboarding of machine access, the organisation is only building a better inventory of exposure.
OAuth, embedded AI, and non-human identities are converging into the same operating problem. Practitioners should expect their SaaS control stack to be judged on how well it constrains inherited permissions, not just how well it finds new apps.
For practitioners
- Map SaaS controls to identity-bearing assets Build an inventory that connects each SaaS application to the humans, service accounts, OAuth grants, API keys, and AI agents that can act through it.
- Review OAuth grants as lifecycle objects Treat consented scopes and persistent tokens as access that must be approved, monitored, and revoked on a lifecycle basis, not left as one-time user consent.
- Classify embedded AI by reachable permissions For each sanctioned SaaS app with AI features, document what data, workflows, and downstream applications the AI can influence under inherited permissions.
- Separate discovery from governance decisions Use CASB visibility to find usage, then use SSPM and identity controls to decide whether the app, integration, or agent should remain connected.
- Create offboarding rules for machine access Revoke stale integrations, disabled service accounts, abandoned tokens, and unused AI connections when the business purpose no longer exists.
Key takeaways
- Shadow SaaS and Shadow AI now create exposure through identities and delegated access, not only through unsanctioned applications.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how weak identity context remains in many programmes.
- Teams need continuous control over grants, tokens, integrations, and embedded AI features if they want SaaS discovery to lead to real governance.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | OAuth grants and persistent tokens create delegated access paths central to the article. |
| NHI-05 — Overprivileged NHI | Embedded AI, integrations, and service accounts can accumulate more access than intended. | |
| NHI-07 — Long-Lived Secrets | Persistent tokens and stale integrations extend exposure beyond the original approval event. | |
| Recommendation — Review delegated access paths and revoke OAuth-based authentication that no longer has a clear business need. Audit SaaS-connected non-human identities for excess scopes and reduce permissions to the minimum workable set. Find long-lived tokens and replace them with short-lived, revocable access wherever possible. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about who and what is authorised to act through SaaS applications. |
| Recommendation — Continuously govern entitlements across SaaS, integrations, and AI features so access stays aligned to need. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | OAuth tokens, service accounts, and connected apps are the access paths most at risk here. |
| Recommendation — Map SaaS token abuse and identity hopping to credential access and lateral movement detections. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud service governance and delegated access are central to the CASB versus SSPM comparison. |
| Recommendation — Use the IAM domain to assess whether cloud and SaaS access paths are continuously governed. | ||
Key terms
- Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- 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.
- 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.
Deepen your knowledge
NHI Foundation Level course covers NHI governance, machine identity security, and secrets management in a practitioner-focused format, alongside the industry's only accredited NHI security programme. It is designed for teams that need to connect identity control to broader security operations and governance.
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