MCP design and MCP security are the same discipline because every exposed tool, input, description, and response adds an attack surface.
2
Production MCP requires remote streamable HTTP, authentication, token management, TLS, CORS configuration, rate limiting, and controls that local standard IO setups do not need.
3
Dynamic Client Registration helps clients connect without manual setup, while Client ID Metadata Documents provide a stronger way to verify client identity and bind redirect URIs.
Summary
Tun Shwe and Jeremy Frenay explain why an MCP server that works on a developer laptop can fail when shared across an organization. They connect agent-oriented design directly to security: agents enumerate every tool, resend conversation history during retries, and load returned data into a limited context window. The speakers propose five design principles: expose fewer outcome-focused tools, constrain input schemas, write defensive documentation, return only necessary data, and limit permissions and blast radius. They then describe the move from local standard IO to remote streamable HTTP, where OAuth, token handling, TLS, CORS, and rate limiting become necessary. Jeremy compares long-lived API keys with OAuth 2.1, Dynamic Client Registration, and Client ID Metadata Documents. The talk ends with enterprise controls beyond OAuth, including tool-level permissions, data masking, interaction logs, and end-to-end tracing.
Agent-oriented interfaces create security problems through discovery, iteration, and context
Agents enumerate every tool and read every description whenever they connect, unlike a human who usually reads API documentation once. Those descriptions can contain hidden instructions that cause tool poisoning, so every additional tool increases the injection surface. Agents also resend the full conversation history when they retry, including sensitive data returned by earlier calls. Their context window creates another risk: unfiltered results can place PII, credentials, and internal system details in front of a model that may be tricked into exfiltrating them. Tun Shwe compares this to finding a needle in a haystack where some of the hay may be poisoned.
Good MCP design reduces security risk before authentication is added
Tun Shwe presents five principles for secure agentic design. First, combine fine-grained operations into outcome-focused tools, so checking an order does not require exposing user deletion. This gives the system fewer permission checks and audit points. Second, constrain inputs with primitives, enums, and non-nested dictionaries, using libraries such as Pydantic when useful. Third, write complete and unambiguous tool documentation to resist poisoned descriptions. Fourth, return only the data needed for the immediate task. Fifth, scope permissions at the tool and resource level, use read-only annotations, and turn suitable read-only tools into MCP resources.
Local standard IO hides the production security cliff
A local MCP server using standard IO runs as a process on one machine, with one user and no network exposure. That setup can avoid authentication because the MCP host communicates directly with the process. Production changes the shape of the system. Streamable HTTP allows remote deployment, several clients, horizontal scaling, and centralized governance. It also brings OAuth, token management, CORS configuration, TLS, rate limiting, and other concerns at once. The speakers describe this as a security cliff because there is no partial production mode. They cite Stacklok tests in which 20 of 22 requests failed with 20 simultaneous connections on standard IO transport.
Long-lived API keys leave remote MCP clients broadly authorized
Jeremy Frenay contrasts local and remote API-key setups with OAuth. A key is often placed in a client configuration or environment variable, passed to an upstream service, rarely rotated, and left unscoped to the actions an agent should perform. It may not be verified by the MCP server. Passing it through can create a confused deputy vulnerability, while mapping it to another shared credential gives many users the same powerful authorization. Such a credential is harder to revoke for one user and compromises everyone if it leaks. Jeremy says the ecosystem is moving toward short-lived, scoped OAuth 2.1 tokens and token exchange for least-privilege access.
Dynamic Client Registration removes manual setup but cannot verify identity well
MCP clients can appear at runtime, including Cloud Desktop, Cursor, VS Code, command-line tools, and other agents. Traditional OAuth registration assumes a small set of known clients, which does not fit an unbounded collection of clients and servers. Dynamic Client Registration lets a client discover the protected MCP server, find the authorization server, register itself, and receive a client ID. The flow uses PKCE, user login through an identity provider, consent for scopes, and an access token. Jeremy points out several weaknesses: each connection can create a new registration, registrations are not portable across devices, attackers can post to the registration endpoint, and a malicious client can claim to be another product.
Client ID Metadata Documents bind client identity to a public URL
With Client ID Metadata Documents, the client owner publishes its client ID and metadata at a public URL. During authorization, the authorization server fetches that document instead of relying on arbitrary self-asserted registration data. The client still uses discovery and PKCE, then the authorization server authenticates the user, presents consent, and issues tokens. This approach avoids a growing registration database. Controlling a domain such as https://cloud.ai provides a stronger identity signal than being able to post to a registration endpoint. Metadata can bind redirect URIs to the client, and the authorization server can selectively allow or deny clients. Jeremy says CIMD is the preferred approach since November 2025.
OAuth scopes alone apply at the session level, so enterprise authorization must also restrict individual tools and resources. Data masking can remove or obscure fields such as email addresses, phone numbers, and national insurance numbers before an agent receives them. Each interaction should record which agent called which tool, the parameters supplied, and the data returned. The speakers connect this detail to compliance expectations such as the EU AI Act. They also require end-to-end observation across request validation, execution, data retrieval, and response generation. Jeremy compares this tracing to distributed-systems observability, applied to autonomous decisions.
"If you cannot trace what an agent did end to end, you cannot govern it."24:05
Who should watch
You are moving an MCP server from a local standard IO process to a shared remote service and need to understand the security work that arrives with that change.
Your MCP tools accept broad inputs or return whole upstream payloads, and you want concrete design rules for reducing injection and data-exposure risks.
You are implementing OAuth for runtime-discovered MCP clients and need to compare Dynamic Client Registration with Client ID Metadata Documents.
