To reduce prompt injection risk in MCP integrations, secure the host, the client, the server, and the downstream operation. Model Context Protocol standardizes communication; it does not make every tool description or returned document trustworthy. I would assume an MCP result can contain attacker-controlled text and prevent that text from granting additional authority.
This guide uses the MCP security guidance dated 2025-11-25 as a reference point, while keeping deployment-specific advice explicit. Implementations and SDK defaults change, so verify the version and controls you actually run. No protocol label or installed package automatically supplies a complete prompt injection defense.
Know which component controls which decision
An MCP host is the application coordinating the assistant and integrations. Its clients communicate with MCP servers, which expose capabilities and connect to resources or other services. The exact packaging varies, but these responsibilities should be clear before you decide where to enforce a control.
I would put resource authorization at the server or downstream service that knows the caller and target. The host should control which integrations and actions the assistant can use. Neither side should assume the other has already made every security decision. A server receiving a valid-looking tool call still needs to decide whether the caller may perform it.
This matters for indirect injection. A server can return a legitimate document containing malicious instructions without being malicious itself. Transport security can protect delivery while the delivered content remains untrusted. Review the content's authority separately from the connection's identity.
Review servers before installation or connection
A local MCP server is executable software. Installing it can run code with access to files, environment variables, or network services available to its process. A one-click configuration should not hide the command and arguments that will execute. I would verify the publisher, package identity, source, and intended privileges before starting it.
For remote servers, verify the endpoint and the permissions requested during connection. A familiar tool name is not proof of a trustworthy service. Keep an inventory of approved integrations and remove unused ones. Where practical, review version updates before automatically adopting changed behavior.
Pinning a package version can improve change control, but it is not a permanent safety guarantee. Maintain an update process for vulnerabilities and compromise reports. Avoid treating popularity, an attractive logo, or a directory listing as equivalent to an independent security assessment.
| Boundary | Responsible check | Do not assume |
|---|---|---|
| Host to integration | Approved server and allowed capability | A known tool name establishes trust |
| Request to resource | Verified caller and resource authorization | A valid schema grants permission |
| Server to downstream API | Correct scoped credentials | Token forwarding is acceptable |
| Local process to host | Filesystem and network isolation | A workspace folder is a sandbox |
Treat tool descriptions and results as untrusted input
The model may read tool descriptions, resource content, and returned errors. Any of those surfaces can contain instructions that try to influence later behavior. A description should explain the tool's legitimate function; it should not be able to redefine the host's policy or demand access to unrelated resources.
I would preserve the origin of tool metadata and results, constrain their size, and avoid placing them into a privileged instruction channel. If a server changes its tool list or descriptions, consider whether the change requires renewed review. A previously approved integration should not silently acquire an entirely new high-impact capability.
Labels and model instructions can help the assistant interpret these inputs, but they do not enforce permissions. A result asking the assistant to call a second server with private data must still encounter independent checks on the second call. Trust should not spread automatically from one integration to another.
Expose narrow tools and validate every request
Prefer operations that express the intended task, such as reading one authorized ticket or preparing a specific update. A universal shell, unrestricted query executor, or arbitrary URL fetcher creates a much wider consequence range. If broad capabilities are unavoidable, isolate them and give them explicit limits.
Validate tool arguments against a maintained schema, then check semantic constraints such as valid target types, allowed destinations, and maximum operation scope. A schema can establish that an identifier is a string; it cannot establish that the caller owns the corresponding record.
I would reject attempts to supply a different tenant, role, or identity through model-controlled arguments. Derive security context from verified authentication and server-side policy. Keep returned results bounded too, so a tool meant to answer a narrow question does not unnecessarily expose an entire account or configuration.
The dated MCP security guidance is the primary reference for protocol-specific token, session, network, and local execution requirements discussed here.
Handle authentication, tokens, and sessions correctly
For remote protected MCP resources, use the supported authorization design rather than improvising token forwarding. The referenced MCP guidance forbids accepting tokens that were not issued for the MCP server. Verify the intended audience and other required token properties through a properly configured authorization implementation.
I would keep downstream credentials under the server's control and use appropriately scoped authorization when calling other APIs. Do not expose raw tokens to the model as a convenience. Token passthrough can bypass intended boundaries and make it unclear which actor performed an operation.
A session identifier is not a substitute for authentication. Authorize incoming requests as required and bind session-related state to the verified user. In a stateful or horizontally scaled deployment, queued events and resumed responses also need correct user association so another party cannot inject material through a shared session mechanism.
Isolate local execution and network access
Run local servers with only the directories, environment variables, and network access they need. A dedicated workspace is useful organization, but it becomes a security boundary only when operating-system or sandbox controls enforce the restriction. Avoid exposing home directories, credential stores, or privileged host interfaces without a task-specific need.
For networked components, enforce destination policy outside the model. URL checks should account for redirects, private address ranges, and changes between validation and use. OAuth discovery can itself involve server-supplied URLs, so the client needs protection against unintended internal requests as well as ordinary tool execution risks.
I would also protect local HTTP listeners rather than assuming localhost makes them safe. Use the appropriate authentication and access restrictions for the transport and deployment. Direct stdio communication limits who can speak through that channel, but it does not make the server executable or its dependencies trustworthy.
Bind approvals to the operation that executes
The host can require review before consequential calls, but the approval must describe the actual action. Show the server, tool, target, changed values, recipient, or destination as relevant. A general permission to use an integration should not stand in for approval of every operation it can expose.
I would bind approval to the validated request and invalidate it when important arguments or tool definitions change. Execution should not proceed because the model writes that a user approved something. The host or service needs its own record of consent and policy satisfaction.
For high-impact operations, keep server-side checks even when the host supplies a good review interface. Different clients may connect to the same server, and one client might not enforce the expected interaction. The resource-owning component must still reject unauthorized callers and operations.
Test both content attacks and protocol boundaries
Use a controlled MCP server or fixture that returns a harmless instruction requesting a forbidden dummy action. Verify that the host treats the result as source material and that the executor blocks the action if the model proposes it. Record the actual tool calls rather than relying on the assistant's explanation.
Then test authorization separately: wrong audience, expired or invalid credentials, cross-user resources, altered tenant arguments, and session state associated with the wrong identity. These are distinct from prompt injection, but failures can make an injected instruction more consequential.
I would include a tool metadata update and a resumed-response scenario when the deployment supports them. Test normal workflows too, including expected denials. A secure integration should fail clearly enough that users do not respond by granting a broad token or disabling all checks just to complete a routine task.
Operate the integration as a maintained service
Log the integration identity, caller, tool, target, authorization result, approval reference, and execution status without dumping credentials or unnecessary private results. Make it possible to disable one server or revoke one credential quickly. Keep an owner for updates, incident reports, and permission reviews.
When suspicious behavior occurs, preserve relevant metadata, stop the affected path, and determine whether any downstream action happened. Rotate exposed credentials and inspect persistent state where necessary. Restarting the assistant does not repair a compromised server package or an overly privileged service account.
My practical order is to review the integration, minimize its authority, enforce request checks, and test failures before scaling access. MCP makes useful connections possible; secure deployment decides how much authority those connections carry and whether untrusted text can exploit it.
Common questions
Does MCP itself stop prompt injection?
No. The protocol structures communication. The host, server, and downstream services still need trustworthy permission checks and careful handling of supplied content.
Are local servers safer than remote servers?
They have different risks. Local servers execute code near your files and environment; remote servers introduce endpoint, authorization, and data-sharing concerns. Assess the actual privileges.
Is schema validation enough?
No. It checks structure, while authorization checks whether this caller may perform this operation on this resource. Both are necessary.
Can I use a session ID as proof of login?
No. Follow the authorization requirements for the deployment and bind session state to a verified identity. Possessing session state must not replace the required authentication checks.