The Question
When enterprise security teams first began deploying Cloud Access Security Brokers in the 2015–2018 period, the problem they were solving was well-defined: employees were adopting SaaS applications faster than security and IT could evaluate them, sensitive corporate data was flowing into cloud storage and collaboration platforms outside of security policy, and compliance teams needed visibility into cloud app usage for audit purposes.
CASB addressed all of those problems. It gave security teams visibility into SaaS application usage, DLP controls for data leaving the organization through cloud channels, and the ability to block or restrict access to unsanctioned applications. For the cloud application landscape of 2017 — where "cloud app" meant Salesforce, Box, Google Workspace, Dropbox, or ServiceNow — CASB was the correct architecture.
The cloud application landscape of 2026 looks different in ways that CASB's original design did not anticipate. Employees are sending sensitive data to AI tools — ChatGPT, Claude, Microsoft Copilot, Gemini, and dozens of vertical-specific AI platforms — in ways that bypass CASB coverage by design. The data flows are not through sanctioned SaaS applications with mature API integrations; they are through browser-based AI chat interfaces and direct API calls that CASB DLP policies were not built to inspect.
The question security teams are now confronting is whether their CASB is providing the protection they believe it is — and for which application categories that belief is still accurate.
Your CASB protects the cloud apps you configured it to watch in 2020 — the apps your employees are actually using in 2026 may not be in the policy.
Why This Matters Now
The enterprise AI adoption curve made CASB coverage gaps visible in 2024 in a way that was difficult to ignore. The specific trigger was the proliferation of ChatGPT Enterprise and similar AI tools — combined with internal surveys at multiple Fortune 500 companies showing that employees were routinely pasting customer data, source code, financial models, and legal documents into AI chat interfaces to get faster answers to work questions.
In February 2025, a major European financial services firm disclosed a regulatory finding that employees had shared client portfolio data with a third-party AI tool over an 18-month period. The firm's CASB was active and its DLP policies were current — but the AI tool in question was not in the CASB application library, the traffic was not classified, and no DLP rules were applied to it. The exposure was discovered during an internal AI governance audit, not by the security stack.
The incident reflected a structural pattern rather than an isolated failure. CASB application libraries — the databases that classify web traffic into named applications for policy application — are maintained by CASB vendors and updated on a lag. Major SaaS applications are catalogued quickly. Emerging AI tools, vertical AI platforms, and API-based AI services may take months to appear in the application library, if they are catalogued at all.
A 2025 study by Enterprise Strategy Group found that enterprises reported an average of 47 AI tools in active use by employees — and that fewer than 12 of those tools were explicitly covered by their existing CASB or SWG application policies. The remaining 35 were in a policy limbo: not blocked, not explicitly allowed, and not inspected by any data loss prevention control.
The DLP gap is compounded by the nature of AI data flows. Traditional DLP rules look for structured data patterns: Social Security numbers matching the XXX-XX-XXXX format, credit card numbers matching Luhn algorithm checks, healthcare record identifiers matching specific schemas. These rules were designed for a world where sensitive data was copied and pasted in recognizable formats. AI tool interactions frequently involve semantically sensitive information — a business strategy document, a customer conversation summary, a draft contract — that does not match any structured pattern but is genuinely sensitive. CASB DLP cannot evaluate semantic sensitivity.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report evaluated CASB capabilities specifically on AI application coverage, DLP accuracy for unstructured data, and deployment mode flexibility — the three dimensions where differentiation among platforms is sharpest today.
Netskope led the evaluation on AI application coverage, with the most comprehensive catalogue of AI tools and the most mature inline DLP policy framework for AI-bound traffic. Netskope's "application instance" controls — the ability to distinguish between personal and corporate Copilot instances, for example — received particular recognition as a capability that addresses real enterprise use cases.
Zscaler's CASB, delivered as part of the Zscaler Internet Access platform, placed strongly on deployment simplicity and inline coverage scale, with meaningful recent improvements in AI application cataloguing. Microsoft Defender for Cloud Apps earned recognition for organizations already standardized on M365, where its native API integration provides depth of coverage for Microsoft-ecosystem applications that third-party CASB platforms cannot replicate.
McAfee/Trellix and Broadcom (Symantec) CASB products placed in the Challengers tier, with strong DLP capabilities for established SaaS platforms but slower AI application coverage updates.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
Understanding CASB coverage requires understanding which deployment mode is active — because the three CASB deployment modes have fundamentally different coverage characteristics that are frequently conflated in vendor presentations.
API Mode: Deep coverage for sanctioned apps, zero coverage for anything else
API-mode CASB connects directly to cloud application APIs — Microsoft Graph API, Salesforce REST API, Box Content API — to inspect data at rest in sanctioned applications. It can scan every file in SharePoint for sensitive data, flag sharing permission misconfigurations in Google Drive, and audit Salesforce record access. It does this after the fact, through the application's own API, without requiring any network traffic interception.
API mode is powerful for the applications it covers and structurally unable to cover anything else. It has no visibility into unsanctioned applications, no ability to enforce inline controls, and no coverage for AI tools that do not have a vendor-maintained API integration. The CASB in API mode knows nothing about what employees are sending to ChatGPT.
Forward Proxy Mode: Inline coverage for managed devices on managed networks
Forward proxy CASB sits inline in the traffic path, inspecting all egress traffic from enrolled devices. It can apply DLP policies to all cloud traffic, block or restrict unsanctioned applications, and inspect AI tool sessions (subject to TLS inspection being enabled). Coverage is comprehensive — for devices with the agent installed, on networks where the proxy is active.
The limitation is the perimeter. Forward proxy requires device enrollment. Personal devices, contractor laptops, and mobile devices not enrolled in MDM are invisible to forward proxy CASB. Employees working from home networks with personal devices — a significant and growing workforce segment — are outside the coverage boundary.
Reverse Proxy Mode: Agentless for managed applications
Reverse proxy CASB provides inline inspection for specific applications without requiring a device agent, by redirecting application traffic through the CASB platform using DNS or IdP integration. It is the CASB deployment mode for BYOD scenarios and contractor workforces. The limitation is configuration overhead: each application requires explicit reverse proxy configuration, and coverage does not extend to applications that are not explicitly enrolled.
The compound coverage gap: An enterprise running API-mode CASB for M365 and Salesforce, with no forward proxy deployment, has comprehensive coverage for the two or three applications they explicitly configured — and no coverage for the 40+ AI tools, shadow IT applications, and emerging cloud services that represent the actual exposure frontier.
Questions Your Buying Team Should Be Asking
1. How current is your AI application library, and what is your update cadence for new AI tools?
The answer tells you how long your organization will be exposed to new AI tools before CASB policy can be applied to them. Ask specifically about coverage for the tools your employees are already using — ChatGPT, Claude, Gemini, GitHub Copilot, and any vertical AI platforms relevant to your industry. Request the application library directly and cross-reference it against your shadow IT discovery data.
2. Does your DLP support semantic content classification, or only pattern-matching rules?
This is the capability gap that determines whether your CASB can protect against AI tool data exposure. Pattern-matching DLP catches Social Security numbers and credit card numbers. Semantic classification can identify a document as sensitive based on its content — a competitive analysis, a customer negotiation record, an unreleased product roadmap — regardless of whether it contains a structured data pattern. Most CASB platforms are still primarily pattern-matching. The exceptions are worth knowing.
3. What percentage of our employee workforce is covered by our current CASB deployment mode, and how do you handle unmanaged devices?
Run the math on your actual coverage. If your forward proxy CASB covers managed corporate devices and your workforce includes 30% contractors, BYOD users, or employees on personal devices for some work functions, your coverage is not 100%. Understand the gap and evaluate whether reverse proxy or agentless deployment options close it.
4. How does your platform distinguish between a corporate M365 tenant and a personal Microsoft account?
Employees using personal Microsoft accounts to access OneDrive or SharePoint are routing data outside corporate governance controls. Application instance awareness — the ability to distinguish corporate and personal instances of the same application — is a critical CASB capability that not all platforms implement with equal granularity.
5. What telemetry does your CASB provide to our SIEM, and how does it integrate with our identity provider for session context?
CASB data is most valuable when correlated with identity context — knowing that the employee who uploaded a sensitive file to an unsanctioned app was a departing employee in their notice period requires linking CASB telemetry with HR data. Evaluate the integration depth with your SIEM and identity platform, not just the standalone CASB capabilities.
The Stackcurve Take
CASB remains a necessary component of a mature cloud security architecture. The argument is not that CASB is obsolete — it is that the scope of what CASB protects has not kept pace with the scope of how employees use cloud services. A security team that is relying on CASB to protect all sensitive cloud data flows is likely to have a false confidence that the actual coverage does not support.
The specific gap that matters most in 2026 is AI tool exposure. Employees are using AI tools as productivity infrastructure — they are not violating security policy out of malice, they are doing their jobs faster with the tools available to them. The security architecture needs to be able to see and govern those flows. Today, most enterprise CASB deployments cannot.
Closing the gap requires two things: a CASB vendor with a current AI application library and inline deployment mode, and organizational buy-in to accept the coverage tradeoffs of different deployment modes for different user populations. The technical solution exists. The organizational will to implement it — including the employee communications around AI tool governance — is the more common limiting factor.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers CASB platforms and AI application security in detail. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.