MCP Security Best Practices for Enterprise: A Working Checklist

The core MCP security practices for an enterprise are: one scoped key per consumer kept in a secrets manager, least-privilege tool access that starts closed, human approval for irreversible actions, database-level tenant isolation, an audit log of every call, and treating all tool output as untrusted. Everything else refines those six.

Why MCP changes the threat model

Before agents, an integration did one thing in code you wrote. With MCP a model chooses which tool to call, with which arguments, based on text it has read, some of it from outside your control. That makes two older risks sharper. The first is credential theft, because a key now unlocks a flexible actor rather than a fixed script. The second is excessive agency, a category the OWASP list of LLM application risks calls out explicitly: giving a model more capability than the task requires.

BusinessMCP’s security guide puts the stance bluntly: your Bearer key is the perimeter. That is a fair summary of remote MCP, where possession of a key is often the whole authentication story, a pattern defined by the bearer-token specification in RFC 6750. If the key leaks, anyone holding it can act.

The checklist

#	Control	Why	Evidence to ask for
1	One key per agent or integration	Targeted revocation	Key list with owners
2	Secrets manager storage	Keys out of repos and browsers	Config review
3	Least-privilege allowlists	Limits what a hijacked agent can do	Policy per key
4	Write, delete and send off by default	Safe starting state	Default policy
5	Approval gates on irreversible actions	Human in the loop	Approval log
6	Per-run cost caps	Stops runaway spend	Plan or setting
7	Database row-level isolation	Tenant separation not left to app code	Architecture doc
8	Vaulted source tokens	Agent cannot read upstream credentials	Vendor description
9	Audit log of each call	Detect and investigate	Log sample
10	Output treated as untrusted	Injection resilience	Test results

Key takeaway: assume a key will leak and a model will be tricked. Design so that either event produces a small, visible and reversible problem.

Controls in more detail

Keys and identity

Issue a separate key for every agent, machine and integration. Store each in a secrets manager and keep them out of source control and any client-side code. Rotate on a schedule and immediately if exposure is suspected. BusinessMCP states that its platform API keys are stored as SHA-256 hashes and shown once, which means a lost key is replaced, not recovered; that behaviour is a good sign when evaluating any vendor.

Least privilege at the tool layer

Start closed and enable capabilities deliberately. A reporting integration should be read-only. A research agent should not be able to send email. Prune tools you do not use. The practical mechanics are covered in enterprise MCP access control, including data classes and presets.

Approvals and cost caps

For anything irreversible or expensive, require a person to confirm. BusinessMCP’s Enterprise page lists approval gates on email sends and code changes, with code delivered as pull requests, and human approval for ad-budget changes. Add per-run cost caps as a second brake; an agent in a loop can burn a budget faster than any reviewer notices.

Isolation and credential handling

If a platform is multi-tenant, isolation belongs in the database. The Enterprise page describes workspace-scoped data through Postgres row-level security and connected keys and OAuth tokens in a deny-all vault. For servers that touch your most sensitive systems, the stronger answer is to run them inside your own network, as the page describes for custom deployments inside a VPC. The architecture article compares placements.

Logging

Log tool, arguments and result for each call, and make sure the log exists before you grant write capability. See MCP audit logging for what to retain and how to review it.

Defending against prompt injection

Text returned by a tool, a web page or a document can contain instructions meant for the model. You cannot filter all of it. What you can do is bound the consequences.

1. Keep the agent’s tool set small for each task.
2. Separate agents that read untrusted content from agents that can act.
3. Require approval before any outbound action that uses data the agent just read.
4. Log calls so that unusual sequences are visible.

BusinessMCP’s guide on MCP prompt injection covers tool poisoning and injection through tool results. Treat it as one input to your own threat model, not as a guarantee.

What a platform cannot do for you

A governed endpoint helps, but several responsibilities stay with you: deciding which data classes each agent really needs, protecting the humans who can edit policy, reviewing access regularly, and handling incidents. The Enterprise page also lists limits worth reading as part of due diligence, including that there is no SOC 2 report or ISO 27001 certification and no 24/7 on-call. Those are disclosures, not defects, but they should flow into your risk assessment. The enterprise-ready article shows how to weigh them.

A 30-day hardening plan

1. Week one. Inventory agents, keys and tools. Remove anything unused.
2. Week two. Split shared keys, assign least-privilege policies and move secrets into a manager.
3. Week three. Turn on approvals for every irreversible action and set cost caps.
4. Week four. Test the controls with a restricted key, confirm logs capture each call and schedule a quarterly review.

Do the inventory first. You cannot secure what you have not listed, and most teams discover at least one forgotten key with far more power than its job needs.

Putting the checklist into a vendor review

If you are buying rather than building, turn the table into questions. Ask how keys are stored, whether disallowed tools are hidden and also blocked at execution, which actions require approval by default, how tenants are isolated and what the audit log captures. BusinessMCP’s Enterprise page answers many of these in public, for example approval gates, scoped policies that fail closed and a vault for connected credentials, while stating its limits. Check the claims against your own tests rather than taking any vendor’s word, and record the answers beside the controls above.

Incident response for agent systems

Prepare for the day a key leaks or an agent misbehaves. Write a one-page runbook: how to revoke a key, how to disable a tool, who decides, where the logs are and who must be told. Practise it once. The speed of response is determined almost entirely by whether keys are per-consumer and whether the log is searchable, which is why those two items top the list.