MCP security begins with trust boundaries

Connectivity changes the threat model

A tool protocol can make an integration easier to build without making its actions safe by default. Once an assistant can search internal information, modify records, or invoke external services, the security question changes. It is no longer only what the model says. It is what the surrounding system allows it to read, transmit, and change on someone's behalf.

The Model Context Protocol authorization specification requires servers to validate that received tokens are intended for them. Its security guidance also discusses risks such as token passthrough and confused-deputy behavior. These are concrete protocol concerns. Our broader architectural recommendation is to review an MCP connection with the same care as a privileged application integration, while accounting for the model's exposure to untrusted content.

Name the principal at every boundary

Draw the path from the person making the request to the service performing the action. Identify the end user, the agent runtime, the MCP server, and any downstream API. For each hop, ask which identity is authenticated and whose permissions determine the allowed operation. If the answer becomes simply the shared service account, investigate whether the application has lost the user's original access boundary.

A shared connector can be appropriate for tightly defined operations, but its broad credentials should not automatically become the agent's authority. Keep user identity and tenant context outside model-generated arguments. Derive them from trusted application state and validate them in the service that performs the action. A prompt that names a different organization must not change which organization's data the connector can access.

Expose a smaller action surface

Tool design affects how easily authority can be understood. A generic execute-any-request tool may be convenient during development, but it makes review and enforcement difficult. Prefer operations whose consequences are clear: retrieve a permitted document, prepare a proposed update, or submit one approved action. Validate identifiers, field names, and allowed transitions before contacting the destination service.

Separate read access from write access when the workflow permits it. Give development and evaluation environments their own credentials and resources. Restrict outbound destinations for connectors that do not need arbitrary network access. These choices create operational constraints independent of the model's interpretation. They also make incident response more precise: disabling one capability need not remove every useful feature from the application.

Treat returned content as data

A legitimate tool can return hostile content. A document, web page, repository file, or support message may include instructions intended to influence the assistant. The fact that the content arrived through an approved connector does not make it an instruction from the user or the application. Preserve information about where it came from and avoid promoting that content into a higher-trust instruction channel.

Defenses should account for attempted actions as well as suspicious wording. A request to send confidential content to an unfamiliar endpoint should fail policy checks even if the prompt injection was never recognized as such. Test combinations: an authorized search result containing an instruction, a tool response that suggests a different identity, and a workflow that tries to combine individually permitted actions into an unauthorized outcome.

Review installation and update paths separately from runtime authorization. A connector that runs local code introduces a different risk from a remote service accessed through a narrow API. Record who can install it, which environment it runs in, and which files or credentials it can reach. Approval of a useful tool should never implicitly approve an unrestricted execution environment.

Operate the integration after launch

Maintain an inventory of enabled servers, owners, permissions, versions, and data destinations. Review changes to tool descriptions and schemas because they can alter the model's behavior even when an endpoint remains the same. Decide how credentials are revoked, how a connector is suspended, and how unfinished tasks are reconciled after an incident. Make those procedures executable before they are urgently needed.

For each sensitive action, retain a bounded record of the requesting identity, selected tool, validated arguments, authorization decision, and observed result. Avoid turning the audit trail into an uncontrolled copy of confidential content. A secure integration is a continuing relationship between systems. The protocol provides a common way to communicate; the product team still owns the decisions about who can do what, with which evidence, and under which constraints.