A CASB and AI agents meet at two edges: the employee's network path, and the SaaS tenant the CASB reads through an API. From those edges a CASB can tell you who reached which AI service, from where and when, and what the tenant logged afterwards. It cannot tell you which operation an agent ran, on which connected account, or whether the call worked. That record exists only where the call executes, which with a governed MCP endpoint is the endpoint itself.
Security asks for a report on what the AI agents are doing with company data. The CASB and the DLP tool both work as designed, and neither answers the question in that form. That is a difference in vantage point, not a defect. Most companies run 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 agent?
A CASB sees sessions and tenant events, not tool calls. CASB stands for cloud access security broker: a control point that reads traffic to cloud services, reads a sanctioned SaaS tenant through its API, or both. Microsoft documents its own CASB, Defender for Cloud Apps, in enough detail to show all three vantage points.
Discovery reads the network. Defender's cloud discovery analyzes traffic logs from firewalls and proxies against its catalog of cloud apps. Depending on the appliance, a log line gives it the app's URL and IP, the username, the origin IP and the bytes uploaded. That is enough to say who reached ChatGPT or Claude, from where, and how much data went up. The same page notes that by default it cannot discover an app missing from its catalog.
App connectors read the tenant. Defender's app connectors use each provider's APIs to collect users, admin and user activity, and the tokens issued to third-party apps. They can also remove those tokens, though support varies by app. Where it exists, an MCP server holding an OAuth grant to your CRM shows up as an app with permissions. The CASB can see it and cut it off.
Session control proxies the browser. Defender's Conditional Access app control puts browser sessions behind a reverse proxy and applies policy to interactive sign-ins. Its page says installed apps with noninteractive sign-in flows cannot be used with those access controls. A tool call that a server makes on an agent's behalf has no browser session to proxy.
What can DLP read in assistant traffic, and where does it stop?
DLP reads content that passes through something it inspects. Microsoft Purview's DLP overview describes matching on keywords, regular expressions, validation functions, nearby supporting matches and machine learning. It lists inline coverage for ChatGPT, Gemini, DeepSeek and Microsoft Copilot through Edge for Business and network integrations.
For a pasted prompt, this is the right layer. Purview's Endpoint DLP can audit or restrict a paste into a restricted service domain in a supported browser. It evaluates the pasted text itself, wherever it came from. An account list dropped into a chat window on a managed laptop is the case it was built for.
Content inspection stops in two places. It stops where the path is not inspected: an unmanaged device, a personal phone, or a client that never routes through the proxy. It stops again where the data never touches the device. A tool result carrying customer records into a model's context is an exchange between servers. The employee reads a summary, and the records never cross the link DLP watches.
Where do a CASB and AI agents cross paths?
On at most two of the three hops a tool call takes, and never on the hop that reaches your SaaS app. Following one call from a prompt to a CRM shows where each control sits next to an MCP endpoint.
- Employee to AI service. The browser or desktop app talks to ChatGPT, Claude or Cursor. This is the hop a CASB and DLP watch well: the destination, the person, the volume and, where inspected, the prompt.
- AI service to the MCP endpoint. Where this hop starts depends on the client. Claude's help center says custom connectors connect from Anthropic's cloud, not from the user's device, on every Claude client. That hop never crosses your network. A client that runs on the device, such as Cursor, does cross it, to a single hostname.
- MCP endpoint to the SaaS app. The call leaves from Elaichi's infrastructure, to the CRM itself or, for a native MCP connector, to the vendor's own MCP server. No proxy on your network sees it. The CASB meets it again later, as an activity in the tenant's log under the connected account. If several people share that connection, the tenant log cannot say whose agent made the call.
The current MCP specification gives an inspecting proxy more to read on the second hop. Its Streamable HTTP transport sends every message as an HTTP POST to one endpoint. Clients must copy the method and the tool name into Mcp-Method and Mcp-Name headers, so intermediaries can inspect a request without parsing its body. Behind TLS, a proxy reads those headers only if it decrypts the session.
In Elaichi, the header names a wrapper, because connected tools are never listed one by one, however few there are. A model looks a tool up with search_tools and calls it through execute_tool. Where a client sends the header, it reads one of those two names for every connected app. The real tool name and its arguments travel in the JSON body. Even a proxy that parses the body learns only what the model asked for. Which account the call actually reached, and whether a rule stopped it, is settled inside Elaichi. The wrapper carries no privilege of its own, and why connected tools stay unlisted explains the design.
What does a governed MCP endpoint record for each call?
Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry carries the operation and tool, the connection, the classification, whether the call was approved, its outcome and an error code. The connection recorded is the account the call actually reached, taken from the execution rather than from what the model asked for.
actor_kind is a stored field, not an inference. Its values include user, scim, api_token and ai_assistant, which marks the Elaichi Agent. A call from Claude, ChatGPT or Cursor is recorded under the person who signed in, with surface mcp and the OAuth client named. The client is written down when the call happens, not guessed later from a user agent string.
Arguments are where the endpoint deliberately sees less than DLP. The trail records the one path argument that names the object, as the target id, and nothing else about the arguments, so it will never tell you what text was in a field. What an AI agent audit log must capture covers the full record and how to query it.
Where do a CASB and a governed endpoint overlap?
On three fields: a person, a destination app and a time. Underneath those, they answer different questions from opposite ends of the same session.
| Question | CASB and DLP | Governed MCP endpoint |
|---|---|---|
| What it covers | Managed networks and devices, plus tenants it reads by API | Only what is connected to it |
| Unit of record | A session: user, service, volume | A call: operation, connection, outcome |
| Finds unsanctioned AI apps | Yes, that is its job | No, by design |
| Reads prompt text | Yes, where the path is inspected | No, never sees a user prompt |
| Names the tool and the account reached | No | Yes, per call |
| Records argument values | Yes, if visible | No, records the one path argument that names the object, as the target id, and nothing else about the arguments |
| What it can block | A destination, a session or an upload | A connector or one tool, for a role or a user |
| Sends records to your SIEM | Yes | Not on Gold: export to your own Datadog comes with the Black plan, which is launching soon |
The sharpest split is content. DLP can read the prompt. Elaichi stores no field contents, so it cannot say what was in a field. Whether somebody pasted a customer list into a chat window is a question for the CASB and DLP. Which connected account ran the delete, and whether it worked, is a question for the audit trail.
Coverage is the other split. A CASB sees every managed path, including clients nobody approved. The endpoint sees only what is connected to it. Treat the CASB as discovery and the endpoint as the record of authorized agent actions, and the two stop competing. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. Two more destinations, Splunk HEC and Microsoft Sentinel, are accepted as destinations, but Elaichi delivers events only to Datadog.
Which rules can only be enforced at the tool call?
Any rule about what an account may do, rather than what a payload contains. "This role may read opportunities but may not run a delete" is not a pattern in a body of text. DLP cannot express it, and a CASB that blocks a hostname cannot either.
In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each layer, blocks beat allows. One trap catches people: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.
Rules bind the operation, not the advertised label, because whoever edits a connector's documentation can rename a tool. A block matches either the tool's name or the operation recorded when the rule was written; an allow matches that operation only. Why blocks and allows match differently sets out the reasoning.
Frozen arguments go one step further. An admin fixes an argument's value on a tool entry, such as the account or the record type. The key disappears from the schema the model is shown, and the fixed value is merged over whatever the caller sends. Elaichi checks every rule at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file.
What can neither layer stop?
Prompt injection: an instruction hidden in content the model reads. An MCP server never sees the user's prompt, so it has nothing to judge. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. Content inspection misses it too, because the instruction arrives inside a document or a tool result, not in anything the employee typed.
What holds on the endpoint is narrower and real. It enforces role-based permissions per operation, a forbidden classification that no OAuth scope can reach, output redaction, scope limits and audit logging of each call that reaches execution. The human check belongs to the client. The MCP specification says there should always be a human in the loop who can deny a tool call. Cursor asks for approval before using MCP tools by default, and ChatGPT may ask for confirmation before a write.
Timing matters to an incident responder. A role or restriction change takes about two minutes to land. Grant revocation, member removal and suspension take effect on the next call. To cut access during an incident, suspend the person rather than editing a rule.
When is a CASB enough on its own?
If nobody has connected an AI 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 right instrument for it. A governance layer over traffic with no tool calls in it adds an 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. A manager switches on a connector that an admin console offers. At that point the action leaves the device, and the case for waiting runs out. Offboarding is usually where it bites first, which is the subject of what to revoke when a contractor leaves.
How do you run both without two versions of the truth?
Pick which system answers which question, then send both to one place. The failure mode is two partial records that disagree, and an auditor reconciling them by hand.
- Give each question one owner. Content inspection and unsanctioned apps go to the CASB and DLP. Authorized agent actions go to the control plane.
- Plan for one SIEM. In Elaichi, export to your own Datadog comes with the Black plan, which is launching soon. That export filters by log type: no filter forwards everything, and an empty list forwards nothing.
- 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. - Choose the region before you need it. Elaichi has three regions,
eu,usandapac, chosen when the organization is created. Foreuandus, the organization's data store and the execution of its org-scoped requests and tool calls stay in that jurisdiction. APAC uses best-effort placement and is not a residency guarantee. The audit trail is stored in one EU log instance for every region. - Write down the erasure gap. Deleting an organization tears down the workspace and deletes every connector credential. Three stores keep residue, and the deletion names them: the audit history, the analytics events, and the credential service's organization, environment and installed-connector configuration rows. Never call it total erasure.
For which clients each plane covers, built-in assistant connectors compared is the closer fit. The trail's controls are on the security page, the 600+ connectors are in the catalog, and team examples are in use cases. More on restrictions is filed under governance.
