Trust boundaries below the protocol — a Qubes-isolated MCP server for review

[alex-schose]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

The MCP threat model has a gap that protocol-layer hardening (wrappers like mcp-context-protector, signed-config pinning) doesn't categorically close. Tool descriptions returned by tools/list become injection vectors before any human-in-the-loop confirmation; the client and server live in the same trust domain by protocol design.

Wrappers help. They can't change the fact that everything the server emits is in scope for the model — side channels in tool names, error messages, response timing, the ordering of fields. The protocol has too many side channels for sanitization to be exhaustive.

I've been building a structural-isolation answer: a FastMCP server that runs inside a dedicated Qubes qube (mcp-control) and exposes a tag-scoped subset of the Qubes Admin API to agents through dom0-mediated wrappers. Agents get real capabilities — spawning qubes, running commands, attaching devices, networking through a controlled egress — while the trust boundary is enforced in dom0 by invariant-checking wrappers rather than trusted to the agent. A "line jumping" payload that survives any wrapper still cannot reach state outside the tag-scoped surface, because the surface is structurally invisible to it.

Repo: https://github.com/alex-schose/qubes-mcp (MIT, stages A through F2 tested on Qubes R4.3-era; eleven dom0-side qmcp.* RPC services in total)

Writeup with the broader case: https://alexschose.com/writing/mcp-trust-boundaries-belong-below-the-protocol.html — includes the qrexec policy excerpt + an 8-point checklist for auditing MCP-using products at this layer.

Specifically asking the community for pushback on:

1. The categorical claim — does isolation-below-protocol foreclose meaningful classes of line-jumping payload that wrappers can't, or am I overstating?
2. The 8-point audit checklist — what questions would you add for a real-world MCP server audit?
3. Implementation specifics — qrexec policy idiom, single-egress chokepoint design, what existence-oracle leaks I might be missing.

Not a launch post; not pitching consulting. Posting here because this Discussions audience is the people building the servers I'm arguing about. Serious review welcome.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other