MCP Server Hardening: A Production Checklist

Most MCP server deployments work like this: developer adds a tool, tests it locally, ships it. The tool works. That's enough. It's not secure — it works.

This checklist covers the specific hardening steps you need before putting MCP servers in production. Each step includes the command to verify it.

Dependency Hardening

1. Pin all direct dependencies

# Check for unpinned dependencies
cat package.json | grep '"\^' | head -5
cat requirements.txt | grep -v '==' | head -5

Your package.json should use exact versions ("1.2.3") not ranges ("^1.2.3"). Your requirements.txt should use == not >=.

2. Commit and verify lockfiles

# Lockfile committed?
git log --oneline -- package-lock.json | head -3
git log --oneline -- poetry.lock | head -3

3. Audit for known CVEs

npm audit --audit-level=high
pip-audit

Both should be CI gates — the build fails on HIGH or CRITICAL findings.

Policy Enforcement

4. Every agent has an explicit allowlist

# navil.yaml — your agent's policy
policy:
  deny:
    - tool: "*"
      default: true

The deny-all-default is non-negotiable. If your policy doesn't start with a blanket deny, you have no security — you have guidelines.

5. Each tool call is within path scope

policy:
  allow:
    - tool: read_file
      scope: "./src/**"
    - tool: write_file
      scope: "./src/**"

A tool that can read ./src/** should not be able to read ~/.ssh/. Scope restrictions enforce least-privilege.

6. No secret access

policy:
  deny:
    - tool: read_file
      scope: "**/.env**"
    - tool: read_file
      scope: "**/secrets/**"
    - tool: read_file
      scope: "**/*.pem"
    - tool: read_file
      scope: "**/id_rsa"

Sensitive files should be explicitly blocked regardless of which agent tries to read them.

Runtime Monitoring

7. Anomaly detection is enabled

navil config list | grep anomaly

Anomaly detection tracks behavioral baselines and flags when an agent does something unusual. This catches novel attack vectors that rule-based detection misses.

8. Audit logs are configured

# Verify audit logging
navil config list | grep log

Every tool call — allowed and denied — should be logged. These logs enable forensics, compliance evidence, and continuous improvement.

9. Webhook alerts are set

Configure Slack or Discord webhooks for CRITICAL and HIGH severity events. Alert fatigue is real — only alert on things that need immediate action.

CI/CD Gates

10. Security scan in CI

- name: MCP Security Scan
  run: |
    navil scan --sarif > report.sarif
    navil gate --min-coverage 80

Builds fail when security coverage drops below 80%. This prevents regressions.

11. Pentest automation

navil test --min-score 90

200 attack simulations run on every deploy. If the security score drops below 90, the deploy is blocked.

Operational

12. Weekly coverage score

navil coverage

Track the trend. Your security score should improve over time as policies are tightened and tool access is reduced.

13. Monthly policy review

Review navil.yaml with your team. Remove tools that agents no longer use. Tighten scopes as you understand actual patterns.

14. Threat intelligence updates

navil update-threats

Pull the latest threat patterns from navil's community feed. New CVEs and attack vectors are added regularly.

Summary Scorecard

Run this to get your hardening status:

navil coverage
navil test

If both return 90+, your MCP deployment is production-hardened. Anything below 90 is a quantifiable risk you should fix before shipping.

Want to go further?

• MCP Security Checklist — Free 15-question readiness assessment
• Features — Full policy language reference
• Quickstart — Get set up in under 5 minutes
• Pricing — Free tier included