N2NS Lab
Back to Blog
Security•4 min read

MCP Server Security Checklist

A practical security checklist for MCP servers covering tool scope, permissions, secrets, filesystem access, command execution, and audit logging.

Written by N2NS Team
Published on 2026-07-02
MCP Server Security Checklist

An MCP server is a trust boundary.

That is the simplest way to review it. The server decides what an AI client can see, what it can call, and what it can change. If that boundary is too wide, the assistant does not need to be malicious to cause damage. A bad prompt, mistaken tool call, or confused workflow can be enough.

Security for MCP servers is mostly about scope.

Give the client the tools it needs. Keep everything else out of reach.

1. Start Read-Only

Read-only tools are easier to review and safer to expose.

If a workflow can start with search, list, inspect, or summarize operations, start there. Add write actions only when the product need is clear.

Good first tools:

  • list resources
  • read selected file
  • search package metadata
  • inspect project status
  • fetch documentation
  • preview draft content

Higher-risk tools:

  • write file
  • publish content
  • run command
  • delete resource
  • update account settings
  • change permissions

Do not expose write access just because the underlying API supports it.

2. Define Allowed Scope Explicitly

Every MCP server should know its allowed scope.

For filesystem access, that means allowed directories. For APIs, it means allowed endpoints and operations. For project tools, it means the active project root. For publishing systems, it means draft operations versus live publication.

Avoid vague access rules such as:

can access user files
can call backend API
can run local commands

Replace them with explicit scope:

can read files under this project root
can create drafts through this API endpoint
can list package metadata only
can run no shell commands

If you cannot describe the scope clearly, the server is not ready.

3. Treat Shell Access As High Risk

Shell access is not a normal tool. It is a power tool.

A command runner can read files, modify projects, install packages, start network calls, and leak secrets. Even a well-meaning assistant can run the wrong command when context is stale.

If shell access is necessary, keep it constrained:

  • Use an allowlist of commands.
  • Avoid arbitrary command strings.
  • Require explicit user approval for writes.
  • Set a working directory.
  • Strip secrets from logs.
  • Return bounded output.
  • Time out long-running commands.

For many MCP servers, the best shell policy is simple: do not expose one.

4. Do Not Leak Secrets

Secrets usually leak through boring paths:

  • environment dumps
  • error messages
  • logs
  • stack traces
  • copied config files
  • broad file reads
  • package manager output

Review every tool response for accidental secret exposure.

If a tool reads files, block common secret files unless the user explicitly opted in. If a tool reports environment variables, redact values by default. If a downstream API error includes tokens, sanitize it before returning it to the client.

The MCP server should be the filter, not the leak.

5. Validate Tool Inputs

Tool schemas are not decoration.

Validate inputs before calling the underlying system. Check paths, URLs, enum values, resource IDs, length limits, and action names. Reject ambiguous operations.

Examples:

  • Normalize paths and reject traversal outside the allowed root.
  • Require exact project IDs instead of fuzzy names for writes.
  • Limit query length.
  • Reject unknown action types.
  • Require draft status before publishing.
  • Validate URLs against allowed hosts.

If a tool accepts raw strings and forwards them directly, review it carefully.

6. Separate Draft From Publish

Publishing workflows need a hard boundary.

Creating a draft is usually lower risk. Publishing, deleting, or updating live content is higher risk. Keep those as separate tools with different requirements.

A safer pattern:

create draft -> preview diff -> human approval -> publish

Do not combine draft creation and publication in one convenient tool unless the product explicitly needs that behavior and the user clearly understands it.

This is the same reason n2n-post2site keeps publishing behind intentional actions instead of letting every content edit go live automatically.

7. Keep Logs Useful But Bounded

MCP servers need logs. They also need restraint.

Log enough to debug:

  • tool name
  • timestamp
  • request ID
  • high-level outcome
  • safe error code
  • scoped resource ID

Avoid logging:

  • raw secrets
  • full private file contents
  • unbounded prompts
  • full environment variables
  • credentials in URLs

Good logs help operators. Bad logs become another data exposure surface.

8. Make Dangerous Actions Obvious

Tool descriptions matter because clients use them to decide when to call tools.

If a tool writes, deletes, publishes, sends, or runs something, say so clearly. Do not hide a destructive action behind a friendly name.

Prefer:

publishDraft: Publishes an existing draft post to the live site.

Avoid:

syncContent: Updates content state.

Names and descriptions are part of the safety model.

9. Check Dependencies

MCP servers are often npm packages. That means ordinary dependency hygiene applies.

Review:

  • direct dependencies
  • install scripts
  • lockfile changes
  • runtime permissions
  • known vulnerabilities
  • abandoned packages
  • packages that execute shell commands

This matters more for servers that touch files, credentials, package managers, browsers, or local services.

An MCP server with a broad toolset and sloppy dependencies is a bad combination.

10. Have A Small Default Config

The safest default is narrow.

Do not ship examples that point at a user's home directory. Do not enable destructive tools by default. Do not require broad tokens for simple read operations.

A good default config should make the first successful setup safe enough to keep.

Users can widen scope later when they understand the tradeoff.

Final Checklist

Before exposing an MCP server, ask:

  • Are tools scoped to a clear job?
  • Are read and write operations separated?
  • Is filesystem access limited?
  • Is shell access absent or tightly controlled?
  • Are secrets redacted?
  • Are inputs validated?
  • Are logs safe?
  • Are dangerous actions named clearly?
  • Are dependencies reviewed?
  • Is the default config conservative?

MCP security does not require fear. It requires explicit boundaries.

The server should make it easy for an assistant to do the right thing and hard for it to wander outside the workflow.