Your Insecure MCP Server Won't Survive Production — Tun Shwe, Lenses

Tun Shwe (Staff AI Engineer) and Jeremy Frenay (AI Engineer) from Lenses.io present a comprehensive framework for hardening MCP (Model Context Protocol) servers against the security vulnerabilities that emerge when moving from local development to enterprise production. The talk opens with a core thesis: poor MCP design and poor MCP security are the same discipline — fixing one without the other is insufficient.

Shwe begins by framing agents as fundamentally different from human API consumers across three dimensions: discovery (agents enumerate every tool description on every connection, creating token costs and tool-poisoning surfaces), iteration (agents broadcast full conversation history on retries, risking data leakage), and context (agents work within a finite token window, roughly 200,000 tokens, making context oversharing equivalent to handing sensitive data directly to an attacker). Each dimension is mapped to entries in OWASP's MCP Top 10, specifically tool poisoning (number 3) and context injection/oversharing (number 10).

From these threat vectors, Shwe derives five principles for secure MCP design. First, shrink the attack surface by design: consolidate fine-grained API operations into single coarse-grained tool calls that produce a defined outcome, yielding one permission check and one audit log entry per operation. Second, constrain inputs at the schema level: accept only top-level primitives (enums, flat dictionaries) and use typing libraries like Pydantic to reject free-form nested payloads, eliminating the root cause of command injection. Third, treat documentation as a defensive layer: complete, unambiguous tool descriptions crowd out the space that poisoned neighboring MCP server descriptions would try to fill. Fourth, return only what the agent needs: strip payloads to the minimum, since any PII, credentials, or internal identifiers sitting in the context window are one prompt injection away from exfiltration. Fifth, minimize blast radius: scope permissions at the tool and resource level rather than the session level, and use MCP's read-only annotation or convert read-only tools into MCP resources to enforce boundaries.

The talk then addresses the production deployment gap. Standard IO transport — used in local single-user setups — collapses under concurrency: Stack Overflow load tests showed 20 out of 22 requests failing with just 20 simultaneous connections. Production requires streamable HTTP transport, which enables remote deployment, horizontal scaling, and centralized governance, but introduces OAuth, token management, CORS, TLS, and rate limiting all at once.

Frenay covers two OAuth 2.1 authorization architectures for remote MCP. The first is Dynamic Client Registration (DCR), in which clients self-register at a /register endpoint to receive a fresh client ID, then proceed through PKCE-based authorization (RFC 7636), a /token exchange for a JSON Web Token access token, and ultimately RFC 8693 token exchange so the MCP server can obtain a scoped session token for the upstream API. DCR solves pre-registration overhead but has critical flaws: registrations are not portable across devices, it is vulnerable to phishing since any caller can hit /register and claim any identity, and the server must trust self-asserted metadata.

The preferred alternative since November 2025 is CIMD (Client ID Metadata Document). Here the client owner exposes their client ID and metadata at a public HTTPS URL (e.g., https://claude.ai). During /authorize the client passes this URL as its ID; the authorization server fetches and validates the document, binding registration to provable DNS control rather than self-assertion. This eliminates the growing database of client registrations, makes redirect URI hijacking harder, and allows the authorization server to selectively allow or deny clients by URL.

Frenay closes by noting that OAuth scopes alone are insufficient for enterprise grade — organizations additionally need tool-level RBAC (not just session-level scoping), PII data masking before agent context is populated, full audit logging of which agent called which tool with which parameters and what data was returned (required for EU AI Act compliance), and end-to-end distributed tracing of the complete request lifecycle to govern autonomous decision-making. The session's open-source Lenses MCP server (github.com/lensesio/lenses-mcp) is offered as a reference implementation of these principles.