Can a gateway inspect local MCP servers running over STDIO?

No network control can, because no network traffic exists. A local MCP server is a process launched by the client, and the JSON-RPC messages travel over standard input and output between two processes owned by the same user. The controls that apply are endpoint controls: application allowlisting, restricting which connector binaries may be installed, endpoint detection on the spawned process, and device management policy. Treat local connectors as installed software subject to your software approval process, and treat remote connectors as network integrations subject to your gateway policy.

What is the difference between classifying the prompt and classifying the tool result?

The prompt is what the user typed and is usually small and deliberate. The tool result is what a connector returned and is usually larger, machine-selected, and unreviewed by anyone before it enters context. A user who types "summarize the open escalations" produces a two-word prompt and a context window containing dozens of customer records. Classifying only the prompt in that exchange reports a clean result while the actual disclosure passes untouched. Both checkpoints matter, and the result side is where the volume is.

Does an OAuth-scoped connector already solve access control?

It solves connection-level access, which is the coarse half. OAuth scoping determines which connectors an identity may reach and which broad capabilities it may use, and that is worth configuring carefully. What it does not evaluate is the individual call: whether these specific arguments, producing this specific result classification, are appropriate for this task at this moment. Scope is static and per-session; the risk is dynamic and per-request. The two controls compose, and treating the first as sufficient is the common configuration error.

How does indirect prompt injection reach a connector deployment?

It arrives through the tool results. Content retrieved by one connector becomes model context, and if that content contains instruction-like text written by someone outside the organization, the model may act on it when choosing its next tool call. A ticket body submitted by an external customer is attacker-writable text that a support connector will faithfully return. The defense is provenance labelling on retrieved content plus authorization on the subsequent call, which is covered in indirect prompt injection.

Does redaction break connector workflows?

Less often than teams expect, because the model rarely needs the restricted values to do the task. A summarization of open escalations works with customer identifiers tokenized. A code-assistance task works with credentials stripped. Redaction becomes disruptive when a policy is written against data classes the workflow genuinely depends on, which is a signal to reconsider whether that workflow should route through an external model at all rather than a signal to loosen the policy. Measure the redaction rate per workflow and treat outliers as design questions.

How does this compare with general AI DLP for chat interfaces?

The classification techniques carry over directly, and the surface is wider. A chat interface moves what the user typed. A connector deployment moves what the user typed plus whatever a set of automated integrations retrieved on the model's instruction, across whatever systems those connectors reach. The inventory problem grows accordingly: the question shifts from which AI tools people use to which systems each connector can read from and how much each returns per call. The broader practice is covered in AI DLP.

Claude Connectors DLP: Where Data Loss Prevention Sits for Remote MCP Servers

A Claude Connector is a Model Context Protocol server that Claude can call during a conversation, and the first thing worth establishing about any given connector is which transport it uses. That single fact decides whether data loss prevention has a place to stand.

Remote connectors speak HTTP to a server reachable over the network, typically authenticated with OAuth, and that traffic crosses a boundary an organization can put a proxy in front of. A local connector instead runs over STDIO between two processes on the same machine, usually the desktop client and a server binary launched alongside it. Nothing in that exchange touches the network, so a network enforcement point has no view of it.

I want to walk through both paths honestly, because a Claude Connectors DLP posture that ignores the split will claim coverage it does not have.

The two transports

The protocol itself is transport-agnostic, which is the source of the confusion. The same connector implementation can be packaged either way, and the security properties differ completely.

A remote connector exchange looks like an HTTP request carrying a JSON-RPC message:

method: tools/call
params.name: search_tickets
params.arguments.query: acquisition pricing Q3

That request has a destination host, an identity attached to it, and a payload. Each of those is a policy input.

A local connector exchange carries the same JSON-RPC message over a pipe between two processes under the same user account on the same laptop. There is no destination host, no network hop, and no place for an inline control to sit. Endpoint tooling and application allowlisting are the controls that apply there, and they belong to the endpoint team.

Saying this plainly costs a vendor nothing and saves an engineer a wasted quarter. Any Claude Connectors DLP claim that covers local STDIO servers is describing endpoint software, not an AI gateway.

The direction the risk actually runs

DLP conversations default to the prompt, and for connectors the more interesting movement runs the other way.

When Claude calls a connector, the tool result comes back into the conversation and becomes model context. A ticket search returns ticket bodies, a document connector returns document text, and a database connector returns rows. That content was retrieved because the model asked for it, and it now sits in a context window that will be sent to the model provider on the next turn along with everything else in the conversation.

The data movement is therefore two-sided. Content moves outward in the prompt the user typed, and again in the tool results the connector returned, and the second stream is usually larger and always less deliberate. A user who never pastes anything sensitive can still produce a conversation whose context window is full of retrieved customer records.

Classification has to run on both. Prompt-only classification is covered in prompt-level DLP, and the connector case extends it to retrieved content arriving from tool calls.

What Claude Connectors DLP has to classify

The data classes are the ones the organization's policy already names, applied at the granularity of a conversation turn rather than a document.

For a remote connector reaching a ticketing system, the classes are customer identifiers, account details and whatever support agents paste into ticket bodies, which in practice includes credentials more often than anyone wants to admit. Where a connector reaches a document store, the classes follow that store's contents: contract terms, unreleased financials, personnel records. Against a database, the classes follow the schema, and a SELECT * from a customer table is a bulk disclosure event dressed as a tool call.

The classifier runs where that content crosses the enforcement boundary: on tool-result content in the model's response, and on the assembled prompt before the next request leaves for the model endpoint. Both checkpoints matter, because content that was permitted to enter a context window is not automatically permitted to leave toward a third-party provider.

Identity, and what OAuth does and does not give you

Remote connectors typically authenticate with OAuth, which means the connector server sees a token and can scope what the caller reaches. That is real and worth having.

What it settles is whether the caller may access the connector. What it leaves open is whether this particular call, carrying this particular content, is permitted right now. A support engineer legitimately authorized to search tickets is still authorized to search tickets when a prompt injected into a previous tool result steers the model toward a broad query, because the token has no opinion about intent. This is the gap covered in the post-authentication gap for AI agents.

The enforcement point that closes it evaluates the call rather than the session: this identity, this tool, these arguments, this result classification, this destination. That evaluation has to happen outside the model's own reasoning, since a model that has read hostile content is the wrong component to consult about whether its next call is appropriate.

The record

A per-decision record for a connector deployment needs enough to reconstruct a conversation's data movement without replaying the conversation.

decision_id: d-4c19ab, recorded at 2026-08-13T09:41:02Z
identity: s.okafor@example.com
connector and tool: ticketing-remote, search_tickets
direction: tool_result, so this is content arriving rather than a prompt leaving
classifications: customer-pii, account-identifier
policy: connector-egress-v2
outcome: redact, with 4 fields removed before the content reached api.anthropic.com

The value of that record is that it was written by infrastructure the deploying organization controls, at the moment the decision was made. A vendor console reports what the vendor chose to record. Both are useful; only one of them is yours.

DeepInspect

This is exactly what DeepInspect does for the remote half of a connector deployment. DeepInspect sits inline between your users or agents and the model endpoints they call, as a stateless proxy. Tool-result content is classified where it crosses that boundary, in the response that returns it and in the next assembled request that carries it onward, and each decision is recorded against the identity that originated it. Enforcement is per request and fails closed.

The boundary is the transport. Remote MCP connectors cross a network line an enforcement layer can hold, while local STDIO connectors run between two processes on a laptop where no proxy reaches; those need endpoint controls and a policy about which connector binaries may be installed at all. An organization serious about Claude Connectors DLP should be running both programmes and should stop pretending either one covers the other.

If your connector inventory has never been sorted by transport, that sort is the first afternoon of work. Book a demo today.