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

Key Concepts

• MCP (Model Context Protocol): An open standard for connecting AI agents to data sources and tools.
• Tool Poisoning: A security vulnerability where malicious instructions are embedded in tool descriptions to manipulate AI behavior.
• Context Injection/Oversharing: The risk of exposing sensitive data (PII, credentials) to an AI agent, which can then be exfiltrated via prompt injection.
• Confused Deputy Vulnerability: A scenario where an MCP server performs unauthorized actions because it trusts a client’s request without proper validation.
• DCR (Dynamic Client Registration): An OAuth flow allowing clients to register with an authorization server at runtime.
• CIMD (Client ID Metadata Document): A secure method for clients to self-identify using a public URL, replacing the vulnerabilities of standard DCR.
• PKCE (Proof Key for Code Exchange): A security extension for OAuth 2.0 to prevent authorization code interception attacks.
• Token Exchange (RFC 8693): A mechanism to exchange a delegation token for a session-specific token to achieve least-privilege access.

1. Designing Robust MCP Servers

The speakers argue that poor design and poor security are inextricably linked. They identify three dimensions where agents differ from humans, each carrying a "security shadow":

• Discovery: Unlike humans who read docs once, agents enumerate every tool on every connection. Security Shadow: Every tool description is a potential surface for tool poisoning.
• Iteration: Agents send full conversation histories with every retry. Security Shadow: Sensitive data is repeatedly broadcast, increasing the risk of leakage.
• Context: Agents have limited token windows (e.g., 200k tokens). Security Shadow: Dumping unfiltered data into this window creates a high risk of context injection and oversharing.

Five Principles for Secure Design:

1. Shrink the Attack Surface: Use coarse-grained operations (e.g., "check order") rather than fine-grained ones (e.g., "delete user").
2. Constrain Inputs: Use strict schemas (e.g., Pydantic) to reject free-form nested payloads and prevent command injection.
3. Defensive Documentation: Write unambiguous, complete tool descriptions to "crowd out" malicious instructions from neighboring servers.
4. Minimize Data Return: Strip payloads to the absolute minimum required for the task.
5. Minimize Blast Radius: Scope permissions at the tool/resource level, not the session level. Use read-only annotations.

2. Transitioning to Production

The speakers highlight the "Security Cliff" when moving from local stdio (Standard IO) to remote HTTP transport.

• The Problem: stdio is a "walled garden" suitable for single-player development but fails under concurrency.
• The Reality: Production requires OAuth, TLS, rate limiting, and CORS. There is no "halfway house"—teams must implement full enterprise-grade security to scale.

3. Enterprise-Grade Authorization Frameworks

The session details the evolution of authorization for MCP:

• Static API Keys: The current standard for many, but inherently insecure. Keys are long-lived, unscoped, and often shared, leading to "confused deputy" vulnerabilities.
• Dynamic Client Registration (DCR): Allows clients to register at runtime. While it solves the pre-registration bottleneck, it is vulnerable to phishing and identity spoofing.
• CIMD (The Preferred Approach): Introduced in November 2025, this method requires clients to expose their metadata at a public URL. The authorization server fetches this metadata to verify the client, ensuring that the client owner actually controls the domain.

The Secure Flow (CIMD + PKCE):

1. Discovery: Client hits the MCP server, receives a 401 and metadata URL.
2. Authorization: Client uses PKCE to generate a code challenge and sends it to the authorization server along with its unique URL ID.
3. Authentication: User logs in via an Identity Provider (SSO) and grants specific scopes.
4. Token Issuance: The server mints a delegation token.
5. Token Exchange: The MCP server exchanges the delegation token for a short-lived, scoped session token (RFC 8693) to perform the final API call.

4. Governance and Observability

To meet standards like the EU AI Act, the speakers emphasize:

• Role-Based Access Control (RBAC): Scoping permissions at the individual tool level.
• Data Masking: Redacting PII (emails, national insurance numbers) before it reaches the agent.
• End-to-End Tracing: Logging the full lifecycle of an interaction—from client request validation to tool execution and final response—to ensure auditability of autonomous decisions.

Synthesis

The core takeaway is that security is not an add-on for MCP servers; it is a design requirement. Developers must move away from static, long-lived credentials toward dynamic, scoped, and verifiable identity flows like CIMD. By treating MCP design as a product engineering discipline—focusing on minimal exposure, strict input validation, and full observability—organizations can safely scale agentic AI systems.