Why MCP Is a Trust-Boundary Problem

MCP is often introduced as a cleaner interface for tool access. That is true, but it understates the real design problem. Once agents can discover and invoke tools, the security question shifts from whether the connector works to whether the access model is coherent.

Trust boundaries, not just connectors

Every MCP integration creates a trust boundary. Who is the agent acting as? Which scopes are attached? What data can be read? What actions can be taken? What must remain approval-gated?

Prompt injection makes this more serious, not less. When instructions and data live in the same context window, the runtime needs stronger boundaries than simple tool availability. It needs scoped identity, constrained actions, and clear separation between observation and execution.

A useful mental model is to treat MCP like internal platform infrastructure, not a plugin directory. That means authentication, authorization, input controls, output validation, audit logging, and revocation paths all matter.

Where teams get this wrong

The failure mode is not that an agent cannot connect to a tool. The failure mode is that it connects too broadly, moves too much context, or takes action with a level of authority no human would have approved in that moment.

That is why I think of MCP primarily as a trust-boundary problem. The connector is the easy part. The security model is the actual product.