Notifications
Clear all
Topic starter
01/08/2026 10:46 pm
TL;DR: CASB is still treated as a bolt-on in many SASE stacks, but SaaS risk now lives in data at rest, over-shared files, over-privileged accounts, and AI sessions that touch tenant data, according to Island. The control problem is not visibility alone, it is whether findings can be remediated by the people who own the data.
NHIMG editorial — based on content published by Island: The Role of CASB in Modern SASE
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: What breaks when CASB only covers live SaaS sessions?
A: You miss the exposures that persist after the session ends, including public file links, dormant users, missing MFA, and over-privileged accounts.
Q: Why do SaaS identity controls need to include AI sessions?
A: Because AI sessions can read files, call tools, and generate outputs using the same tenant permissions as human users.
Q: What do security teams get wrong about choosing CASB-like tools?
A: Many teams focus on the breadth of features and ignore the operating model.
Practitioner guidance
- Map SaaS control ownership to resource owners Assign each high-risk SaaS finding to the person or team that can safely change the share, permission, or configuration without breaking legitimate use.
- Correlate AI session activity with tenant permissions Track prompts, uploads, tool calls, and token usage against the same identity and data classification model used for SaaS files.
- Extend posture review to data at rest Review sharing links, dormant accounts, missing MFA, and over-privileged SaaS roles through API-based inspection rather than waiting for live traffic events.
What's in the full article
Island's full post covers the operational detail this analysis intentionally leaves for the source:
- API polling cadence, tenant integration model, and how findings are generated from managed SaaS apps
- User-facing remediation flow, including one-click fixes, dismissals, and automated resolution states
- How the same policy engine is applied across SaaS data, browser activity, endpoint signals, and AI sessions
- Examples of the specific AI governance findings exposed through SaaS API monitoring
👉 Read Island's analysis of CASB in modern SASE and SaaS API protection →
CASB in SASE: are your SaaS data controls actually complete?
Explore further
01/08/2026 10:55 pm
CASB only works when it governs stored SaaS state, not just live traffic. The article is right to separate inline session enforcement from API-native inspection of tenant data, because the real exposure often sits in sharing settings, dormant accounts, and permissions that outlive the browser session. For identity teams, that means access governance must extend into the SaaS control plane, not stop at the edge. The practitioner conclusion is clear: SaaS posture is identity governance by another name.
A question worth separating out:
Q: How should IAM and security teams decide what to revoke in SaaS?
A: They should revoke only what violates policy and do it in a way that preserves approved business sharing, contractor access, and active workflows. The right test is whether the owner can confirm the exposure and fix it immediately without opening a separate ticket. That keeps governance tied to the actual resource state, not the ticketing system.
👉 Read our full editorial: CASB in modern SASE still misses the SaaS data-at-rest gap
