TL;DR: Public SaaS attacks rose 490% year over year, the average enterprise now operates 3,891 SaaS and AI-connected environments, and more than 23,000 SaaS applications sit outside centralized IT visibility, according to Grip Security’s 2026 SaaS + AI Security Report. The practical shift is that SSPM alone is no longer enough; identity relationships, OAuth grants, AI-enabled apps, and automation now define the real attack surface.
At a glance
What this is: Grip Security argues that SaaS security is shifting from configuration posture toward identity control, with SaaS discovery, OAuth governance, AI app visibility, and non-human identity oversight becoming core requirements.
Why it matters: IAM, DevSecOps, and NHI teams now have to govern who and what connects to SaaS, not just whether configurations are hardened, because hidden identities and grants expand real exposure.
By the numbers:
- Public SaaS attacks increased 490% year over year, according to Grip Security’s 2026 SaaS + AI Security Report.
- The average enterprise now operates 3,891 SaaS and AI-connected environments, according to Grip Security’s 2026 SaaS + AI Security Report.
Context
SaaS security now has an identity problem. When applications, OAuth grants, service accounts, AI-enabled tools, browser extensions, and automation platforms all create access paths, configuration posture alone no longer describes the real exposure surface.
The governance gap is that many programmes still treat SaaS as a static application estate. In practice, SaaS environments mutate continuously through new connections, unmanaged apps, and non-human identities that inherit or accumulate access outside normal review cycles.
Key questions
Q: What breaks when SaaS security posture is not included in cloud security monitoring?
A: When SaaS posture is left out, security teams miss misconfigurations, third-party integrations, and identity risks that create entry points for attackers. That gap can hide phishing-driven compromise, abused OAuth tokens, and other paths that let an intruder pivot from a business app into cloud workloads, repositories, or storage. The result is blind spots across the attack chain.
A: OAuth integrations and non-human identities create risk because they expand trust beyond the traditional user login. A legitimate connection can grant broad access to email, documents, messaging, or data workflows without a password compromise. The security problem is not only authentication, but the scope of delegated access and the difficulty of governing it continuously.
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 posture management no longer covers the SaaS attack surface
SaaS Security Posture Management focuses on configuration state, misconfigurations, and compliance drift. That remains useful, but it only answers whether a platform is set up correctly at a point in time. Modern SaaS risk is increasingly created by relationships: OAuth consents, third-party integrations, AI-enabled applications, browser extensions, and service accounts that connect systems outside a central approval path. The technical problem is not simply configuration, but trust inheritance across identity-bound connections. Once access is granted, the effective security boundary is defined by the grant, the token, and the downstream app behaviour, not just the original SaaS setting.
Practical implication: Treat posture data as one input, then add identity and grant inventory to see the real exposure path.
OAuth grants and non-human identities as control-plane risks
OAuth permissions turn user or service approvals into persistent inter-application trust. In SaaS ecosystems, those grants can outlive the original business need, especially when app owners, service accounts, or automation workflows are never revisited. Non-human identities such as service accounts, bots, and AI agents compound the problem because they can maintain access without the human lifecycle controls used for employees. The result is an identity control plane where privilege is distributed across tokens and integrations rather than managed through one authoritative directory. That creates review blind spots and makes stale access difficult to detect through traditional SaaS hygiene checks.
Practical implication: Inventory OAuth trust chains and non-human identities together, then tie each grant to an owner and expiration condition.
AI-enabled SaaS changes what counts as governable access
AI functionality inside SaaS applications changes both data exposure and access control. The issue is not only that AI may process sensitive data, but that AI-enabled apps often introduce new integration paths, embedded assistants, and autonomous or semi-autonomous workflows that can reach data and execute actions faster than human review cycles. That means governance must shift from whether the app is approved to whether its AI components, connected identities, and downstream permissions are visible and bounded. For security teams, the control question becomes whether AI features are discoverable, monitored, and constrained inside the same governance model as the rest of the SaaS estate.
Practical implication: Add AI application discovery and policy review to SaaS governance so embedded AI does not bypass existing access controls.
Threat narrative
Attacker objective: Exploit trusted SaaS identity relationships to reach data and actions across connected applications without needing to break the core platform.
- Entry occurs when users, business teams, or automation platforms grant SaaS access through OAuth permissions, integrations, or unmanaged applications outside central review.
- Credential or trust exposure follows when those grants, tokens, or service accounts persist after the original use case changes, creating standing access across connected SaaS systems.
- Escalation happens as third-party apps, automation workflows, and AI-enabled features inherit permissions and extend reach into additional data and actions.
- Impact is broader SaaS compromise, because attackers or unauthorized workflows can operate through trusted identity relationships rather than through a single hardened application boundary.
Breaches seen in the wild
- 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
Identity visibility is now the primary control plane for SaaS security: posture still matters, but it is no longer sufficient to describe who and what can actually act in the environment. When OAuth grants, service accounts, AI-enabled apps, and automation platforms carry the real trust relationships, the programme has to govern identities before it governs settings. Practitioners should read SaaS risk as an identity graph problem, not a configuration checklist.
Hidden SaaS trust chains create identity blast radius: the dangerous unit is no longer the individual application but the connected permission chain between users, apps, and automation. Each additional grant expands the blast radius of a single compromise or bad approval, especially when the grant has no expiration and no clear owner. The practitioner implication is to measure trust propagation, not just app count.
AI-enabled SaaS forces governance to move upstream: embedded AI changes the speed and scope of action inside SaaS, which means security teams cannot wait for periodic review cycles to discover misuse. The governance question becomes whether the AI feature itself is visible, owned, and bounded within the SaaS control model. That changes the operating assumption for DevSecOps and IAM teams alike.
Non-human identities are the missing bridge between SaaS and workload governance: service accounts, bots, and agent-like automation now sit between traditional SaaS administration and cloud workload identity. That makes lifecycle ownership, permission boundaries, and offboarding discipline a shared concern across IAM, PAM, and NHI governance. Teams that treat these identities as edge cases will keep missing where SaaS access actually persists.
Automation is becoming a governance requirement, not a convenience feature: the scale of unmanaged SaaS and the volume of identity relationships make manual remediation structurally inadequate. That does not mean automating blindly; it means automating revocation, cleanup, and enforcement only after ownership and policy rules are explicit. The field is moving toward continuous identity control, not periodic SaaS review.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
- Read next: NHI Lifecycle Management Guide
What this signals
Identity control plane for SaaS: the programme boundary is moving from application posture to the relationships that let apps, bots, and AI features act on data. Security teams that cannot inventory those relationships will keep finding risk after the fact instead of governing it up front.
The practical shift is that SaaS visibility must now include ownership, trust propagation, and non-human access paths. When those three are visible together, IAM and DevSecOps teams can stop treating SaaS as a shadow inventory problem and start treating it as an identity governance problem.
Only 44% of developers are reported to follow security best practices for secrets management, according to the State of Secrets in AppSec, which is a reminder that access hygiene and developer behaviour are still weak points even before SaaS integrations multiply the blast radius.
For practitioners
- Map SaaS identity relationships continuously Inventory users, service accounts, OAuth grants, AI-enabled apps, and automation accounts in one governance view so access paths are visible before they become incidents.
- Set expiry conditions for third-party access Require business ownership and review dates for every SaaS integration, token, and delegated permission so stale trust does not persist after the original use case ends.
- Include AI features in SaaS review workflows Check whether embedded AI functions can access regulated, confidential, or production data, then apply the same approval and monitoring standards used for other high-risk integrations.
- Automate revocation for unused grants Use policy-driven cleanup to remove dormant OAuth permissions, abandoned app connections, and orphaned non-human identities before they accumulate standing access.
- Separate posture findings from identity findings Track misconfigurations, but also report on who can authenticate, which apps can act on behalf of users, and where access is inherited through integrations.
Key takeaways
- SaaS security is no longer governed by posture alone, because identity relationships now define how access is actually created and extended across connected applications.
- OAuth grants, service accounts, and AI-enabled integrations widen the blast radius when they are not owned, reviewed, and expired on a lifecycle basis.
- The strongest control model combines SaaS discovery, identity visibility, and automated revocation so teams can reduce risk continuously rather than report on it after the fact.
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 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 delegated access create the exposure pattern discussed here. |
| NHI-05 — Overprivileged NHI | The article emphasizes excessive OAuth permissions and accumulated non-human access in SaaS. | |
| NHI-10 — Human Use of NHI | Employees and teams are using SaaS connections and automations that blur human and non-human control boundaries. | |
| Recommendation — Inventory third-party access paths and remove unused delegated grants before they become standing risk. Review non-human permissions against business need and trim any access beyond task scope. Separate human approvals from delegated machine access so identity accountability remains clear. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is unmanaged entitlements across SaaS, integrations, and AI-enabled apps. |
| GV.OV-02 — Oversight of cybersecurity risk management | The article frames SaaS identity control as a governance and oversight problem. | |
| Recommendation — Map and govern SaaS entitlements continuously instead of relying on periodic configuration checks. Assign clear oversight for SaaS identity risk and tie it to measurable control outcomes. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Excessive grants and trusted integrations enable credential-driven spread across SaaS systems. |
| Recommendation — Hunt for trusted SaaS pathways that enable credential abuse and lateral movement between apps. | ||
Key terms
- Software As A Service Security Posture Management: Software as a Service Security Posture Management is the continuous assessment and control of security settings, access, and data exposure across SaaS applications. It focuses on misconfigurations, excessive permissions, risky integrations, and weak governance. The discipline maps SaaS controls to policy, detects drift, and supports remediation before exposure becomes an incident.
- 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.
- Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.
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.
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