MCP puts your data one tool call from the model. Act like it.
The Model Context Protocol makes it fast to connect a language model to a database, an inbox, or a payments API. Fast is the problem. Every server you add is a capability you just granted, and most teams grant it without asking what happens if the model gets it wrong.
The short version
5 things that decide this
- 01An MCP server is not a read-only helper by default. If the tool can write, delete or send, the model can call it that way too.
- 02A model with a database credential has the database's permissions, not the permissions a careful employee would use. Scope the credential, not the prompt.
- 03Per-tool permissions matter more than per-server ones. A server that both reads invoices and issues refunds should not be granted or denied as one unit.
- 04Audit logging is what turns 'the agent did something wrong' into 'the agent called refund_customer at 3:41pm with these arguments'. Without it, you are debugging blind.
- 05Treat every MCP connection the review you would give a new hire's access request, not a plugin install.
A tool call is not a suggestion
Before MCP, connecting a model to your systems meant custom glue code. That code was where someone decided what the model could touch. MCP removed that step. A server exposes a set of tools. The model sees them in its tool list and can call any of them the moment the connection is live.
That is the appeal and the exposure in one sentence. A support agent connected to your CRM through MCP is not reading customer records the way a person browsing a dashboard does. It is calling functions. A function that can update a record can update the wrong one, or act on a bad instruction buried in an email the model just summarized.
Scope the credential, not the prompt
Telling a model 'only read data, never delete it' in a system prompt is not access control. It is a request the model can misread, or that a crafted input can talk it out of. Access control lives in what the credential behind the tool is actually permitted to do.
- 01Issue a database role that can select from three tables, not the admin connection string, even if the admin connection is what a developer already has open.
- 02Split read tools from write tools into separate grants, so a server built for lookups cannot be repurposed for edits just because it shares a connection.
- 03Set row-level or field-level limits where the database supports them, so a tool built for one customer's records cannot return another's by a bad filter.
- 04Expire and rotate the credential the way you would for a departing contractor, not a service you forgot was running.
Permission by tool, not by server
A single MCP server often bundles tools with very different consequences. A billing server might expose look_up_invoice next to issue_refund. Approving 'the billing server' as one decision approves both. Most teams never notice they did.
The safer default is per-tool review. A read tool can usually run without a human in the loop. A write tool that moves money, sends a customer-facing email, or deletes a record needs explicit approval. That check can come from a person, or from a second rule the code enforces before the call runs. Trading Copilot, one of our own builds, draws this line the same way. It reads market data freely and only executes a trade after a human confirms it.
Not every connection needs this much ceremony
A server that only reads public documentation does not need row-level scoping or a refund-style approval gate. Neither does one running in a sandbox with nothing valuable behind it. Match the design effort to what the tool can actually reach, not to a uniform policy applied out of habit.
The judgment call is simple to state and easy to skip under deadline pressure. If the tool can change something a customer or your finance team would notice, it earns scoped credentials, per-tool approval and a log. If it cannot, treat it lightly and move on.
Questions this raises
01Is MCP safe to connect to company data?
MCP itself is a protocol, not a permission system, so safety depends entirely on how each server is scoped. A server given a narrow, read-only credential and logged tool calls is safe in the way any well-scoped integration is. A server handed a broad admin credential is not, regardless of the protocol connecting it.
02What is the biggest MCP security risk?
Over-broad credentials behind a tool the model can call on its own judgment. If a connection can do more than the task needs, a reasoning error or a crafted input in the data it reads can trigger an action nobody approved.
03Do I need audit logging for every MCP server?
You need it for any server whose tools write, delete, or send something a customer or your team would notice. A read-only server against public data can usually skip it. A server that can issue a refund or send an email cannot.
