MCP security checklist for business teams

1. Define the workflow and trust boundary

Write one sentence describing what the connection is allowed to accomplish, who initiates it, which system it reads, which system it may change, and who reviews the result. Then draw the data path from source to MCP server, AI host, model provider, logs, and destination. Security reviews fail when 'the MCP server' is treated as a single box even though credentials and customer data cross several operators.

Classify the data and actions in the workflow. A public-web research assistant and a CRM agent with contact exports are not the same deployment. State prohibited data and prohibited actions explicitly. If the team cannot describe the boundary, the connection is not ready to install.

• Name a business owner, technical owner, security reviewer, and incident contact.
• List every host, server, model, subprocess, package registry, and observability destination.
• Record whether the server is local, self-hosted remote, or provider-hosted remote.
• Define the maximum acceptable impact of a mistaken or malicious tool call.

2. Verify publisher and software provenance

Confirm who controls the server endpoint, source repository, package namespace, release process, and signing keys. Prefer a provider's current documentation over a directory description. For open-source servers, review maintainers, license, recent commits, unresolved security reports, dependencies, install hooks, and release tags. Popularity is not a control, and a familiar service name in a package title does not prove affiliation.

Pin reviewed versions where local deployment permits it. Build an update process that includes changelog review, dependency scanning, tool-diff review, and regression tests. Avoid install commands that always fetch the latest package into a production workflow. For remote servers, monitor the discovered tool catalog and provider notices because behavior can change without a local version bump.

3. Get authorization and token handling right

Remote MCP authorization follows OAuth conventions, with OAuth 2.1 flows documented by the protocol. Verify that the client uses PKCE where required, validates redirect URIs and state, discovers the correct protected resource metadata, and requests tokens intended for the MCP server. The official security guidance explicitly prohibits token passthrough: a server should not accept a client token and forward it unchanged to an upstream API.

Ask where access and refresh tokens are stored, how they are encrypted, which processes can read them, how rotation works, and what revocation actually invalidates. Do not place secrets in prompts, committed configuration, shell history, or general chat logs. For local servers, environment variables are common but not magically secure; inspect subprocess access and prefer an operating-system or enterprise secret store when available.

• Use separate credentials for development, staging, and production.
• Validate token audience and do not accept tokens issued for another resource.
• Set short, appropriate lifetimes and test refresh and revocation behavior.
• Require a new authorization decision when meaningful scopes are added.

4. Enforce least privilege at every layer

Limit the source identity first. Host-side toggles are useful, but they are not a substitute for permissions enforced by the system of record. A CRM agent authenticated as an administrator remains overpowered even if its current prompt says to read contacts only. Use a dedicated user or service identity restricted to required accounts, objects, fields, regions, and operations.

Then reduce the exposed tool set. Disable unrelated servers and tools for the workflow, especially generic shell, filesystem, browser, email-send, bulk export, and delete capabilities. Separate read tools, draft-producing tools, and effectful tools into risk tiers. A model that can read hostile content and immediately send data outward has a much larger attack surface than one that can only prepare a cited note.

5. Put consent and confirmation around effects

The user should see the meaningful consequence of a write before approving it: target system, record, fields, old value where relevant, new value, and whether an external person will be contacted. Approval for 'use HubSpot' is not approval for every future update. Avoid permanent blanket approval for write tools in shared business agents.

Make writes idempotent when possible and preserve provider operation IDs. Do not automatically retry a timed-out mutation unless the server can prove it did not complete. Require additional control for bulk changes, permission changes, sends, publishing, refunds, purchases, deletions, merges, and exports. Where rollback is impossible, use a draft or staging object instead.

6. Treat retrieved content as untrusted input

Prompt injection can arrive inside a web page, document, support ticket, CRM note, email, or tool result. Text that tells the agent to ignore policy or call another tool is data, not an authorized instruction. Models do not reliably distinguish benign content from adversarial instructions on their own. Filtering phrases is insufficient because attacks can be indirect, encoded, multilingual, or tailored to the workflow.

Reduce the damage available to an injected instruction. Keep untrusted retrieval separate from secrets and write tools; pass only required fields; label provenance; constrain destinations; validate tool arguments in code; and require human review for consequential actions. For web research, use a read-only environment with no customer systems connected. For support or inbox automation, never let message content select arbitrary recipients or reveal unrelated records.

• Do not expose credentials, hidden system instructions, or full connector inventories to retrieved content.
• Allowlist domains, record types, output destinations, and argument shapes where possible.
• Test with adversarial documents and records, not only friendly prompts.
• Make policy enforcement deterministic outside the model.

7. Secure local execution and network access

A local MCP server is code running with the user's operating-system privileges. It may read files, spawn commands, access the network, or inherit environment variables. Run untrusted or community code in a sandbox, container, or dedicated low-privilege account. Mount only approved directories, use read-only filesystems where practical, restrict outbound traffic, and inspect install and update scripts.

Remote and proxy servers need network controls too. The MCP security guidance calls out server-side request forgery, authorization URL validation, session hijacking, and DNS rebinding risks. Allowlist upstream endpoints, block private and link-local address ranges where not required, validate redirect and authorization URLs, use HTTPS, bind sessions to the correct client, and avoid using session identifiers as authentication. A public endpoint also needs rate limits and abuse monitoring.

8. Minimize data and make logs useful

Return only the rows and fields needed for the task. Large context dumps increase privacy exposure, cost, confusion, and the surface for injected instructions. Apply retention and redaction before content reaches general traces. Tool arguments and results may contain customer data or secrets even when the final answer does not.

Keep an audit trail that connects the human or service identity, host, server, tool, arguments or a safe summary, authorization decision, result status, source record IDs, and provider operation ID. Protect the logs as sensitive data and define retention. Monitor unusual query volume, repeated permission errors, new tools, large exports, unexpected destinations, authentication anomalies, and writes outside normal hours.

9. Test controls, not just happy-path answers

Create tests for cross-tenant access, revoked users, expired tokens, missing scopes, malformed arguments, hostile retrieved text, oversized responses, upstream timeouts, duplicate retries, partial completion, and unavailable audit services. Verify that failure is visible and fails closed. An empty answer that hides an authorization error can be as damaging as an exception if a business user assumes no records exist.

Repeat the evaluation after changes to the model, host, server, tool definitions, scopes, dependencies, or source schema. Run a tabletop incident: revoke the credential, disable the server, identify affected workflows, retrieve the relevant logs, notify owners, and restore a known-good version. If the team cannot do those steps during a test, it will not do them cleanly during an incident.

10. Approve a bounded release

Start with named users, a single workflow, read-only access, non-sensitive or minimized data, and a defined review period. Publish acceptable-use guidance and a manual fallback. Record an expiration date for the approval rather than allowing an experimental connection to become permanent by neglect.

Do not release if the publisher is unverified, scopes cannot be constrained, tool side effects are unclear, tokens cannot be revoked, logs cannot attribute actions, or the server can mix customer tenants. A business deadline does not reduce those risks. Choose a conventional API integration, a human-operated export, or no connection until the controls exist.

• Inventory entry and current owner
• Approved version, endpoint, host, model, and tool list
• Data classification and retention decision
• Identity, scopes, and write-approval policy
• Evaluation results and known limitations
• Monitoring, incident, offboarding, and review dates