AI Gateway vs CASB/SSE for Controlling Shadow AI: Coverage, Bypass Routes and a Combined Design

Shadow AI moves through two different pipes, and most organisations try to control both with one tool: people using AI in a browser, and code calling model APIs with keys nobody approved. A cloud access security broker (CASB), usually delivered today as part of a security service edge (SSE) platform, sees the first pipe; an AI gateway sees the second, but only for traffic sent to it. This guide compares the two for controlling unsanctioned AI use: what each covers, how deeply each can inspect, the bypass routes that defeat each (personal devices, embedded AI features, direct API keys), how much identity context each holds, and how they fail. It ends with a combined design, decision criteria and a worked scenario. It is written for security architects, SSE owners and AI platform teams who need a defensible answer to "how do we control AI use?"

Key takeaways

• They cover different traffic. A CASB or SSE platform governs users reaching AI websites and SaaS apps from managed devices and networks; an AI gateway governs sanctioned applications and agents calling model APIs. Neither sees the other's traffic well.
• Inspection depth depends on decryption and app knowledge. The NCSC notes that without intercepting encrypted connections a CASB cannot see personal accounts in approved services or what users do in them. An AI gateway sees full prompts, but only for calls routed to it.
• Bypass is the main design problem. Personal devices, AI built into sanctioned SaaS, browser extensions and direct provider keys all route around one or both controls.
• Identity context differs. The CASB knows the human user and device; the AI gateway knows the application, team or agent key. Shadow AI decisions usually need both.
• Blocking alone pushes use underground. Pair controls with a fast route to an approved AI service, as the NCSC shadow IT guidance advises.

The short answer

If the shadow AI you worry about is staff pasting data into public chat tools, start with the CASB or SSE platform: discovery from proxy and firewall logs, an AI app category, instance controls that allow corporate tenants and block personal ones, and inline DLP on uploads and prompts. If it is developers and agents calling model APIs with personal or unapproved keys, start with an AI gateway plus egress controls that make it the only route to model providers. Most organisations have both problems, so the end state is both controls with a shared policy and a shared AI inventory. See the CASB Guide for CASB fundamentals and the AI Gateway and LLM Gateway Guide for the gateway pattern; this page covers only how they divide shadow AI between them.

CASB/SSE and AI gateway side by side

Coverage: browser use versus sanctioned API traffic

CASB/SSE threat model: an employee uses a consumer AI tool with corporate data, signs in with a corporate account and grants the tool OAuth access to mail or files, or installs an AI extension. The CASB's architecture in words: endpoint or network traffic is steered to a cloud proxy, the destination is classified against an app catalogue (most catalogues now carry a generative AI category with risk attributes), and policy decides whether to allow, coach, restrict or block. API-mode connectors to sanctioned SaaS add posture and OAuth app visibility after the fact.

AI gateway threat model: a product team ships a feature calling a model provider with a key from a personal account, an agent switches to an unapproved model, or a pipeline sends customer records in prompts. The gateway's architecture in words: applications authenticate with a gateway-issued key, the gateway checks the requested model against an allow list, applies data policy and budgets, attaches the provider credential and logs the exchange. Its coverage is exactly the set of callers configured to use it.

The coverage gap is symmetrical. A CASB rarely sees a container in a cloud VPC calling a provider API, and an AI gateway never sees a browser session. Map your AI traffic before choosing: list the AI web apps in discovery logs, and list the provider API hostnames reached by servers, CI runners and agent hosts in DNS or egress logs.

Inspection depth

• CASB inline: with TLS inspection, the proxy can read uploads and form posts and apply DLP patterns, and some platforms parse prompts for specific AI apps and capture prompt content in encrypted payload logs. Without decryption it sees the hostname only. Certificate-pinned desktop and mobile apps often have to be exempted from inspection, and every exemption is a blind spot. See M1020 SSL/TLS Inspection.
• CASB API mode: reads data at rest and OAuth grants inside sanctioned SaaS, including AI features turned on inside those apps, but acts after the event.
• AI gateway: sees the full message structure, model, token counts and response for every routed call, and can redact before forwarding. It has no view of anything a user types into a website.

Failure mode shared by both: pattern-based DLP misses paraphrased or summarised sensitive content, and full prompt capture creates a new sensitive data store. See the Generative AI Data Loss Prevention Guide and GenAI DLP vs Traditional DLP.

Bypass routes and what closes them

The OAuth route deserves emphasis because neither control sees it after consent. In the Vercel Context.ai OAuth Breach 2026, an employee signed up to a consumer AI app with a corporate account and granted broad access; when the AI vendor was breached, the stolen token was used to take over the account (ATT&CK T1528 Steal Application Access Token, T1550.001 Application Access Token). The control that would have helped was consent governance in the identity platform, not a proxy rule.

Identity context

The CASB evaluates a human: user and group from the identity provider, device compliance and location, which suits rules such as "finance users on managed devices may use the corporate AI tenant with DLP; everyone else is coached". It does not know which application or agent made a server-side call. The AI gateway evaluates a non-human caller: the key identifies an application, team or agent, and a user identity exists only if the application forwards one. For shadow AI this means:

• Human use decisions (who may use which AI app with which data) belong in the CASB, aligned with zero trust principles in NIST SP 800-207 that grant access per session from user and device context rather than network location.
• Workload decisions (which service may call which model with what budget) belong in the AI gateway, with one key per workload and an owner. See the API Keys vs OAuth Tokens Guide.
• Agents acting for users need both: the gateway key identifies the agent, and the forwarded user identity lets you apply the user's data entitlements. See the Shadow AI Discovery Guide.

Failure modes of each

CASB/SSE:

• Category-only blocking: blocking the generative AI category while sanctioned SaaS gains AI features under its existing domain.
• Catalogue lag: new AI tools appear faster than catalogues classify them, so unknown or uncategorised destinations need a default policy.
• Remote and unmanaged gaps: clients disabled, split tunnels sending AI domains direct, or contractors on unmanaged devices.
• Block without alternative: the NCSC warns that unnecessary lockdowns push staff to workarounds, which here means personal phones.

AI gateway:

• Optional gateway: egress to provider APIs left open, so teams call providers directly.
• Shadow gateways: teams run their own open-source gateway with their own keys, recreating the problem.
• Key sprawl: shared gateway keys without owners, so usage cannot be traced to a team. See AI Gateway vs API Gateway.
• Treated as discovery: gateway dashboards report only sanctioned traffic and give a false sense of full visibility.

A combined design

1. Discover first (weeks 1 to 4): run CASB discovery on proxy, firewall and DNS logs for AI apps; pull DNS and egress logs from server and CI networks for provider API hostnames; pull OAuth grants to AI apps from the identity provider. Record each in the AI inventory. See the AI Usage Monitoring Guide.
2. Offer the sanctioned route: publish an approved AI tool for staff (corporate tenant) and an AI gateway endpoint for developers before blocking anything.
3. Coach before block (pilot ring): apply CASB coaching pages for unsanctioned AI apps in one business unit; allow the corporate tenant with DLP; set personal tenants of sanctioned services to read-only or block. Roll back by switching policies to monitor mode.
4. Route API traffic: move workloads to gateway keys, then add egress rules blocking provider hostnames from everything except the gateway, in audit mode first so you can see what would break.
5. Govern grants and features: restrict user consent to unverified apps, review AI OAuth grants, and set AI feature toggles inside sanctioned SaaS tenants.
6. Share policy and evidence: one data classification drives CASB DLP and gateway redaction; both send logs to the SIEM keyed to the same inventory IDs.

Size matters. A small organisation with no SSE platform can get much of the browser-side value from managed browser policies, DNS filtering of AI categories and identity-provider consent controls, and can run a single gateway for developers. A large enterprise usually extends an existing SSE deployment and runs federated gateways with a common policy baseline.

Worked scenario

A law firm finds through CASB discovery that staff use eleven AI web tools, two of them heavily, and that a document automation team calls a model provider directly from a cloud function using a partner's personal API key.

• Browser side: the firm licenses a corporate tenant of the most used tool, allows it with DLP rules for client matter numbers, sets personal accounts on that service to block, and shows a coaching page with a link to the approved tool for the other ten.
• API side: the cloud function moves to an AI gateway key with an allow list of one approved model in an approved region and a monthly budget; the personal key is revoked; provider hostnames are blocked from the function's subnet except through the gateway.
• Gaps left: partners using AI on personal phones. The firm requires managed devices for client document access through conditional access and makes the approved tool available on mobile, rather than trying to inspect personal devices.

Detection and measurement

• Log: CASB events for AI app access, instance (corporate versus personal), DLP matches and coaching outcomes; gateway events for caller key, model, tokens and policy verdicts; DNS and egress events for provider API hostnames outside the gateway; OAuth consent events for AI apps.
• Metric 1: unsanctioned AI apps with active users per month, and trend after the sanctioned tool launches.
• Metric 2: share of AI web traffic going to corporate instances rather than personal ones.
• Metric 3: share of model API traffic (by tokens) passing through the gateway; direct provider calls from servers should trend to zero.
• Metric 4: OAuth grants to AI apps with an owner and a review date.
• Metric 5: number of AI domains in inspection bypass lists.

See the Shadow AI Health Check and CASB and SSE platform health check for scored reviews.

Framework mapping

Practitioner checklist

• Map AI traffic in both pipes: AI web apps from proxy and DNS logs, provider API hostnames from server and CI egress.
• Publish an approved AI tool and an AI gateway endpoint before you block anything.
• Enable instance or tenant controls so corporate AI tenants are allowed and personal ones are restricted.
• Apply DLP consistently in CASB inline policy and gateway redaction from one classification scheme.
• Block direct egress to provider APIs except from the gateway, starting in audit mode.
• Restrict user consent to unverified apps and review AI OAuth grants on a schedule.
• Set AI feature toggles in each sanctioned SaaS tenant and check them through CASB API mode.
• Review inspection bypass lists for AI domains every quarter.
• Report the five metrics above monthly against one AI inventory.

Standards and references

• NCSC: Shadow IT
• NIST: SP 800-207 Zero Trust Architecture
• OWASP: LLM02:2025 Sensitive Information Disclosure
• OWASP: LLM10:2025 Unbounded Consumption
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• MITRE ATT&CK: T1528 Steal Application Access Token

Related NHI Mgmt Group resources: Top 10 Shadow AI Risks · Shadow AI Policy Template · AI Usage Control and Shadow AI · Shadow AI Statistics · Secure Web Gateway and Web Filtering Guide