Every CISO is being asked the same question this year by their finance team: Do we need a separate AI security tool, or can our CASB handle this? The architecture decision sits behind the budget question, and most internal debates conflate the two.
The honest answer requires distinguishing what CASBs were built to do from what generative AI looks like in production. CASBs are a real category that does real work. They were designed when SaaS was a clean perimeter problem with known apps, known endpoints, and known data flows. Generative AI breaks all three of those assumptions, not as an edge case but as the default.
This article maps what CASBs catch, what they miss, and where the missing coverage actually lives. The goal is not to replace your CASB. It is to clarify which architectural layer each tool covers, so you can decide what your stack is missing.
WHAT YOU'LL LEARN
Before going through the gaps, here is what an AI agent actually looks like in production. The visible interaction happens at the chat interface. Most of the risk happens behind it. The diagram below traces the seven components a single agent moves through to serve one prompt, with coverage zones for what a typical CASB sees and what it does not.
Cloud Access Security Brokers earn their license. There are four capabilities they handle reliably:
Shadow AI app discovery. CASBs maintain catalogs of known SaaS applications and detect new ones as they appear in network logs. When an employee starts using a new generative AI service from their corporate device, the CASB will surface it.
Network-layer DLP. Outbound traffic to AI endpoints can be inspected for sensitive data patterns. Copy-paste of regulated data into a public chat window can be flagged, with rules tied to data classification labels.
Identity-aware access policies. Enforcing who can use which AI service, with conditional rules based on group membership, device posture, or location. Standard CASB territory.
Block-listing. Once a service is deemed unacceptable, CASBs prevent traffic to it from corporate devices. Effective for the unsanctioned tier of AI tools.
These capabilities matter, and they are not in dispute. They are also not what this article is about.
Five places where generative AI risk concentrates that fall outside CASB coverage:
The CASB sees the user logging into Salesforce. It does not see Einstein Copilot inside Salesforce, reading from objects the user technically has access to but should not be querying. Microsoft Copilot, Salesforce Einstein, Slack AI, and ChatGPT inside Notion all run inside the sanctioned SaaS app, not at the perimeter. The CASB's traffic logs show the parent app's API calls. They do not surface the AI agent's internal behavior.
The same gap widens for agents built on top of SaaS apps in workflow tools. Copilot Studio, n8n, Make, and LangChain agents may use a single user's OAuth token to read from Drive, post to Slack, and write to Salesforce on every run. The CASB sees one user authenticating once. The agent then operates for hours. Reco opens the agent and scores it. This GDrive Customer Files Agent, an n8n workflow on GPT, reads customer files from Drive and scores HIGH risk, with weak guardrails, Tools and Permissions in the red, and data exfiltration leading the impact. Its authorization is still TO REVIEW. The CASB logged a login. Reco shows the risk behind it.
Granting an AI plugin OAuth access to your Drive is one click. The consent screen asks for read-all permissions. The user clicks accept. The CASB logs the OAuth event but does not classify the scope as HIGH-risk, MEDIUM-risk, or LOW-risk. It does not understand that read-all access to the company file system means access to every contract, every customer list, and every product roadmap.
OAuth scope risk classification is its own discipline. Connected AI Apps in Reco tags HIGH-risk integrations and tracks their grant history with timestamps. CASBs do not.
Microsoft Copilot has configuration settings that govern whether it can search across organizational data. Salesforce Einstein has settings for which fields it can read. n8n agents have settings for output guardrails. These settings drift. Someone disables a guardrail to fix an urgent bug. Someone broadens an Einstein scope for a sales experiment. Weeks later, the configuration change may remain in place without anyone realizing it.
CASBs do not audit the configuration of AI features inside SaaS apps. SSPM-style posture management does. Reco's AI Posture Checks scan over 3,200 controls daily across the AI surfaces of major SaaS platforms, flagging drift before it becomes an incident.
Prompt injection. Output toxicity. Training-data residency. These happen between the SaaS app and the foundation model API, in territory the CASB cannot inspect. The CASB sees TLS-encrypted traffic to api.openai.com. It does not see the prompt or the response. The agent platform sees both, and that is where the relevant guardrails must be enforced.
GDPR Article 33. EU AI Act Article 73. NIST AI RMF. Each requires evidence about agent inventory, model usage, posture state, and incident timelines. CASB logs do not have this structure. They are built for SaaS access auditing, not AI-system accountability. When auditors ask which AI agents are operating in your environment, who owns each, and what data each agent can access, the CASB cannot answer.
How the layers map across the three categories of tools commonly found in enterprise security stacks:
Reframed: Most organizations need both. The architectural question is which layer each tool covers, not which to buy. Two patterns:
Pattern A: CASB-first organizations. You have a mature CASB deployment covering perimeter DLP and shadow IT discovery. The gap is everything inside sanctioned SaaS apps and agent runtimes. The fix is to add SSPM with AI Governance and AI Agents Security on top of your existing CASB. Your CASB stays.
Pattern B: SaaS-Security-first organizations. You have an SSPM platform that already covers SaaS configuration, identity sprawl, and OAuth integrations. The CASB has been deprioritized because most of your work happens inside the SaaS layer, where the CASB cannot reach. The fix is to extend your SSPM into AI-specific surfaces if it does not already cover them.
The right answer depends on where your stack already sits. Either way, the architecture decision is not a “CASB or AI tool.” It is “what coverage am I missing, and which layer do I need to add?”
AI security is not a feature bolted onto a CASB. It is a distinct architectural layer, addressing different risks and requiring different evidence. The real question is not "Do I need a separate AI security tool?" but rather "Where in my stack does AI risk live, and what tool can see that layer?" For most organizations, the answer is neither the perimeter nor any single tool operating in isolation.
EU AI Act, artificialintelligenceact.eu
%201.svg)
Gal is the Cofounder & CPO of Reco. Gal is a former Lieutenant Colonel in the Israeli Prime Minister's Office. He is a tech enthusiast, with a background of Security Researcher and Hacker. Gal has led teams in multiple cybersecurity areas with an expertise in the human element.
%201.svg)
.svg)