CASB in modern SASE still misses the SaaS data-at-rest gap

At a glance

What this is: This is an analysis of why CASB remains awkward inside SASE, with the key finding that SaaS data-at-rest and AI activity need API-native visibility and user-directed remediation.

Why it matters: It matters because IAM and security teams need to govern who can access SaaS data, how AI tools use it, and whether remediation actually reaches the account or file owner before exposure becomes incident response.

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.

👉 Read Island's analysis of CASB in modern SASE and SaaS API protection

Context

CASB in SASE is fundamentally a governance problem as much as a visibility problem. Inline controls can see live traffic, but they do not fully govern SaaS data at rest, sharing settings, dormant accounts, or over-privileged access that persists after the session ends. In practice, that leaves a control gap between identity, data, and user action.

The article also surfaces an identity-adjacent AI angle: SaaS tenants increasingly host AI usage, agent sessions, and token activity that operate on the same data controls as human users. That makes SaaS policy enforcement part of the broader identity security model, especially where browser, endpoint, and API-native telemetry all need to align.

In other words, the starting position is increasingly typical, not exceptional. Many organisations still split network enforcement, SaaS posture, and user remediation into separate workflows, even though the attack surface is already unified by identity and data relationships.

Key questions

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. Those controls live in the tenant state, not the browser flow, so inline inspection alone cannot remove them. Effective CASB must inspect SaaS APIs and route remediation to the owner who can safely change the exposure.

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. If security teams treat those sessions as separate from identity governance, they miss how tokens, workspaces, and delegated actions expand the blast radius. AI activity should be governed as part of the SaaS identity surface.

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. The real test is whether the platform fits into identity lifecycle processes, supports timely policy changes, and avoids creating another layer of manual administration. A tool that is hard to run becomes a governance burden.

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.

Technical breakdown

Why CASB visibility stops at the session boundary

Traditional inline controls govern traffic in motion, but SaaS exposure frequently exists after the session ends. API-native CASB reaches tenant state directly, so it can inspect permissions, sharing links, dormant users, and configuration drift without waiting for a browser event. That matters because a document shared publicly remains exposed regardless of whether anyone is actively using it. The real architectural issue is the seam between runtime controls and stored-state governance.

Practical implication: teams need API-level SaaS posture coverage, not just session monitoring, to find risk that persists outside live traffic.

How AI sessions expand SaaS data governance risk

AI usage in SaaS introduces a second layer of exposure because prompts, uploads, tool calls, projects, and token activity all become governance signals. If an AI session can read sensitive files or write back to connected systems, then the AI workflow inherits the same identity, data, and permission problems as the underlying tenant. Monitoring token use alone is insufficient. Security teams need to correlate AI activity with the files, permissions, and users that the AI touched.

Practical implication: correlate AI sessions with tenant permissions and sensitive content classification before allowing automated or semi-automated actions.

Why remediation design matters more than finding generation

CASB programs fail when they create findings that no one can safely act on. If a security team must manually decide whether every shared file should be revoked, they will suppress low-confidence alerts and leave genuine exposure untouched. User-directed remediation shifts the response to the person with context, which is often the only practical way to clean up oversharing without breaking legitimate business sharing. That is an operating model choice, not just a UI feature.

Practical implication: route remediation to the resource owner and preserve business context, or the backlog will outgrow the response model.

Threat narrative

Attacker objective: The attacker aims to reach sensitive SaaS data and keep that access hidden inside ordinary sharing, account, or AI workflow activity.

1. Entry occurs when SaaS data is overshared, misconfigured, or accessed through an AI session that can read tenant content.
2. Escalation follows when over-privileged accounts, public links, or unmanaged tokens allow broader access than the business intended.
3. Impact is data exposure, silent policy violation, or downstream misuse of SaaS content by humans or AI systems.

NHI Mgmt Group analysis

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.

Remediation latency is the governance failure, not finding volume. If a CASB console produces alerts that cannot be safely acted on by the business owner, organisations accumulate ignored findings and preserve exposed data. This is the same operating failure seen in many identity programmes: central visibility without delegated action creates administrative drag, not control. The practitioner conclusion is to design ownership and response together from the start.

AI sessions create a new category of SaaS governance debt. Once AI assistants can read documents, call tools, and write outputs back into cloud apps, the identity boundary expands from user and account to session, token, and delegated action. That is a direct intersection with NHI governance because tokens, workspaces, and agent-like sessions now require lifecycle control, access scoping, and auditability. The practitioner conclusion is to treat AI activity as part of the SaaS identity surface, not as a separate concern.

SaaS visibility without identity correlation will keep missing the highest-risk exposures. A file share, a dormant account, and an AI tool call are only meaningful when tied back to the owning user, role, and permissions model. The article’s strongest implication is that posture management, DLP, and access governance need a shared identity graph. The practitioner conclusion is to unify findings across browser, endpoint, and SaaS APIs before deciding what to remediate.

One named concept here is the SaaS remediation gap. This is the distance between finding a risky file or configuration and getting the right person to fix it without losing business context. It is the failure mode that makes good detection look weak in practice. The practitioner conclusion is to reduce that gap with owner-aware workflows and policy-driven exceptions.

What this signals

SaaS remediation will become a governance differentiator. Organisations that can push fixes to the user or owner inside the workflow will close exposure faster than those relying on central queues and tickets. That matters because SaaS, AI sessions, and identity all intersect in the same files, permissions, and sharing links.

SaaS remediation gap: the gap between identifying an exposure and getting the right person to resolve it before business context is lost. The more your programme depends on manual triage, the more likely it is to normalise risky sharing as operational friction. Teams should expect this gap to widen as AI-driven content creation and sharing increase.

The practical signal for readers is that CASB, DLP, and IAM can no longer be managed as separate enforcement layers. If your programme cannot correlate owner, permission, and content state across browser and API telemetry, you do not really have end-to-end SaaS governance.

For practitioners

• 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. Keep exception handling explicit so business-critical sharing is not hidden inside blanket approvals.
• 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. This lets you see when an AI session is reading or moving sensitive content outside intended boundaries.
• 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. That is the only way to catch persistent exposure that never appears in a session log.
• Build a remediation path the business will actually use Use in-product remediation, clear owner notifications, and well-defined dismissal logic so users can fix overshared files without emailing security for every exception. If the path is slower than the exposure, the backlog will win.

Key takeaways

• CASB becomes useful in modern SASE only when it reaches SaaS data at rest, not just the live session.
• The bigger failure mode is remediation latency, because findings that cannot be acted on quickly become accepted risk.
• AI sessions turn SaaS governance into an identity problem, which means ownership, scoping, and auditability now matter across human and machine activity.

Key terms

• Cloud Access Security Broker: A CASB is a control layer that monitors and governs how users and services access cloud applications and data. It is strongest when used to enforce policy, detect shadow IT, and apply cloud app controls, but it still depends on accurate identity and entitlement data upstream.
• SaaS posture management: SaaS posture management is the continuous discovery, classification, and policy enforcement of cloud application risk. For AI-enabled SaaS, it extends beyond configuration checks to include data retention, model training permissions, delegated access, and automated remediation when behaviour drifts from policy.
• Data at rest: Data at rest is information stored on disks, databases, backups, or object storage when it is not actively moving through a network or application flow. Protection usually relies on encryption, access restrictions, and strong key handling so stored information is not readable if the storage layer is exposed.
• User-directed remediation: User-directed remediation is a response model where the person who owns or understands the resource receives the finding and can fix it directly. It reduces handoff friction, preserves business context, and is often more workable than forcing security teams to manually clear every exposure.

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

👉 Island's full post covers the SaaS API workflow, AI session monitoring, and remediation model in more detail

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security practitioners connect identity controls to the broader programmes that depend on them.