How to Secure Your MCP Server: Governance Checklist

Why MCP Servers Need Governance

MCP (Model Context Protocol) servers expose capabilities to AI agents — file access, cloud APIs, databases, communication tools. In development, security is an afterthought. In production, an unsecured MCP server is an open door.

This checklist covers the security controls every production MCP server should implement.

Authentication and Authorization

Who Can Connect?

• Transport security — MCP connections use TLS. No plaintext stdio in production network deployments.
• Client authentication — Each connecting agent/client has a unique identity (API key, mTLS certificate, or OAuth token).
• Connection allowlist — Only known clients can connect. Unknown clients are rejected before any tool is exposed.

What Can They Do?

• Tool-level authorization — Not every client can invoke every tool. Define which clients have access to which tools.
• Parameter-level restrictions — A client authorized to read files might be restricted to specific directories. A client authorized to query databases might be restricted to read-only queries.
• Rate limiting — Cap tool invocations per client per time window. Prevents runaway agents from exhausting resources.

Example: Scoped Access

{
  "client": "deploy-agent",
  "allowed_tools": ["read_config", "check_health"],
  "denied_tools": ["write_config", "restart_service"],
  "rate_limit": "100 calls/minute"
}

Input Validation

Validate Everything

• Type checking — Every tool parameter has a defined type. Reject malformed inputs before processing.
• Length limits — String parameters have maximum lengths. Prevents memory exhaustion from adversarial inputs.
• Path traversal prevention — File path parameters are canonicalized and checked against allowed directories. ../../../etc/passwd is rejected.
• SQL injection prevention — Database query parameters are parameterized. Never concatenate agent-provided strings into SQL.
• Command injection prevention — If any tool invokes shell commands, parameters are never interpolated into command strings.

Validate Semantics

• Resource existence — Check that referenced resources exist before operating on them.
• Permission verification — Verify the requesting client has permission for the specific resource, not just the tool category.
• Idempotency markers — For mutating operations, accept and enforce idempotency keys to prevent duplicate actions from retrying agents.

Output Sanitization

What Goes Back to the Agent

• Strip credentials — Tool outputs must never contain API keys, passwords, connection strings, or tokens. Redact before returning.
• Limit output size — Cap response sizes. An agent asking for “all logs” shouldn’t receive 10GB of text.
• Sanitize external content — If the tool fetches data from external sources (web pages, databases), strip potential prompt injection payloads before returning content to the agent.
• Error messages — Don’t expose internal paths, stack traces, or infrastructure details in error responses.

Logging and Audit

What to Log

• Every tool invocation — tool name, parameters, client identity, timestamp, result status.
• Authentication attempts — successful and failed. Alert on repeated failures.
• Authorization denials — when a client tries to invoke a tool they don’t have access to.
• Rate limit hits — when a client exceeds their quota.
• Unusual patterns — tools invoked in unexpected sequences or with unusual parameters.

How to Log

• Structured format — JSON logs with consistent field names. Queryable by log aggregation tools.
• Immutable storage — Logs written to append-only storage. An attacker who compromises the MCP server shouldn’t be able to delete evidence.
• Retention policy — Keep logs for at least 90 days. Compliance may require longer.
• No sensitive data in logs — Redact tool parameters that contain credentials or PII before logging.

Network Isolation

Minimize Attack Surface

• No public endpoints — MCP servers should not be reachable from the internet unless specifically designed for it.
• Egress filtering — Restrict outbound connections to only what the MCP server needs. A filesystem MCP doesn’t need internet access.
• Separate from application network — MCP servers should run in their own network segment, not co-located with production application servers.
• Internal DNS only — MCP server hostnames should not resolve publicly.

If Public Access is Required

• API gateway — Route through a gateway that handles authentication, rate limiting, and request validation before reaching the MCP server.
• DDoS protection — Public endpoints need volumetric attack mitigation.
• WAF rules — Block known attack patterns at the edge.

Credential Management

Credentials the MCP Server Uses

• No hardcoded credentials — Cloud API keys, database passwords, and service tokens are loaded from environment variables or a secrets manager.
• Least privilege — Each credential grants the minimum permissions needed. A cloud scanning tool needs read-only access, not admin.
• Rotation — Credentials are rotated on a schedule. The MCP server handles rotation gracefully (reload without restart).
• Separate per environment — Dev, staging, and production MCP servers use different credentials. A compromised dev server can’t access production.

Credentials Agents Might Request

• Never expose raw credentials to agents — If an agent needs to access a service, the MCP server should proxy the request, not hand over the credentials.
• Scoped temporary tokens — If credential exposure is unavoidable, issue short-lived, scoped tokens (STS, OAuth with limited grants).

Update and Patch Management

• Dependency scanning — Run npm audit / pip audit / equivalent on MCP server dependencies regularly.
• Automated patching — Security patches for the MCP server runtime should be applied within 24 hours.
• Signed updates — If the MCP server pulls updates from a vendor, verify cryptographic signatures before applying.
• Rollback capability — If an update breaks functionality, you can roll back to the previous version within minutes.
• Change log review — Review what changed in each update. Don’t blindly apply updates to security-critical infrastructure.

Monitoring and Alerting

• Health checks — The MCP server exposes a health endpoint. Alert when it’s unresponsive.
• Performance metrics — Track response latency, queue depth, and error rates. Degradation may indicate attack or misconfiguration.
• Anomaly detection — Alert on unusual tool invocation patterns: new tools being called, unusual hours, spike in error rates.
• Dependency health — Monitor that downstream services (databases, cloud APIs) the MCP server depends on are reachable.

Deployment Checklist Summary

Before putting an MCP server in production:

Category	Critical Items
Auth	TLS, client identity, tool-level authz
Input	Type checking, path traversal, injection prevention
Output	Credential stripping, size limits, injection sanitization
Logging	Every invocation, structured, immutable, redacted
Network	No public exposure, egress filtering, segmented
Credentials	No hardcoding, least privilege, rotation
Updates	Signed, scanned, rollbackable
Monitoring	Health, performance, anomalies

How Kloudle’s MCP Server Implements This

Kloudle’s MCP server for cloud security scanning follows this checklist:

• Read-only tools only — no cloud modifications possible through the MCP interface
• Scoped to connected accounts — agents can only scan accounts you’ve explicitly connected
• No credential exposure — cloud credentials stay server-side; agents never see access keys
• Full audit trail — every scan invocation is logged with client identity and parameters
• Rate limited — prevents runaway scan loops

Learn About Kloudle’s Agent Tools → | MCP Security Risks Overview →