A misdesigned MCP is a map you hand to whoever finds it first

This week Wiz reported active exploitation of an auth flaw in MCP servers. Attackers getting into connected tools and services. It didn't surprise me: the real problem is that most people treat MCP security as something you add at the end, after it already works.

The same week I was designing the architecture for a client's MCP, giving their sales team access to operational data. None of the decisions were reactive. They were there before I wrote the first tool:

• The public-facing process runs with a database user that has no write permissions on anything sensitive. The database enforces security, not an if someone deletes in the next refactor.
• Nobody gets in anonymous. Everyone has their own token via magic link, with a real audit trail and revocation.
• A tool that checks an order's status also asks for the email or tax ID tied to it. Without that, anyone can iterate IDs and walk away with the client's entire order map.

None of this is an original idea. It's minimum privilege and real identity, the usual stuff, applied to a new protocol that an agent can invoke on its own, with nobody watching every call.

I've been saying since last year that MCP is the most underrated technology of this cycle: tool agility, per-user permissions, everything connected without rebuilding from scratch. What doesn't get discussed enough is that the same power, badly designed, is a complete map of what can happen if someone else finds it first.

A misdesigned MCP isn't a server with a bug. It's a complete map of your operation, waiting for someone else to find it first.

My bet: by 2027 MCP security will be a contract line item, not a technical detail. The companies thinking about this now will charge differently for it.