Independent security review for AI-agent products and Qubes-isolated infrastructure.
Excerpt from a Qubes policy gate the practice ships and reviews against.
qmcp.SpawnAIManagedQube * mcp-control @adminvm allow target=dom0
qmcp.SpawnAIManagedQube * @anyvm @adminvm deny
qmcp.LifecycleAIManaged * mcp-control @tag:ai-managed allow
qmcp.LifecycleAIManaged * @anyvm @anyvm deny
qmcp.AttachDeviceAIManaged * mcp-control @tag:ai-managed allow
qmcp.AttachDeviceAIManaged * @anyvm @anyvm denyA trust boundary is only worth what you can prove about it. Most security reviews of AI-agent products stop at the protocol — checking that tool descriptions are sanitised, that prompts are pinned, that human-in-the-loop confirmations fire. I work a layer below that: where the trust boundary actually lives, what the agent can name, and what gets foreclosed when the model is wrong.
The practice serves teams shipping agentic products, infrastructure where AI is given real capabilities, and individuals whose work requires a workstation that resists compromise by design rather than by hygiene. Engagements are direct, written, and contained — two weeks, one operator, one report.
Trust-boundary review of an MCP server, agent client, or autonomous-agent product. The deliverable answers eight questions in writing — where the boundary is drawn, what the model can name, how denial differs from absence, what the egress surface allows, where credentials originate, what disposable state looks like, what is loggable and by whom, and what the failure mode is when the model is wrong. Each answered with primary-source evidence from the product, not interview transcripts.
For teams giving AI agents real capabilities — provisioning, code execution, network reach — and recognising that protocol-layer defence is insufficient. Design and implementation of structural isolation: tag-scoped trust boundaries, dom0-mediated RPC surfaces, default-deny egress, ephemeral compute as the default disposition.
For journalists, lawyers, researchers, and individuals whose threat model requires compartmentalised computing. A specified Qubes installation with template hygiene, per-domain network policy, disposable browsing, and an operating doctrine the client can sustain after handover. Not a turnkey product. A working system you understand.
A FastMCP server exposing a tag-scoped Qubes Admin API sandbox. Autonomous agents are given real capability — 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. Six stages tested.
An argument that protocol-layer wrappers are necessary but not sufficient against line-jumping — and what an audit of an MCP-using product should be checking instead. With a concrete qrexec policy and an eight-point checklist.
Design notes and open questions on tag-scoped Admin API access with dom0-mediated trust boundaries. Posted for review by the Qubes engineering community.
Direct enquiry is preferred. Please include a one-paragraph description of the product or environment, the question you want answered, and any constraint on timing.