Secure MCP integrations for business applications

Start with the business capability, not the connector catalog

Define the task the assistant needs to perform and the smallest set of capabilities required. An account-support workflow might need to read subscription status and create a draft ticket. It may not need access to payment credentials, bulk exports, or account deletion.

Map each capability to an existing business permission. If the ordinary application would not allow a user to perform an action, connecting an AI client should not create a shortcut around that rule. The integration should preserve the organization’s resource and role boundaries.

Evaluate whether MCP adds value for the intended environment. A reusable connector used by several clients may justify the protocol, while a single tightly scoped internal service call may be simpler through an existing API. Interoperability is useful when it serves a real integration need.

Document the initial scope and the features deliberately excluded. This gives reviewers a concrete boundary and prevents a convenient server package from introducing many unused capabilities simply because they are available.

Review the server as software with meaningful access

Identify who maintains the MCP server, how it is distributed, what code or service will run, and what resources it can reach. A server running locally can have access to files, environment variables, or network services depending on its configuration. A remote server introduces a different data and trust arrangement.

Inspect required credentials and permissions before installation or connection. Broad administrator access may be convenient for setup but inappropriate for the task. Determine whether scopes can be reduced and whether separate connections are needed for different environments or user roles.

Review update behavior. A connector that changes automatically can introduce new tools or altered semantics without the product team noticing. Establish a process for version changes and compatibility checks according to the risk of the capabilities exposed.

Keep a registry of approved integrations with owners, purpose, access, and data categories. The registry should make it possible to answer which systems an assistant can reach and who is responsible when the connection stops working or needs to be revoked.

Keep identity and token boundaries explicit

The MCP security guidance warns against token passthrough and requires tokens accepted by an MCP server to be intended for that server. It also discusses consent and authorization risks in proxy arrangements. Follow the relevant authorization specification rather than improvising a credential-forwarding shortcut.

For the business application, document whose authority each tool call uses. A personal user connection, a service account, and a delegated organizational identity have different consequences. The audit trail should not imply that a human directly performed an action when it was executed by an automated workflow under a service identity.

Use narrowly scoped credentials and a clear revocation process. If a user leaves an organization or disconnects an integration, subsequent calls should lose access appropriately. Test this behavior rather than assuming that deleting a visible connection removes every cached credential.

Keep credential storage and refresh outside model context. The agent does not need raw tokens to use a tool. The application should manage them through the trusted integration layer and prevent secrets from appearing in tool results, errors, or conversational logs.

MCP: security best practices

Design tools with narrow, validated contracts

Prefer capabilities that express a business operation, such as retrieve an authorized customer summary or prepare a case update. A general execute-query or arbitrary-request tool can be much harder to constrain and review.

Validate every input and enforce resource ownership in the server-side implementation. A tool description can explain what is allowed, but it is not the enforcement mechanism. Reject identifiers outside the caller’s scope, invalid state transitions, and values that violate business rules.

Return only the information needed for the task. A customer summary does not necessarily require every contact detail or internal note. Structured results with clear status and error categories help the assistant respond without exposing unnecessary data.

Separate preparation from execution where consequences matter. A tool that creates a proposal can be available more broadly than a tool that applies it. This design makes approvals concrete and gives the application a stable object to validate, review, and execute.

Preserve permissions across search and resource access

Connected knowledge sources may contain documents with different access rules. Apply those rules before returning content to the client or model. Do not retrieve everything and rely on the assistant to avoid mentioning restricted passages.

Consider organization switching, group changes, and shared caches. A result available to one user may not be available to another. Cache design and source indexing must preserve the relevant authorization context and respond appropriately when permissions change.

Test indirect references. A tool may accept a document identifier, attachment link, or resource URI obtained from another result. The receiving operation still needs to authorize that resource rather than trusting that an earlier tool call already made it safe.

Keep access-denied behavior understandable without disclosing unnecessary information. Operators need enough evidence to diagnose a policy problem, while users should receive a clear next step. Avoid turning detailed errors into a way to enumerate confidential records or internal system structure.

Treat tool results and descriptions as potential attack surfaces

An assistant may receive text from documents, tickets, or third-party systems that attempts to redirect its behavior. Keep those sources in the data category rather than allowing them to change the trusted task, available permissions, or destination of sensitive information.

Review tool descriptions and changes to them as part of the integration’s software supply chain. The application should know which server supplied a capability and should not assume every discovered tool is appropriate for every task.

Restrict the tool set to the current workflow where possible. A document-reading task does not need an unrelated message-sending or file-deletion capability. Reducing the available action surface limits the consequences of a model following a misleading instruction.

Build adversarial cases into evaluation. Include a document that asks for an unauthorized export, a result that suggests sending data to an external address, and conflicting instructions disguised as administrative guidance. Inspect actual calls and data exposure rather than only the wording of the final answer.

Constrain network and local execution

Decide which network destinations the integration genuinely needs and enforce that boundary through the environment and application configuration. Metadata discovery, redirects, and user-supplied URLs can create paths to destinations the original task did not require.

For local servers, use an execution environment proportionate to their access. Separate project files, secrets, and system capabilities where practical. A connector that only reads a selected directory should not need unrestricted access to unrelated personal or production data.

Avoid using the model as the validator for paths or URLs. The trusted layer should resolve and validate targets, handle redirects deliberately, and reject disallowed destinations. These checks need to account for the actual network and filesystem environment.

Record and review exceptions. Development conveniences such as local endpoints or broad file access should not silently become production defaults. A documented exception with a clear purpose is easier to manage than a configuration copied between environments without understanding its original assumptions.

Require meaningful approval for consequential actions

Define which operations need confirmation according to their effect. Sending external communications, changing financial records, or modifying access may warrant review. Read-only operations within an already authorized task can often proceed without repeated prompts that add no useful protection.

Show a concrete proposal before execution. Identify the record, action, important values, destination, and expected consequence. The reviewer should be able to understand what will happen without reading the entire agent trace.

Bind the approved proposal to execution and recheck current permissions and state. If the target changes or the proposal is edited, decide whether approval must be renewed. Do not allow a vague earlier confirmation to authorize a materially different action later.

Preserve an audit record of the proposal, approval, execution, and result with appropriate data minimization. This supports investigation and helps distinguish an agent error from a connector failure or a legitimate action that produced an unexpected business outcome.

Test reliability and recovery at the integration boundary

A tool call can time out after the downstream system has already completed the action. Use stable operation identifiers and idempotency where supported. The workflow should discover the actual result before repeating a consequential operation.

Test expired credentials, revoked membership, rate limits, unavailable servers, malformed results, and incompatible versions. The assistant should receive a structured failure it can handle, while operators receive enough context to diagnose the problem.

Exercise partial completion across multiple systems. If a case is created but a document attachment fails, return that distinction and provide a recovery path. Do not describe the whole workflow as complete or retry every step without checking what already exists.

Set budgets for calls, concurrency, and expensive downstream operations. MCP standardizes communication, but the business still pays for the work performed through connected services. Limits should be enforced outside the model and produce an understandable result when reached.

Roll out with an owner and a capability inventory

Start with a small set of read or draft capabilities for a defined user group. Verify that the integration preserves existing permissions and improves the intended workflow. Add write capabilities individually after their approval and recovery behavior is tested.

Maintain an inventory of deployed servers, versions, tools, credentials, and owners. Review it when staff roles change, vendors update, or the product adds a new use case. Remove unused capabilities and connections rather than leaving them available indefinitely.

Provide a way to disable a server or tool promptly and continue through an ordinary workflow. Test revocation and the operational response, not only initial connection. A secure integration is one the organization can understand throughout its lifecycle: why it exists, what it can do, which data it can access, and how to stop it when circumstances change.