MCP in Practice — Part 8: Your MCP Server Is Authenticated. It Is Not Safe Yet.

Part 8 of the MCP in Practice Series · Back: Part 7 — MCP Transport and Auth in Practice Your MCP server is deployed, authenticated, and serving your team. Transport is encrypted. Tokens are validated. The authorization server is external. In a normal API setup, this would feel close to done. But MCP is not a normal API. The model reads your tool descriptions and can rely on them when deciding what to do. That reliance creates a security problem that is less common in traditional web services. This article covers the security risks that are specific to MCP — the ones that remain even after transport and auth are set up correctly. This is not a general web-security article. It assumes you already have TLS, auth, and token validation in place. The risks here are the ones that come with the protocol itself. Why MCP Security Is Different The outer layers — TLS and auth — protect the transport and verify identity. The inner risks — tool poisoning, rug pulls, cross-server shadowing — live in