Securing an MCP server means controlling what a tool can do, on whose behalf, and with which data. MCP standardizes interaction; it does not automatically sandbox executables, enforce database ownership, or make model-proposed actions safe.
This guide complements Building an MCP Server and Connecting LibreChat to MCP Tools. Apply protocol-version-specific requirements from the official specification when implementing authorization.
Treat tools as privileged APIs
Write a capability inventory before exposing a server. Separate reading, writing, deletion, command execution, and external communication. A tool named search_notes should not also execute SQL or fetch arbitrary URLs.
Prefer narrow operations with validated schemas over a general shell, unrestricted query endpoint, or arbitrary filesystem path. Validate inputs again at the execution boundary even if the client validated them already.
Authenticate and authorize independently
For remote HTTP tools, verify the credential and intended audience using the supported authorization scheme. Then authorize the specific operation and resource. Knowing a record ID, session identifier, or job handle is not permission to access it.
Derive identity from verified credentials or an authenticated, trusted gateway. Do not accept arbitrary user_id, role, or tenant arguments as proof of authority. Apply ownership constraints in database queries and file lookups.
Local standard-input/output servers have a different boundary: the launched process generally inherits the client's OS privileges unless sandboxed. Review the exact command and arguments before enabling it. Downloading and running an unpinned package is executable-code installation, not just configuration.
Limit the blast radius
| Capability | Safer boundary |
|---|---|
| File access | Approved roots, canonical paths, symlink-aware containment |
| Database access | Separate account, minimum privileges, parameterized queries |
| Command execution | Fixed executable and argument list, no shell interpolation |
| Web fetching | Destination policy, redirect checks, restricted egress |
| Writes | Ownership checks, bounded inputs, audit record |
| Long jobs | Time, memory, output-size, and concurrency limits |
Private network placement helps, but is not a replacement for authorization. A compromised client on the same network can still call an unprotected tool.
Keep consent meaningful
Require confirmation for destructive, costly, or externally visible actions. The confirmation should identify the target and intended effect. A general "allow tools" checkbox is not equivalent to approving every future deletion or message.
Bind confirmation to the actual operation so arguments cannot change after approval. Use server-side idempotency for retryable writes; a timeout does not prove the first attempt failed.
Defend against untrusted tool content
Tool descriptions and returned text can contain malicious instructions. Do not let a retrieved page expand credentials, change policy, or authorize another tool. Keep secrets out of prompts and avoid reflecting credentials in errors.
For HTTP discovery and URL-fetching tools, validate destinations and redirects and account for DNS rebinding. A broad URL parser alone does not prevent requests to internal administration services or cloud metadata endpoints.
Observe and test
Log the authenticated principal, operation, resource reference, timestamp, result, and correlation ID while redacting sensitive values. Test cross-user reads and writes, traversal, invalid inputs, missing credentials, resource exhaustion, cancellation, and duplicate requests.
Pin dependencies, review updates, and revoke unused credentials. A passing happy-path demo is not a security review.