MCP Security for Mid-Market Data Teams

The Fast Version

MCP security means controlling which identity an AI agent uses when it calls a tool through the Model Context Protocol, what that tool can reach, and whether every call is logged. For a mid-market data team, the fix is one identity per agent, narrow scopes, a gateway in front of every MCP server, and queryable logs.

• Risk: an agent with a broad token can read or change anything that token allows, at machine speed.
• Biggest lever: least-privilege identities and scopes, not faster patching.
• Effort: an inventory of servers and tools first, then gateway policy and logging.
• When it fits: the day any agent, coding assistant or chatbot connects to internal data.

The security community has already catalogued the problem. The OWASP MCP Top 10, currently a beta release, lists ten risk categories, and the first one is token mismanagement and secret exposure. Notice what is missing from the top of that list: the model. Most of the ten are about credentials, scopes, supply chain and audit.

The protocol’s own maintainers say the same thing in plainer terms. The MCP security best practices state that token passthrough is explicitly forbidden by the authorization specification, because a server that forwards tokens it was never issued breaks audit trails and lets a stolen token turn the server into an exfiltration proxy.

So the hard part for a data team is not exotic. It is the familiar work of identity, access control and logging, applied to a new kind of caller that moves faster than any analyst and never gets tired of asking for more rows.

What Is MCP, and Why Does It Change Your Security Model?

The Model Context Protocol is an open-source standard for connecting AI applications to external systems. Its maintainers describe it as a USB-C port for AI applications: one standard plug between an assistant and your data sources, tools and workflows. An MCP client lives inside the AI application. An MCP server exposes tools, such as “query the sales table” or “create a ticket,” that the client can call.

That standardization is exactly why adoption is fast, and exactly why the security model shifts. Before MCP, each integration was a bespoke connector that someone reviewed. With MCP, a developer can attach a new server in minutes. The agent decides at runtime which tool to call, with what parameters, based on text it has read. Your old model assumed a human chose every query. That assumption is gone.

On a lakehouse, the consequence is concrete. The agent’s tool calls land on the same tables, views and volumes your analysts use. If the identity behind the call can read the whole silver layer, so can the agent, and so can anyone who manages to steer the agent.

What Breaks When Agents Start Calling Tools?

Six problems show up in almost every MCP review. They are listed in the order we usually find them, because each one makes the next harder to see.

Tokens that travel too far

Teams connect a server with a developer’s personal token or a shared service account because it works on the first try. Now every agent session runs with that person’s full reach. When a server also forwards that token downstream, the downstream system logs the wrong caller, and your audit trail points at someone who was asleep.

Scopes granted up front

The MCP guidance calls out omnibus scopes such as db:* or admin:* as a common mistake. A token with every scope turns one leak into lateral access across unrelated tools. The protocol recommends a minimal starting scope with step-up elevation when a privileged operation is first attempted.

Poisoned tools and contextual payloads

Tool descriptions and tool results are text the model reads. A malicious or compromised server can hide instructions in either, and an agent that trusts them acts on them. OWASP lists tool poisoning and prompt injection via contextual payloads as separate categories for a reason: one attacks the menu, the other attacks the meal.

Shadow MCP servers

Someone installs a community server on a laptop to speed up a report. Nobody registered it, nobody reviewed its dependencies, and it holds a live credential. This is the agent-era version of the spreadsheet on a personal drive, and it is the same governance gap we describe in our guide to shadow AI.

Local servers running with your privileges

The MCP specification warns that local servers run with the same privileges as the client, and gives an example startup command that quietly posts an SSH key to an outside address. A local server that is not sandboxed is arbitrary code execution with a friendly name.

Tool calls nobody logged

Model calls land in one system, identity events in another, and data reads in a third, each on its own clock. When something goes wrong, nobody can answer “which agent read this table, for whom, and why” without a week of log archaeology. OWASP names this directly: lack of audit and telemetry.

Which Control Answers Which MCP Risk?

The table maps the OWASP MCP Top 10 categories most relevant to a data platform onto the control that contains each one. Use it as the agenda for a design review.

How Does a Gateway Govern MCP Servers on Databricks?

A gateway gives you one choke point. Instead of trusting each server to authenticate callers, enforce limits and log properly, every agent request passes through a layer you control. On Databricks, that layer is Unity AI Gateway, which current Databricks docs also shorten to Unity Gateway.

Databricks announced general availability on 4 August 2026. The announcement describes it as governing agents, models, MCP servers, skills and tools, extending the identity, permissions, policies and observability of Unity Catalog to those assets, with proactive budgets and hard spend caps. The community announcement confirms that Smart Routing, which routes requests across models by quality, cost and availability, remains in Beta.

The gateway documentation adds the mechanics a data team cares about. AI assets are registered as Unity Catalog securable objects, so you grant and revoke access with the same privileges you use for tables and volumes. Consumption limits apply to model services and MCP services. Requests, token usage and latency are tracked in system tables. Service policies decide how each request proceeds based on its content and on who is making the call.

The Databricks MCP documentation states that Databricks-provided and registered MCP servers use Unity Catalog permissions, and that external servers can be added and shared through the MCP interface. One caution: the core gateway is GA, but MCP-specific governance was reported as Beta earlier in 2026. Check the current release notes for your cloud before you treat a specific MCP control as production-grade.

What Does Least Privilege Look Like for an MCP Tool?

Start from the task, not the server. Write down what the agent needs to do in one sentence, then grant only what that sentence requires. A support agent that looks up order status needs read access to one gold view, not the orders schema and certainly not the customer PII table behind it.

Three rules carry most of the weight. First, give each agent its own service principal, never a person’s token, so grants and logs attach to the agent. Second, point tools at curated gold views rather than raw tables, so a stray query cannot reach columns the view never exposed. Third, request minimal OAuth scopes and elevate only when a privileged tool is actually called, which is exactly the progressive model the MCP guidance recommends.

Writes deserve a separate decision. A read-only tool against a governed view is a contained risk. A tool that updates records, sends email or deletes files should sit behind human approval until you have a measured baseline of how the agent behaves. Our article on RAG guardrails covers the retrieval side of the same discipline.

How Should You Log MCP Tool Calls?

Aim for one record per tool call that answers five questions: which agent, acting for which user, called which tool, with which parameters, and touched which data. If those five fields live in one queryable place, incident response takes an hour. If they live in five systems, it takes a week.

This is where the lakehouse earns its keep. Gateway usage lands in system tables, Unity Catalog records data access and lineage, and both sit next to the rest of your security telemetry. Normalize them to a shared schema, join on identity and time, and you can replay a single agent run from prompt to tool call to table read.

Measure before you automate. In Lean Six Sigma terms, you cannot spot an abnormal agent without a baseline of normal ones. Record a few weeks of call volumes, tools used and rows read per agent, then alert on departures. That is the same statistical process control we apply to pipeline quality, pointed at a new kind of process.

For the wider risk map that MCP sits inside, our breakdown of the OWASP Top 10 for Agentic Applications ties each agent risk to a data control.

What Should You Ask Before You Sign an MCP Vendor or Build Your Own Server?

Bring these questions to a vendor demo or your own design review. Any answer of “we will sort that out later” marks the gap you will be explaining to an auditor.

1. Does each agent authenticate as its own identity, and can you show me every grant that identity holds?
2. Does the server validate that tokens were issued to it, and does it refuse to pass client tokens downstream?
3. Which scopes does the server request on first connection, and how does step-up elevation work?
4. Where are secrets stored, who can read them, and how long does each credential live?
5. How are tool descriptions reviewed and versioned, and what stops an update from changing a tool’s behaviour silently?
6. Can every MCP server sit behind our gateway, with rate limits and spend caps applied per agent?
7. Can you produce a single log of one agent run, joined to the data it read, within an hour?
8. How do we revoke one agent in one step without breaking the others?

If you would rather have those answers built than promised, our lakehouse security team designs agent identities, gateway policy and the logging that proves both, on a governed lakehouse you already run.

Frequently Asked Questions (FAQs)

What is MCP security?

It is the set of controls that govern how AI agents use the Model Context Protocol to call tools and read data. In practice that means agent identities, narrow scopes, a gateway in front of MCP servers, server vetting and complete logging of tool calls.

Is MCP itself insecure?

No. MCP is a connection standard, and its specification includes detailed security guidance, including a ban on token passthrough. The risk comes from how servers are built and connected: broad tokens, unvetted servers and missing logs.

Is there an OWASP Top 10 for MCP?

Yes. The OWASP MCP Top 10 is published on owasp.org as a beta release with ten categories, from token mismanagement and secret exposure to context injection and over-sharing. It complements the OWASP Top 10 for Agentic Applications rather than replacing it.

Do we need a gateway if we only run a few MCP servers?

A few servers is the right time to add one, because the policies are simple and the inventory is short. Retrofitting a gateway after dozens of teams have wired servers directly to data is far harder than starting with one choke point.

How does a lakehouse help with MCP security?

It puts the data agents read, the permissions that govern it and the logs that record it in one governed layer. That gives every agent a single access policy and lets you join tool calls to data reads when you investigate.