MCP and Firecracker

Widespread adoption of MCP seems to be happening. There are already thousands of MCP servers available for download and easy incorporation into your local workflow. And there is no security mechanism in the protocol. What a perfect setup for security disaster!

An MCP client running as a local user has the privileges of that user. The damage it can cause is limited only by constraints on the user account. The server may run locally as well. Making it easy to download and run MCP clients and servers absent security partitioning means making it easy to run foreign code locally. All bets are off.

At first blush I thought it was a mistake that MCP did not incorporate security directly. But my view has changed. Making security a direct requirement in the protocol would add a lot of complexity. It would risk lock-in to an inflexible or suboptimal approach. It might confuse the questions of managing permissions grants with the imposition of runtime restrictions.

One way to handle runtime restrictions is to isolate each client and local server in its own Firecracker virtual machine. An AWS Lambda runs in a Firecracker VM. The idea is simply to run a local lambda for each client and local server.

Applying this approach locally doesn’t address the questions of initial registration of an MCP client or server, or managing permissions grants. It provides no bells and whistles like AWS Lambda offers. But it does address the most fundamental security problem with local MCP processing.

Who is working on this? Searching for “mcp firecracker” yields precious few relevant results.