Why MCP security is different
An MCP server hands an autonomous agent the ability to call real tools against real data. That is exactly what makes it useful, and exactly why it needs careful security. Unlike a human clicking through a UI, an agent can act quickly, in bulk, and in ways you did not explicitly anticipate — so your safeguards have to be structural, not just guidelines.
The good news is that MCP maps cleanly onto well-understood security principles: authenticate every caller, grant the least privilege necessary, isolate tenants, gate dangerous actions, and log everything. The rest of this guide walks through how each applies to a business MCP server, using how BusinessMCP is built as the reference model.
Treat keys as the perimeter
Your Bearer key is the primary boundary between an agent and your data. BusinessMCP uses workspace-scoped keys prefixed mcph_; anyone holding one can act within that workspace, so key hygiene is non-negotiable. Store keys in a secrets manager, never in source control, and never in client-side code where a browser can leak them.
Issue one key per consumer — per agent, per machine, per integration — so revocation is surgical. If a laptop is lost or an integration is deprecated, you kill that single key and nothing else breaks. Rotate keys periodically and immediately on any suspicion of exposure.
Underlying source credentials deserve even stronger handling. In BusinessMCP, OAuth tokens and API keys for connected tools live in an encrypted vault with deny-all row-level security, resolved server-side and never sent to the client. The agent gets tools, never the raw credentials behind them — so a compromised agent key cannot exfiltrate your Stripe secret or your ad-account token.
Apply least privilege to tools
Every tool you expose is a capability an agent can use, so expose only what is needed. BusinessMCP namespaces connector tools and enforces a per-connection allowlist, letting you switch on read-only lookups while leaving write, delete or send tools off. Start closed and open capabilities deliberately rather than exposing everything by default.
There is also a cap on the total number of connector tools per workspace. Beyond keeping the agent focused, a smaller tool surface is a smaller attack surface: fewer operations to reason about, fewer ways for a misused tool to cause harm. Prune tools you are not actively using.
Scope keys and tools together. A reporting integration should get a key whose reachable tools are read-only; an operational automation can have more, but only the specific writes it requires. Match the privilege to the job, not to convenience.
Gate consequential actions behind approval
Some actions are irreversible or externally visible — sending an email to a customer, launching a paid campaign, spending money. For these, autonomous execution is too much power. BusinessMCP gates such actions behind an approval step: the agent proposes the action with its payload, and a human confirms before it runs.
Approval gates let you open the endpoint to genuine automation without ceding control of the actions that matter. The agent still does the work — drafting the email, building the campaign — but the final commit is a deliberate human decision. Combine this with per-run cost caps so an agent cannot rack up unbounded spend even within its allowed tools.
Isolate tenants and audit everything
Multi-tenant safety comes from isolation you cannot accidentally bypass. Every table in BusinessMCP is workspace-scoped with row-level security enforced at the database, so a key for one workspace can never read another tenant’s data — even if application code has a bug. Push isolation down to the data layer; do not rely on filtering in application logic alone.
Finally, log everything. BusinessMCP records every tool call — which tool, what arguments, what result — so you have a complete audit trail of what agents did. Logs turn incidents into investigations you can actually run: you can see exactly what an agent accessed, spot anomalies, and prove compliance. An unlogged agent is an unaccountable one.
Together these practices — key hygiene, least privilege, approval gates, tenant isolation and audit logging — let you give AI agents real access to real data while keeping the blast radius small and the trail complete.
Frequently asked questions
What is the single most important MCP security control?
Key management. Your Bearer key is the perimeter, so scope keys narrowly, issue one per consumer, keep them out of client code and source control, and rotate or revoke them the moment anything looks wrong.
How do I stop an agent from doing something irreversible?
Use least-privilege tool allowlists so the dangerous tool is not even reachable, and put consequential actions behind an approval gate so a human confirms before they execute. Per-run cost caps add a further backstop.
How is one customer prevented from seeing another’s data?
Through row-level security enforced at the database. Every table is workspace-scoped, so a key can only ever reach its own workspace’s rows, independent of application code.
Turn your business into one AI-ready MCP server
Connect your tools, install one tracking script, and expose your unified data to any AI agent through a single secure endpoint.
Get started free