MCP Server Security Best Practices for Hosted Servers

Secure a hosted MCP server by treating keys as the main boundary: one scoped key per consumer, stored in a secrets manager and revocable instantly. Give each key least-privilege tool access, switch write, delete and send tools off by default, require human approval for irreversible actions, isolate tenants at the database and log every call.

A threat-to-control map

BusinessMCP’s security best practices guide organises controls around six threats. The table below follows that structure with our own commentary; the guide is vendor-authored, though the controls are generic.

Threat	Control	Our note
Leaked or stolen bearer key	One key per consumer, secrets manager, instant revocation and rotation	Test revocation, do not assume it
Agent misuses a powerful tool	Least-privilege allowlists, write/delete/send off by default	Review the tool list as if it were a permission list
Irreversible action such as sending or spending	Approval gates plus per-run cost caps	Gates beat warnings in prompts
Cross-tenant data access	Row-level security, workspace-scoped keys	Enforce below the app layer
Credential exfiltration through the agent	Encrypted vault, server-side resolution	Agents should never see raw secrets
Silent misbehaviour	Full audit log of every tool call	Log arguments and results

Keys first

The guide says key management is the most important control, and we agree for most hosted servers. Keys carry authority; whoever holds one acts as that consumer. Issue one per agent, label it, give it a minimal scope, store it in a secrets manager rather than a config file in a repository, and rotate it if you suspect exposure. BusinessMCP’s endpoint uses mcph_-prefixed keys scoped to a workspace. More on mechanisms in authentication for hosted MCP servers.

Least privilege for tools

Every tool is a capability. Ask what the worst use of each is, then remove what the agent does not need. Concretely:

1. Start every key read-only.
2. Add write tools one at a time with a written reason.
3. Keep send, spend and delete tools behind approvals.
4. Prefer a few well-described tools to many broad ones; narrow tools are easier to reason about.

Per-connection allowlists are one pattern; data-class policies are another. BusinessMCP builds policies from classes such as revenue, contact PII, enrichment, behaviour and messaging, and says restricted keys advertise fewer tools and receive redacted output.

Key takeaway: do not rely on telling the model “do not do X”. Make X unreachable.

Approval gates and cost caps

For actions that cannot be undone, the agent proposes and a human confirms. BusinessMCP describes this for actions like sending email, with per-run cost caps as a backstop. Cost caps matter because an agent in a loop can spend money without any single call looking dangerous.

Tenant isolation

If your server holds data for more than one customer, isolate it where a bug in your application code cannot undo it. BusinessMCP says it enforces isolation with row-level security with workspace-scoped tables. For a server you build, equivalents include separate databases per tenant or database policies keyed on the authenticated tenant. Whatever you choose, test it: try to read tenant B’s data with tenant A’s key.

Prompt injection and tool poisoning

Models read tool names and descriptions as context. A malicious or compromised server can place instructions there: fake system tags, requests to exfiltrate data, “shadowing” other tools, or reading credentials. BusinessMCP’s prompt injection guide covers the pattern in more depth.

Defences that work in practice:

• Pin each tool definition at approval time, and diff on every check.
• Scan new or changed tools, but treat a clean scan as a text screen, not proof of safety.
• Do not connect untrusted third-party servers to agents that hold sensitive tools.
• Combine scanning with least-privilege scoping and approval gates.

The MCP specification itself says clients should treat tool annotations as untrusted unless they come from trusted servers. Our monitoring article shows how to detect drift automatically.

Secrets handling

Encrypt upstream credentials, resolve them server-side, never echo them in outputs or errors, and scope them narrowly at the source. If a connected account lets you create a read-only token, use it.

Logging and audit

Record every call: key id, tool, arguments, result, time. Redact secrets before logging. Retain long enough to investigate incidents, but not so long that logs become a liability. A log that nobody reads is a record, not a control, so assign someone to review it.

A short security review you can run this week

1. List every key and its owner. Delete unknowns.
2. List every tool and mark which can write, send, spend or delete.
3. Confirm each consumer has the minimum tools.
4. Revoke a test key and verify access ends at once.
5. Attempt a cross-tenant read with a test key.
6. Read one day of logs.
7. Pin and hash current tool definitions.

If you host on a managed platform, ask the vendor how each of these is handled; if you self-host, the requirements checklist turns them into rows you can score.

Security by deployment model

Where the server runs changes which controls you own.

Control	Self-hosted	Managed
TLS and certificates	You	Vendor
Key issuance and revocation	You build it	Provided, verify behaviour
Credential vault	You choose and operate	Vendor-operated, verify claims
Tenant isolation	You design and test	Vendor-enforced, ask how
Audit logs	You build and store	Provided, check export
Patching	You	Vendor
Tool allowlists	You	Provided in varying depth

Managed does not mean unexamined. Ask for specifics: how are secrets encrypted, how is isolation enforced, and what can you export? BusinessMCP publishes the code of its gateway under the MIT licence at github.com/businessmcp/mcp-gateway according to its hosting page, which lets you inspect the implementation instead of relying on a description. That kind of transparency is worth weighing, though reading code requires skill, and a published repository is not a guarantee the deployed system matches it.

Mistakes we see most

• Treating prompts as security controls instead of removing capabilities.
• Giving one broad key to every agent.
• Connecting an untrusted community server to an agent that also holds a send or delete tool.
• Logging arguments that contain secrets.
• Skipping revocation tests.
• Never reviewing tool description changes after approval.

If you remember one habit, make it this one: inventory your tools and keys quarterly, and delete anything nobody can justify. For how to run that review for a managed or self-hosted setup, see self-hosted versus managed MCP servers.