Your CASB vendor sent you an email this quarter introducing AI security features. Block ChatGPT. Block Gemini. Block Copilot. Detect risky AI usage. New dashboard. New policy pack. New SKU, naturally.

Look at what they actually inspect, and you will find the same SaaS visibility product shipped under a fresh AI label. The vendors who told you in 2021 that they “cover Slack” are now telling you in 2026 that they “cover ChatGPT” with the same network and proxy telemetry. Same engine. New labels. Slightly more purple in the product screenshots.

That does not make CASB useless. It makes CASB useful for what it was built to do.

On 24 January 2023, NIST released the AI Risk Management Framework 1.0, and Govern 3.2 squarely addresses third-party AI risks: you need to manage external provider risk, contract risk, dependency risk, and data handling risk. CASB and SSE help with the first category. They do not solve the second when the data leaves through a browser prompt box.

CASB sees the trip, not the passenger

CASB and SSE platforms operate at the network or proxy layer. That means they see TLS-decrypted HTTP requests if you have the right proxying and certificate setup. They can tell you a user visited chat.openai.com. They can often tell you there was a POST to an OpenAI endpoint. They can sometimes tell you response volume, session timing, user identity, and whether the destination matches a sanctioned app.

What they cannot see is the browser DOM event where your employee pasted the content.

That is the gap.

A prompt is usually typed or pasted into a browser textarea. The browser then packages that content for transmission, sometimes as ordinary HTTPS requests, sometimes incrementally, sometimes over WebSocket or server-sent event patterns, with TLS terminating at the vendor service.

By the time a CASB inspects traffic, it is dealing with encrypted bytes in transit or a decrypted blob too late in the flow to offer precise, pre-submit control at the user interface layer.

The CASB sees transport. It does not see the textarea.

!Prytive popup intercepting at the browser textarea — the layer the CASB cannot reach

That distinction matters when your problem is prompt-content control rather than app discovery.

// Show what CASB sees vs what actually happened
CASB log: 'User Jane: POST https://chat.openai.com/backend-api/conversation — 12.3 KB.' Reality: Jane pasted the customer database and asked for segmentation
CASB log: 'User Bob: GET https://copilot.microsoft.com/ — session start.' Reality: Bob spent 40 minutes asking Copilot to summarise the layoff plans

If your vendor demo ends with “we detected ChatGPT usage,” fine. That is visibility. If the pitch slides from visibility into “we inspect prompts,” ask for the exact technical path. Not the slide. Not the roadmap. The packet path.

NIST already separates vendor risk from data risk

NIST AI RMF Govern 3.2 is useful here because it forces a distinction many product pages blur on purpose. Third-party AI risk is not one thing.

One part is vendor risk. Which provider is your team using? Is the app sanctioned? Where is data going? Which contracts apply? CASB is decent at this. It can surface unsanctioned AI domains, identify usage trends, and support policy at the application level.

The other part is data risk. What exactly did your employee send? Was there source code in the prompt? Patient data. M&A terms. Litigation strategy. Customer exports.

In this channel, CASB cannot answer that question with precision, because it does not sit where the data is created and pasted.

That is why so much “CASB AI security” feels familiar. It is the old SaaS visibility story wearing a new AI badge and hoping nobody asks what happens between the keyboard and the POST request.

Why prompt inspection needs browser-layer access

If you want to classify content before it leaves for ChatGPT, Gemini, Claude, or Copilot, you need the control where the user interacts with the page. That means a browser extension or a managed browser that can access the DOM, inspect the textarea contents, and act before submit.

This is not a marketing preference. It is how web apps work.

The employee pastes data into a field. The page may autosave, chunk, stream, transform, or send that data in ways a network tool only sees after the user has already committed the action.

Browser-layer control can inspect the actual text in context, classify for PII, financial data, or confidential project names, and block or redact before the bytes leave the device.

That is the honest alternative. Pair your CASB with a browser-layer control plane.

If you want the operational side after a leak, the 72-hour AI incident response playbook covers the first moves most teams miss.

EDR and XDR miss the same layer from the other side

EDR and XDR vendors have the inverse problem. They see process execution, browser launches, command lines, child processes, memory signals, and sometimes clipboard events if you configure them aggressively. Useful signals. Wrong layer for prompt inspection.

By default, they do not see browser DOM contents either.

So you end up with two categories of tooling making adjacent claims. CASB sees the network but not the textarea. EDR sees the endpoint process but not the textarea. Meanwhile the actual risk event happens in the browser, in the few seconds before submit, where neither tool naturally lives.

That is why blanket “we cover AI” claims deserve a raised eyebrow and maybe a strong coffee.

Three questions to ask your CASB vendor

Before you buy the AI security add-on, ask these three questions and insist on technical answers.

1. Can you inspect prompt text before the user submits it?

If the answer starts with “we monitor requests to OpenAI endpoints,” the answer is no.

2. Do you access browser DOM elements such as the ChatGPT or Copilot textarea?

If the answer is “we inspect sanctioned SaaS traffic through our proxy,” the answer is still no.

3. Can you block or redact specific sensitive strings before they leave the browser?

If the answer is “we alert on app usage” or “we provide session controls,” you are buying discovery, not prompt-content control.

None of this means you should rip out CASB. It means you should stop asking it to do a job it was not built to do.

CASB remains useful for sanctioned-app policy, shadow AI discovery, and vendor exposure mapping. Those are real needs.

But if your requirement is ChatGPT prompt inspection, the browser is the control point. Not the proxy. Not the SIEM. Not the nice new AI tab with the suspiciously familiar widgets.

For policy design, the one-page AI usage policy template is a practical place to start.

Your takeaway is simple: discovery and control are different products, even when one vendor tries very hard to sell them as the same thing.

Pair your CASB with the layer it cannot see. Prytive sits in the browser, where the paste actually happens.