Topic starter
15/08/2026 6:07 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Grip Security: “Best SSPM and SaaS Security Platforms for DevSecOps Teams (2026)”.
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.
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.
A: OAuth integrations and non-human identities create risk because they expand trust beyond the traditional user login.
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.
Practitioner guidance
- 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.
Bottom line: SaaS security is no longer governed by posture alone, because identity relationships now define how access is actually created and extended across connected applications.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 6:16 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SaaS security is shifting from posture to identity control