MCP Server Security: Build a Safer Tool Boundary

An MCP server can give an AI application access to files, services, or other tools, so it should be treated as a boundary between the model and your systems—not as a trusted helper. The steps below show how to limit what the server can do, validate requests, protect credentials, and make tool use observable. You’ll need a working MCP client and server, plus control of the server’s configuration and deployment environment.

What You’ll Need

A development or test environment separate from production.
The MCP server source code or configuration, and a way to run its tests.
A list of tools the server exposes, the data each tool can access, and the actions each can take.
Credentials stored in a secret manager or protected environment configuration—not in source code.
Logs and a process for reviewing changes to permissions and tool definitions.

Step-by-Step

Define the boundary and threat model. Write down which users and clients can connect, what data the server can reach, and what could go wrong if a request is mistaken or malicious. Include prompt injection: untrusted text in a file, webpage, or tool result can try to persuade a model to misuse other tools. Treat model-generated arguments and retrieved content as untrusted input. Decide which actions are read-only, which change state, and which must never be available.
Expose only necessary tools. Remove unused tools and avoid broad operations such as unrestricted shell commands, arbitrary code execution, or access to an entire filesystem. Prefer narrow tools with a single purpose, such as retrieving one record by an authorized identifier. If a capability is not needed for the task, do not expose it “just in case.” Review the tool list whenever the server changes.
Run with least privilege. Use a dedicated operating-system or cloud identity for the server. Grant access only to the specific files, directories, APIs, and actions required. Keep development, staging, and production credentials separate. Where possible, use read-only credentials for lookup tools and separate, limited credentials for write operations. Do not rely on instructions to the model as a substitute for technical access controls.
Validate every argument on the server. Check types, required fields, lengths, allowed values, and identifier formats before doing work. Reject unexpected fields where practical. Normalize and constrain file paths to an approved root; do not assume a path is safe because it looks relative. Use parameterized database queries rather than building query strings from user input. Enforce authorization for the requested resource on every call, not just when the client connects.
Make sensitive actions deliberate. Separate read tools from tools that send messages, change records, delete data, or trigger external effects. For consequential actions, use explicit confirmation in the surrounding application and show the user what will happen, including the target and key parameters. Add server-side checks as well: confirmation should not be the only safeguard. Consider requiring a second approval or a narrow allowlist for especially sensitive operations.
Protect credentials and connections. Keep tokens out of tool descriptions, prompts, logs, and error messages. Load secrets from a managed secret store or protected runtime configuration, scope them narrowly, rotate them when exposed, and avoid long-lived credentials where feasible. Use authenticated, encrypted connections appropriate to the deployment. For local servers, verify the executable and configuration the client launches; for remote servers, restrict who can connect and verify the server identity.
Control outputs and failures. Return only the information the caller needs. Remove secrets and unnecessary personal or internal data from results. Set limits on result size, execution time, and resource use so one request cannot consume unlimited resources. Handle errors with useful but non-sensitive messages; keep stack traces and internal paths out of responses. Treat tool results as untrusted data when they are passed back to a model.
Log use safely and test adversarially. Record which tool ran, when, whether it succeeded, and a suitably minimized account or request identifier. Avoid logging credentials, full sensitive payloads, or private content by default. Test malformed arguments, unauthorized identifiers, path traversal attempts, oversized inputs, timeouts, and prompt-injection text in retrieved content. Confirm denied actions really fail at the server. Review logs and tests after each change.
Deploy with a recovery plan. Pin and review dependencies, apply updates through a controlled process, and keep a record of configuration changes. Start with limited access, monitor the server, and expand only when needed. Know how to disable a tool, revoke its credentials, or stop the server quickly if it behaves unexpectedly. Test that rollback or credential revocation works before relying on it.

Common Mistakes

Trusting the model to enforce policy: Model instructions can help guide behavior, but the server must independently authorize each operation.
Giving a tool broad access: A convenient “read any file” or “run any command” tool makes an error much more damaging. Replace it with specific, constrained operations.
Checking permissions only once: A permitted connection does not mean every later request or resource is authorized.
Logging everything for debugging: Logs can become another store of credentials and sensitive data. Minimize, redact, and restrict access to them.
Assuming confirmation makes an operation safe: Users may approve unclear or misleading prompts. Show precise consequences and retain server-side limits.
Testing only normal requests: Include malicious, malformed, oversized, and unauthorized inputs, plus failures in downstream services.

Tips

Keep each tool’s name, description, inputs, and effects clear and specific. Avoid descriptions that imply more authority than the implementation actually grants.
Use allowlists for actions and destinations when possible. Deny by default, and make new permissions an explicit review decision.
Give write tools predictable, limited effects. For example, update a named field rather than accepting an arbitrary database command.
Make tool definitions and permission changes part of code review. A small description change can influence how a model chooses a tool.
Document who owns the server, how to report suspicious activity, and how to revoke access during an incident.

Troubleshooting

A legitimate call is rejected: Check the server’s validation and authorization logs, then compare the actual argument types and permitted resource scope with the tool definition. Fix the narrowest incorrect rule; do not solve it by granting broad access.

The model keeps choosing a risky tool: Remove that tool if it is unnecessary. Otherwise, clarify its description, narrow its inputs, and enforce restrictions in server code. Do not depend on a prompt-only warning.

Requests time out or return too much data: Add bounded timeouts, pagination or result-size limits, and safe handling for downstream failures. Check whether limits are enforced by the server rather than only by the client.

Sensitive values appear in logs or responses: Stop the affected flow if needed, restrict access to the exposed records, remove or redact data where supported, and rotate any exposed credentials. Identify how the value entered the output and add a regression test.

You cannot tell whether a tool call was authorized: Improve structured audit events to capture the tool, outcome, and relevant non-sensitive identity or request reference. Avoid adding raw secrets or full private payloads to make the logs more detailed.

Frequently Asked Questions

Does MCP itself make a server safe?
No. The protocol provides a way for clients and servers to exchange information; the server still needs authentication, authorization, input validation, and operational safeguards.

Should every tool call require user confirmation?
Not necessarily. Confirmation is most useful for consequential or irreversible actions. Low-risk read operations may not need it, but still require authorization and bounded access.

Can I expose a shell or filesystem tool safely?
Broad access is difficult to constrain reliably. Prefer purpose-built tools. If a system-level capability is essential, isolate it, restrict its identity and scope, validate inputs, and test the limits thoroughly.

Is a read-only server risk-free?
No. Read access can expose confidential information, and returned content can contain prompt-injection attempts. Limit accessible data and treat results as untrusted.

What should I do if a credential is exposed?
Revoke or rotate it promptly, check for unauthorized use, remove it from future outputs and logs, and investigate the source of exposure. Do not assume deleting one visible log entry is sufficient.

How often should I review the boundary?
Review it when tools, dependencies, identities, data sources, or deployment settings change, and periodically as part of normal maintenance. Re-run security tests after material changes.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →