Securing MCP Tool Servers: Transport Auth, Gateways, and Policy Enforcement

MCP servers are API endpoints that AI agents call with full trust. Securing them requires the same rigor you would apply to any production API, plus additional controls specific to the LLM-agent threat model.

Transport Authentication

For stdio transport: The server runs as a child process of the client. Authentication is implicit through process-level access control. Restrict who can spawn the process. Use OS-level permissions to limit what the process can access.

For SSE/HTTP transport: Implement bearer token or OAuth 2.0 authentication on every endpoint. Do not rely on network-level controls (firewalls, VPNs) as the sole authentication layer. Tokens should be scoped: read-only tools get read-only tokens.

Rotate tokens regularly. Log authentication failures. Implement rate limiting per authenticated identity.

Gateway Patterns

A gateway sits between the agent and MCP servers. All tool calls route through it.

What the gateway enforces:

• Identity verification: confirm the agent and user are who they claim to be
• Tool allowlists: only permitted tools are callable by each role
• Parameter validation: reject parameters outside expected ranges
• Content scanning: check tool descriptions and responses for injection
• Rate limiting: prevent runaway agents from flooding servers
• Audit logging: record every tool call with full context

The gateway is the single enforcement point. Individual MCP servers do not need to implement security logic if the gateway handles it. This simplifies server development and centralizes policy management.

Authensor's control plane functions as an MCP gateway, providing all of these controls through a policy engine configured in YAML.

Policy-Based Authorization

Static allowlists are a starting point. Dynamic policy evaluation is better. A policy engine can evaluate each tool call against rules that consider:

• The user's role and permissions
• The specific tool and its parameters
• The conversation context and recent actions
• Time-of-day restrictions and operational windows
• Cumulative risk scores for the session

Example policy in YAML:

rules:
  - tool: "delete_record"
    require_approval: true
    allowed_roles: ["admin"]
    max_calls_per_session: 5
  - tool: "read_file"
    allowed_roles: ["admin", "analyst"]
    parameter_constraints:
      path: { pattern: "^/data/public/" }

This is deterministic and auditable. The policy engine evaluates rules synchronously without calling an LLM, so there is no prompt injection risk in the authorization layer itself.

Server-Side Hardening

Even behind a gateway, MCP servers should:

• Validate all input parameters against their JSON Schema definitions
• Run with minimum required permissions
• Avoid executing user-supplied strings as code or shell commands
• Return structured data rather than free-text where possible (reduces response injection surface)
• Log internal operations for forensic analysis

Defense in depth means every layer contributes. The gateway catches most threats, but a hardened server reduces the impact of gateway bypass.