# CASB vs MCP governance: what each one sees

> A CASB watches sessions and tenant events, Elaichi records one entry per tool call, and the CASB vs MCP governance overlap is narrower than it looks.

**TL;DR** A CASB and a DLP tool observe assistant traffic from outside the call: sessions, domains, volumes and whatever a sanctioned SaaS tenant reports afterwards. Elaichi writes one entry per tool-call attempt, succeeded or failed, naming the operation, the connection actually reached and the outcome. On CASB vs MCP governance the overlap is user, destination and time. That is small enough to forward both to one SIEM without running two versions of the truth.

Security asks for a report on what the AI assistants are doing with company data. You already run a CASB and a DLP tool, and both work as designed. Neither answers the question in the form it was asked. That is not a defect in either product. It is a difference in vantage point, and CASB vs MCP governance is the clearest frame for it. A CASB watches sessions and SaaS tenants from outside the call. A governed MCP control plane sits inside the call and records the act. Most companies end up with both, so the work is deciding which one is the record for which question.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps Everything below assumes an assistant that can act in your systems, not one that only chats.

## What does a CASB see when someone uses an AI assistant?

A CASB sees the session, not the action. CASB stands for cloud access security broker: a control point that observes traffic to cloud services, reads events from a sanctioned SaaS tenant through its API, or both.

From the network side it can establish that a person reached an assistant's domain, at what time, from which device, and roughly how much data moved. From the tenant side it reads the events the SaaS vendor publishes afterwards: a file shared, a role changed, an export run.

Two things get harder once the assistant acts through a server. The outbound call to the SaaS app does not leave the employee's laptop. It leaves the infrastructure that serves the tools, so the employee's network path never carries it. With one organization-wide MCP endpoint, the network view also collapses to a single hostname. An endpoint here is the one address clients call, `POST /mcp`, behind OAuth. Every tool call for every connected app rides that address, and the tool name sits in a JSON-RPC body inside the session.

That is a boundary, not a weakness. The identity that matters at the far end is the connected account, and only the system that made the call holds both the person and the account.

## What can DLP read in assistant traffic, and where does it stop?

DLP reads content while the content is in its path. Data loss prevention matches text and files against patterns, usually at a browser extension, an inspecting proxy, a mail gateway or a hook into a sanctioned tenant.

For pasted prompts that is the right layer. Somebody dropping an account list into a chat window is a content event on a device you manage, and content inspection sees it.

Content stops in two places. It stops where the path is not inspected, which covers unmanaged devices and clients that do not route through the proxy. It stops again where the data never touches the device at all. A tool result returning customer records into a model's context is a server-to-server exchange. The employee reads a summary, and the records themselves never cross the link DLP is watching.

## Why does a collapsed tool list make payload inspection harder?

Because the method name on the wire is often a wrapper rather than the operation. Elaichi serves 450+ connectors, and past a threshold of 30 tools the connected tools collapse behind two meta-tools, `search_tools` and `execute_tool`.

The threshold counts catalog operations and connected tools together. The control-plane catalog alone is dozens of operations, so one connected app is normally enough to trip it. Collapse is the normal case, not an edge case.

Inside Elaichi that indirection carries no privilege. `execute_tool` unwraps to the same name and arguments and falls through the identical gates, and the audit entry names the operation that actually ran.

## What a control plane records per tool call

Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account actually reached. The audit log is an append-only record of what happened, visible to the organization and exportable.

Recorded per call: the operation and the tool, the connection, the classification, whether it was approved, the outcome, and an error code. Argument names and counts are logged. Argument values never are.

The recorded connection comes from the execution rather than from the intent. Which of two connected Notion workspaces did the agent write to is the first question after an unexpected change, and the answer has to come from the call that ran.

`actor_kind` is a field, not an inference. Its values include `user`, `system`, `staff`, `scim`, `api_token` and `ai_assistant`. Whether an AI took the action is written at the point of action, not guessed later from a user agent string.

Failed calls produce two different error strings. The one returned to the caller is derived from the third party's response body. The one written to the audit trail is never derived from the request or the response. Audit records are org-visible, readable by the in-product assistant, and fanned out to whatever SIEM you configure, so a remote error body reaching the trail would be third-party payload leaving through the log pipe.

Audit events and application logs share one record shape, so a single query answers what happened instead of correlating two systems by eye. Each organization gets its own log tenant. The trail is eventually consistent, so a row may take a moment to appear.

## CASB vs MCP governance: where do the two overlap?

On the axes an SOC lead cares about, the two answer different questions from opposite ends of the same session:

| Dimension                        | CASB / DLP                              | Governed MCP endpoint          |
|----------------------------------|-----------------------------------------|--------------------------------|
| What it sees                     | Every session on the corporate network | Only what is connected to it |
| Resolution                       | Session (user + service + volume)       | Call (operation + connection + outcome) |
| Discovers shadow AI clients      | Yes, that is its job                    | No, by design |
| Blocks unauthorized destinations | On the wire                             | On the tool call |
| Reads prompt text                | Yes, subject to encryption              | No, never sees a user prompt |
| Records tool name and account    | No                                      | Yes, per call |
| Records argument values          | Yes, if visible                         | No, records argument names and counts, and never argument values |
| Forwards to SIEM                 | Yes                                     | Datadog implemented; Splunk HEC and Sentinel accepted |

They overlap on three fields and diverge under all of them. Both can name a person, a destination app and a time. Both can forward to your SIEM. Elaichi's export to Datadog is implemented, while Splunk HEC and Microsoft Sentinel are accepted but not yet delivering.

Resolution differs first. A CASB reports at session level: this user had a session with that service, this long, this much data. The control plane reports at call level: this operation, on this connection, with this outcome.

Content differs in the other direction. DLP can read the prompt text. Elaichi stores argument names and counts without values, so it will never tell you what was in a field. If the question is whether somebody pasted a customer list into a chat window, the CASB and DLP pair answers it. If the question is which connected account ran the delete and whether it succeeded, the audit trail answers it.

Coverage differs last. A CASB sees everything on the network, including clients nobody approved. A control plane sees only what is connected to it. Treat the CASB as discovery and the control plane as the record of authorized agent action, and the two stop competing.

## Which rules can only be enforced where operations are named?

Any rule about what an account may do, rather than what a payload contains. "This account may read opportunities but may not run a delete" is not a pattern in a body of text.

In Elaichi, restrictions target a role or a user. There is no organization target; the org default is the absence of any rule, which means allow-all. A user-targeted rule replaces role rules entirely. Within the winning layer, blocks beat allows, and an allow rule naming nothing denies everything.

Rules bind the canonical operation, not the advertised label, because a tool's name is a token the governed party can edit. Blocks match the tool name or the pinned operation, allows match the pinned operation only, which is the subject of [why blocks and allows match differently](/blog/block-matches-name-allow-matches-operation/).

Frozen parameters go further. A frozen key is stripped from the advertised schema, so the model never sees it, and the frozen value is merged over caller arguments at execution. Precedence runs entry defaults, then caller or model arguments, then frozen parameters. Enforcement happens at browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL against the same resolver, plus a final check on the fully substituted outbound URL.

## What neither layer stops

Neither layer protects against prompt injection. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. Content inspection does not catch the injected instruction either, since it arrived inside content the model read.

What holds on the endpoint is narrower and real: role-based permissions per operation, a `forbidden` classification that no OAuth scope can reach, output redaction, OAuth scope limits and full audit logging.

Timing is worth telling the incident responder before the incident. A role or restriction change takes effect within about two minutes. Grant revocation, member removal and suspension are effective on the next call, because the revocation flag is re-read from the org store on every single call.

## When the CASB is enough on its own

If nobody has connected an MCP client to a system of record, you do not need a control plane yet. Assistant use that is read, copy and paste is a content problem, and content inspection is the correct instrument for it. Adding a governance layer over traffic with no tool calls in it gives you another address to maintain and answers nothing you were asked.

The signals that the balance has shifted are specific. Somebody requests an API key for an agent. A team wires an assistant to the CRM with a personal token. An admin console offers a connector and a manager switches it on. At that point the action leaves the device, and [the argument for waiting](/blog/when-you-dont-need-an-mcp-gateway/) runs out. Offboarding is usually where it bites first, which is the subject of [what to revoke when a contractor leaves](/blog/shadow-ai-contractor-offboarding/).

## How to run both without two versions of the truth

Pick which system answers which question, then wire both into one place. The failure mode is two partial records that disagree, and an auditor who has to reconcile them by hand.

1. Assign the question to the system. Content and unsanctioned discovery go to the CASB and DLP. Authorized agent actions go to the control plane.
2. Point both at the same SIEM. Elaichi's export filters by log type: absent means forward everything, an empty list means forward nothing.
3. Give the reviewer a free Auditor seat. Auditor is read-only and not billable, and it lacks `tool:execute`, so the MCP endpoint lists no tools for that account.
4. Choose the region before you need it. The `eu` and `us` regions are hard residency for compute and storage. The `apac` region is a placement hint (best-effort). Only eu and us are hard-residency. Region also selects which regional log instance the trail lands in.
5. Write down the erasure gap. Deleting an organization tears down the workspace but has no path to purge its log tenant, and it returns that residue by name.

If the next question is which clients each plane covers, the comparison with [built-in assistant connectors](/blog/elaichi-vs-native-ai-connectors/) is the closer fit. The controls behind the audit trail sit on [the security page](/security/), the 450+ in the [connector catalog](/connectors/), and the team-by-team shape in [use cases](/use-cases/). More on restrictions and evidence is filed under [governance](/blog/category/governance/).

## FAQ

### Can a CASB tell you which AI assistant changed a record in a SaaS app?

Usually not by itself. A CASB observes sessions from the network and events reported by a sanctioned SaaS tenant. When an assistant acts through a server, the outbound call originates from that server's infrastructure rather than the employee's device, so the network vantage point loses the link between the person and the change. An MCP control plane such as Elaichi records the person, the connected account actually reached, the operation and the outcome as one audit entry per tool-call attempt.

### What does an MCP control plane log that DLP does not?

It logs the action rather than the content. Elaichi records the operation and tool, the connection used, the classification, whether the call was approved, the outcome and an error code, for every tool-call attempt including failures. Argument names and counts are logged, but argument values never are. DLP works the other way around: it inspects content in its path, such as a prompt typed into a browser, and cannot express a rule about which operation an account may run.

### Do you still need DLP if you have an MCP control plane?

Yes, for anything that is content on a device. An MCP control plane covers what is connected to it and records the calls that pass through it. It does not see somebody pasting a spreadsheet into a chat window on an unmanaged laptop, and Elaichi does not store argument values, so it will never report what text was in a field. Keep DLP and CASB for content inspection and for discovering unsanctioned clients, and use the control plane as the record of authorized agent actions.

### Does Elaichi defend against prompt injection at the tool call?

No. An MCP server never sees a user prompt, so it has no way to judge whether an instruction was injected, and Elaichi states that its agent-window write gate does not apply to the MCP endpoint. What holds on the endpoint is role-based permissions per operation, a forbidden classification reachable under no OAuth scope, output redaction, OAuth scope limits and full audit logging. Content inspection does not catch injection either, because the instruction arrives inside content the model read.

### How quickly does a restriction change take effect compared with revoking access?

In Elaichi, a role or restriction change takes effect within about two minutes, because it resolves through a 60-second cache plus edge propagation on every surface. Grant revocation, member removal and suspension are effective on the next call, since the revocation flag is re-read from the organization store on every single call. That difference matters during an incident: to cut access now, revoke the grant or suspend the member rather than editing a restriction.

## Read next

- [Elaichi vs Composio for company-wide MCP access](/blog/elaichi-vs-composio/) — Elaichi vs Composio: one organization-wide MCP endpoint with connectors Elaichi authors, against per-team endpoints over a large third-party app registry.
- [Elaichi vs native AI connectors: one plane, many clients](/blog/elaichi-vs-native-ai-connectors/) — Elaichi vs native AI connectors: what a second AI client costs in repeated authorization, provisioning, audit shapes and role models, and when native is still right.
- [Lunar MCPX alternative: count your servers first](/blog/lunar-mcpx-alternative-governed-access/) — Lunar's MCPX fronts the MCP servers you already run. If you run none, the right Lunar MCPX alternative removes the servers instead of proxying them.