Data exfiltration through an MCP gateway does not look like an attacker dumping a database. It looks like a model reading a customer table because a tool let it, then including that data in an output that goes somewhere you did not intend. Same outcome, different shape. To defend it well, separate the new risk from the old one.
The familiar risk
The old form of data exfiltration is an over-privileged connection. If the MCP server reaches a database with a wide credential, any tool call can pull large amounts of sensitive data out of that system. This is the classic problem: too much access, too little scoping, sensitive fields returned in the clear. The defenses are familiar. Scope the connection, mask sensitive fields before they leave the system, record what was read.
None of that is specific to agents. It is the same data-handling discipline you would apply to any client with database access, and it still applies here.
The genuinely new risk
What MCP gateways add is that the client deciding what to read is a model whose behavior depends on inputs it processes during the task. Data it reads can influence what it does next, so a benign-looking task can turn into a wider read than anyone designed, and the data, once returned to the model, is now part of a context that may flow onward.
This is why trust the agent to handle data carefully is not a control. The defense cannot live inside the model or the MCP server, because those are the things being influenced. It has to live on the connection, where the data actually leaves the infrastructure, and it has to act regardless of what the agent intended.
There is a second reason the connection is the right place. Once sensitive data has been returned to the model, you have lost track of it. It can be summarized, embedded in a later tool call, written to a file the agent has access to, or surfaced in an output that lands outside your boundary. None of those steps look like exfiltration on their own. The only point where you can reliably decide whether a value leaves is before it reaches the agent at all, which is on the connection, on the way out of the database.
Defending the boundary
- Mask sensitive data inline. Redact PII, PHI, and secrets in returned results before they reach the agent, so the model never receives the raw values it could pass on.
- Scope the connection. Limit reads to the resources the task needs, so a wide pull is not even possible.
- Record every read. Command-level recording tells you exactly what data was accessed if you need to scope an incident.
- Grant access just in time. No standing connection means no idle path for data to leave through.
Where the masking has to happen
The key architectural point: masking sensitive data has to happen on the connection, between the database and the agent, not inside the MCP server that the model drives. hoop.dev is an identity-aware proxy that sits exactly there. It parses the connection at the protocol level and, with a configured DLP provider, redacts sensitive fields in returned results before they reach the client, with no copy landing somewhere new. It also scopes access just in time and records each session at the command level.
So the data an agent can exfiltrate is bounded by what the connection lets through after masking, not by what the model decides to do with a raw result set. hoop.dev governs the infrastructure actions, it does not read the model's prompt or output. See how inline masking and scoped access are set up and the wider model in hoop.dev's runtime governance writing.
FAQ
Is data exfiltration via an MCP gateway a new threat?
Partly. The over-privileged-connection part is old and well understood. What is new is that a model influenced by untrusted input decides what to read, so the read pattern is not fixed and the data can flow onward once returned.
Why mask on the connection instead of in the agent?
Because the agent and the MCP server are the components being influenced. Masking on the connection acts before the model ever sees the raw values, regardless of what the agent was told to do.
Does masking cover every connection type?
Masking runs at the protocol layer through a configured DLP provider and is supported per connection, with strong support on database connections and none on protocols like SSH or RDP. Scope and recording still apply everywhere.
The gateway is open source. Read and run it from the hoop.dev repository on GitHub to put masking and scope on the connections your MCP tools read from.
