GenAI DLP vs MCP DLP: Prompts vs Agent Tool Calls

Data loss prevention built for people typing into chatbots does not see what an AI agent sends when it calls a tool. GenAI DLP inspects prompts, pastes and uploads that a human sends to a model, and the responses that come back. MCP DLP inspects something different: the arguments an agent places into Model Context Protocol (MCP) tool calls, the results those tools return, and the requests a server makes back to the client. This guide compares the two on threat model, inspection points, exfiltration paths, failure modes and controls, and ends with a decision checklist and a worked scenario. It is written for data security, AI platform and security architecture teams who already run some form of GenAI DLP and now have agents with tools.

Key takeaways

Different traffic, different sensor. GenAI DLP watches a human to model channel; MCP DLP watches a model to tool channel, where no human types the content and the destination is chosen at run time.
Arguments are the new upload. MITRE ATLAS AML.T0086 describes sensitive data being encoded into a tool's input parameters and sent as part of a seemingly legitimate action, so the place to inspect is the tools/call request, not the chat window.
Destination beats content. Most agent exfiltration seen so far left through an allowed channel, an email copy, an image URL or a DNS lookup, so destination allowlists and scoped tools stop more than pattern matching does.
The gateway only sees what is routed through it. Local stdio servers talk to the client over a process pipe, so an MCP gateway or network DLP sees nothing unless servers are forced through it.
Keep one policy, enforce it twice. Reuse the same classifiers and exact data match lists at the prompt layer and the tool layer, and add tool layer rules that only make sense there: record counts, recipients and argument fields.

The short answer

Use GenAI DLP when the risk is an employee sharing sensitive data with an AI service: pasting customer records into a public chatbot, uploading a contract, or a model returning regulated data to the wrong user. Use MCP DLP when the risk is an agent moving data between systems on its own: reading a CRM and writing the result into an email, a ticket, a web request or a file share. Most organisations running agents need both, and the second is not an extension of the first. The GenAI DLP vs Traditional DLP guide covers the prompt layer in depth; this guide starts where it stops, at the tool call.

What each control inspects

GenAI DLP sits on the path between a user and a model service: an endpoint agent, an enterprise browser, a secure web gateway with TLS inspection, or an AI gateway in front of the model API. It inspects the assembled prompt, attached files and the model response, and acts by blocking, redacting, warning or logging. The unit of inspection is a conversation turn.

MCP DLP sits on the path between an MCP client (the agent host) and MCP servers. The MCP specification (revision 2025-06-18) defines JSON-RPC messages over two standard transports, stdio and Streamable HTTP. The messages that carry data are:

tools/call requests: a tool name and an arguments object. This is outbound data the model chose to send, for example an email body, a SQL query, a URL or a file path.
Tool results: content items of type text, image, audio, resource link or embedded resource, plus optional structuredContent. This is inbound data that enters the model context and can later leave through another tool.
sampling/createMessage requests: a server asks the client's model for a completion and can include its own messages and system prompt.
elicitation/create requests: a server asks the user, through the client, for structured input. The specification states that servers MUST NOT use elicitation to request sensitive information, which makes elicitation content a policy check in its own right.
tools/list results: tool names, descriptions and schemas. These are not data loss in themselves, but a changed description or a new tool is often the first sign that a server will start sending data somewhere new.

Side-by-side comparison

Dimension	GenAI DLP	MCP DLP
Traffic	Human prompts, uploads and model responses	Tool call arguments, tool results, sampling and elicitation messages
Who creates the content	A person, usually interactively	The model, often unattended, from data it retrieved
Format	Free text and files	JSON-RPC with named fields defined by each tool's `inputSchema`
Where it can be enforced	Endpoint, browser, SWG or SSE, AI gateway	MCP client hooks, MCP gateway or proxy, the MCP server itself, network egress
Main exfiltration path	User shares data with an unapproved or untrusted AI service	Agent writes data to an attacker controlled destination through a legitimate tool
Typical trigger	Carelessness or policy ignorance	Prompt injection, a poisoned or malicious tool, or over-broad tool scope
Best signal	Content classification of the prompt or file	Destination, recipient, record count and tool name, then content
Response options	Block, redact, warn, coach the user	Deny the call, strip fields, require human approval, quarantine the server, revoke the token
Identity in the logs	The user	The user, the agent, the MCP client and the server credential, which must be linked to be useful

Threat model: where prompt DLP holds and where it breaks

GenAI DLP is built on an assumption that holds for chat: the person at the keyboard is the source of the data and the AI service is the destination. Controls ask whether this person may send this class of data to this service. That model breaks for agents in four ways.

The source is retrieved, not typed: an agent reads a CRM record, a mailbox or a repository through one tool and passes it to another. Nothing crosses the prompt channel that GenAI DLP watches, because the model and the tools exchange it inside the client.
The destination is chosen at run time: a send email tool accepts any recipient; a fetch tool accepts any URL. ATLAS AML.T0086 lists sending emails, creating or modifying documents and updating CRM records as variants of exfiltration through tool invocation.
The instruction may come from the data: OWASP LLM01 Prompt Injection covers indirect injection, where text in a retrieved record steers the model. The user who started the session never asked for the data to move. See SalesBleed, where a poisoned web to lead record made an agent place CRM fields in an image hostname, so the data left in a DNS lookup.
The tool itself may be hostile: in the postmark-mcp malicious server, version 1.0.16 added a hidden blind copy to every email it sent, using the victim's own email service credentials. The agent's output looked normal, and prompt DLP had nothing to inspect.

OWASP LLM06 Excessive Agency is the root cause in most of these cases: tools with more functions, permissions or autonomy than the task needs. DLP at the tool layer reduces the damage; scoping reduces the chance.

Inspection points for MCP traffic

There are four places to inspect tool traffic. Each sees a different slice, and the choice depends mostly on transport.

Inspection point	What it sees	Strength	Failure mode
MCP client hooks (agent host)	Every call before it is sent, including stdio servers, plus the model's reasoning context	Only place that sees local stdio traffic in clear and can show the user the arguments before sending	Depends on the client product supporting hooks; users can run a different client
MCP gateway or proxy	Streamable HTTP traffic routed through it, with identity of client and server	Central policy, one log, can enforce allowlists of servers and tools	Blind to direct connections and local stdio servers that are not wrapped
MCP server (in the tool code)	Its own arguments and the downstream API response	Knows field semantics, for example which argument is a recipient	Only for servers you build or control; a malicious server will not police itself
Network egress (SWG, firewall, DNS)	Destinations the server or agent host connects to, and content where TLS inspection applies	Catches the final hop whatever the protocol, including the BCC and DNS channels	Sees HTTP to the email API, not that a copy was added; no MCP context

The MCP specification already places expectations at the client. It says clients SHOULD show tool inputs to the user before calling the server, "to avoid malicious or accidental data exfiltration", SHOULD validate tool results before passing them to the model, and SHOULD log tool usage for audit purposes. It also says clients MUST treat tool annotations as untrusted unless they come from trusted servers, so a tool that labels itself read only cannot be trusted on that label alone. On the server side, servers MUST validate all tool inputs, implement access controls, rate limit invocations and sanitise outputs.

For architecture choices between gateway types, see Agent Gateway vs MCP Gateway and the MCP Gateway and MCP Server Governance Guide. For why transport decides visibility, see Streamable HTTP vs stdio MCP Transport.

Exfiltration paths and the control that catches each

Path	Reference	GenAI DLP sees it?	Primary control
User pastes records into an unapproved chatbot	OWASP LLM02	Yes	Prompt DLP with exact data match, AI app allowlist
Model returns another user's data in a response	ATLAS AML.T0057	Yes, on the response	Retrieval permissions, response redaction
Agent puts data in an email, ticket or document via a legitimate tool	ATLAS AML.T0086	No	Recipient and destination allowlist on tool arguments, approval above a threshold
Data encoded in a rendered image or link URL	ATLAS AML.T0077	Rarely	Block external image and link rendering; strict URL allowlist with parsing tests
Malicious or updated server adds a hidden recipient	OWASP LLM03 Supply Chain	No	Server allowlist with pinned versions, per server credentials, egress logging
Agent uploads files to a web service through a fetch or HTTP tool	ATT&CK T1567	No	Egress proxy for agent hosts, deny arbitrary URL tools
Stolen token used to drive an MCP server as a proxy	MCP security best practices, token passthrough	No	Audience bound tokens; servers accept only tokens issued for them
Server uses sampling to pull context into its own request	MCP sampling specification	No	Disable sampling or require review of sampling requests

Failure modes of MCP DLP

Pattern rules on JSON: a credit card regex finds numbers inside a JSON string, but misses data the model has summarised, reformatted or base64 encoded in an argument. Pair content rules with structural ones: argument length, field type and record count.
Inspecting arguments but not results: results are where retrieved data enters the context. If a tool returns 5,000 customer rows when the task needed one, the leak has already been staged. Cap result size at the server and flag large results.
Human approval fatigue: the specification says there SHOULD always be a human in the loop with the ability to deny tool invocations, but approval on every call trains people to click through. Reserve approval for external sends, new destinations and bulk operations. See the Human-in-the-Loop for AI Agents Guide.
Trusting tool descriptions: a server can change its tool list and send notifications/tools/list_changed. A DLP policy keyed on tool names without pinning server versions can be bypassed by renaming.
Logging without identity: a log line that says a tool sent data, without the user, agent and credential behind it, cannot support an investigation. The best practices document notes that token passthrough leaves the MCP server unable to distinguish clients, which damages the audit trail.

Controls that belong at the tool layer

Inventory servers and tools: list every MCP server in use, local and remote, with its publisher, version and the credential it holds. See How to audit MCP servers on developer laptops.
Classify tools by data direction: read only, internal write, external send. External send tools (email, chat, HTTP, file share, public repository) get the strictest policy.
Allowlist destinations in arguments: for external send tools, check recipient domains, URLs and repository names against an approved list before the call is sent.
Apply the shared content policy to arguments: the same sensitive information types, exact data match lists and secret detectors used for prompts, run on argument values and on result content.
Set volume thresholds: record count and byte size per call and per session, with approval or denial above the threshold.
Scope credentials per server: each server gets its own token with the minimum scopes; the MCP best practices warn against omnibus scopes and require that servers MUST NOT accept tokens not issued for them.
Force egress through a proxy: agent hosts and remote MCP servers reach only approved destinations. See the Agent Egress Control and Network Isolation Guide.
Turn off what you do not use: do not declare the sampling capability in clients that do not need it, and block external image and link rendering in agent front ends.

Where identity fits

An MCP server acts with whatever credential it holds, so installing one grants its author the agent's access to that system. DLP decisions at the tool layer are only as good as the identity attached to the call: which human started the session, which agent identity ran it, and which non-human credential the server used downstream. Bind those three in every log record, keep credentials out of prompts and tool arguments (see Runtime Secrets Injection for AI Agents Without Prompt Exposure), and treat a tool that suddenly sends secrets in its arguments as a credential exposure incident, not only a DLP event.

Decision guidance

Chat assistants only, no tools: GenAI DLP at the browser or AI gateway is enough. Add MCP DLP when the first connector or tool is approved.
Developer agents with local stdio servers: enforcement must live in the client or on the endpoint, because the network sees only what the server process sends out. Combine client hooks, an approved server list and endpoint egress control.
Business agents with remote servers: an MCP gateway gives the best single control point. Require all remote servers to be reached through it, and block direct connections at the egress proxy.
Agents you build: put field aware checks inside your own MCP servers (the server knows which argument is a recipient) and keep the gateway for cross-server policy.
Small organisations: start with a short approved server list, per server tokens and an egress allowlist; content inspection of arguments can follow. Large organisations should reuse the enterprise DLP classifiers at the gateway so prompt and tool decisions agree.

Worked scenario: a finance team agent

A finance team uses an assistant with three MCP servers: an ERP read tool, a document store and an email sender. Prompt DLP already blocks staff from pasting supplier bank details into public AI services. An invoice PDF from a new supplier contains hidden text telling the agent to email the full supplier master file to an external address for "verification".

Without MCP DLP: the agent calls the ERP tool, receives 3,200 supplier rows, and calls the email tool with the rows in the body. Prompt DLP sees only the user's request to "process this invoice". The data leaves through the company's own mail service.
With MCP DLP: the ERP server caps results at 50 rows for this agent; the gateway flags the email call because the recipient domain is not on the supplier allowlist and the body matches the exact data match list for bank details; the call is held for approval and the finance lead denies it. The event is logged with the user, the agent identity and the email server credential, and the invoice is quarantined as an injection attempt.

Implementing in phases

Discover (weeks 1 to 3): inventory clients, servers and transports; classify tools by data direction; record which servers are local stdio and which are remote.
Monitor (weeks 3 to 6): route remote servers through a gateway in log only mode; enable client side tool logging; run the prompt DLP policy against arguments and results to measure hit rates without blocking.
Enforce destinations (weeks 6 to 10): turn on recipient and URL allowlists for external send tools, per server credentials and egress proxy rules for agent hosts. Test with a pilot group and a set of injected test documents.
Enforce content and volume: move tuned content rules and record thresholds to block or approval mode, one tool class at a time.
Roll back safely: keep each rule switchable back to log only, and keep an emergency path to disable a server at the gateway or revoke its token without changing client configuration.

Detection and measurement

Coverage: percentage of MCP servers in the inventory whose traffic passes an inspection point (client hook or gateway).
External send control rate: share of external send tool calls checked against a destination allowlist.
Tool layer detections: argument and result DLP matches per 1,000 tool calls, split by tool class, with the false positive rate from analyst review.
Approval quality: approval requests per user per week and the denial rate; a near zero denial rate with high volume suggests fatigue.
Unapproved server attempts: connections to servers not on the allowlist, and direct connections that bypassed the gateway.
Injection test pass rate: share of seeded test documents whose exfiltration attempt was blocked or held.

Framework mapping

Framework	Reference	How it applies
NIST CSF 2.0	PR.DS-02, PR.DS-10, DE.CM-09	Protect data in transit and in use; monitor runtime environments, including agent hosts and tool traffic
NIST SP 800-53 Rev. 5	AC-4, SC-7, SI-4, AU-6	Information flow enforcement between tools, boundary protection for agent egress, monitoring and audit review of tool calls
CIS Controls v8.1	Safeguard 3.13	Deploy a data loss prevention solution, extended to agent tool traffic
ISO/IEC 27001:2022	Annex A 8.12, 8.16	Data leakage prevention and monitoring activities
MITRE ATLAS	AML.T0086, AML.T0053, AML.T0077, AML.T0057	Exfiltration via AI agent tool invocation, AI agent tool invocation, LLM response rendering, LLM data leakage
MITRE ATT&CK	T1567, T1048, T1213	Exfiltration over web service, exfiltration over alternative protocol (the DNS channel), data from information repositories
OWASP Top 10 for LLM Applications 2025	LLM01, LLM02, LLM03, LLM06	Prompt injection, sensitive information disclosure, supply chain, excessive agency

Practitioner checklist

Inventory every MCP server with publisher, version, transport and the credential it holds.
Classify tools as read only, internal write or external send, and apply the strictest policy to external send.
Route all remote MCP servers through a gateway and block direct connections at the egress proxy.
Enable client side logging and argument review for local stdio servers.
Run the same DLP classifiers on tool arguments and results that you run on prompts.
Allowlist recipients, domains and URLs for external send tools, and test the URL parser against tricky hostnames.
Cap result sizes and set per session record thresholds with human approval above them.
Give each server its own minimum scope, audience bound token and log the user, agent and credential on every call.
Disable sampling and external image rendering where they are not needed.
Test quarterly with seeded injection documents and track the block rate.

GenAI DLP vs MCP DLP: Inspecting Prompts Versus Agent Tool Calls