# I didn't trust an AI with my Proxmox cluster — so I built one that can't surprise me > Source: > Published: 2026-06-19 21:00:43+00:00 I wanted an AI agent that could actually *run* my Proxmox cluster — create VMs, fix storage, tail logs inside a container — not just read it back to me. Then I pictured it deleting a storage pool and learning, at the exact second I did, which VMs just lost their boot disks. That image is why I never wired one up. So I built the version I'd actually trust: **Proximo**, an open-source (Apache-2.0) Proxmox MCP + A2A server. The whole design goal is one sentence — *the AI has to show me what it's about to do before it does it, and I keep the receipts.* Go looking for a Proxmox MCP server today and you find two shapes: a **read-mostly "safe inspector"** (the most-starred one is exactly this — a handful of read tools, popular *because* it doesn't hold the knives), or a **feature-rich mutator** you trust on faith. I wanted the third thing — full management I could point at a hypervisor I care about, with trust built into the substrate instead of bolted onto the door. Every tool inherits these; they aren't per-tool flags you can forget to set: ``` $ (dry-run) pve_storage_delete storage=local-zfs PLAN — RISK_HIGH affected (cluster-wide): - vm/104 won't-boot (boot disk scsi0 on local-zfs) - vm/210 won't-boot (only copy of scsi0) - ct/301 degraded (mp1 data volume on local-zfs) recorded to ledger: chain ok (#1438) -> you cannot mutate without this plan existing first ``` In 0.6.0 that blast-radius reasoning spans the destructive surface — storage, disk-move, firewall rules (reach + lockout), network-apply, guest-destroy, ACL changes, migrations. Proximo is **API-only out of the box** — the hypervisor itself is never touched; management goes over the Proxmox REST API with a scoped token. The one genuinely sharp edge is running a command *inside* an LXC: the REST API has no container-exec endpoint at all (it lives in `lxc-attach` ), so most API-based servers structurally can't do it. Proximo can — over your existing ssh — but it's **opt-in** (`PROXIMO_ENABLE_EXEC=1` ), gated by a fail-closed CTID allowlist, and it says plainly that it grants near-root. The token is never read or logged. I'd rather you trust the project than the marketing: `LOW` means "no state change," not "safe."`proxxx` (a Rust cockpit with a pre-flight risk gate, an HMAC-keyed audit chain, and Telegram human-in-the-loop) and RekklesNA's ProxmoxMCP-Plus (command policy + approval tokens) both have real trust mechanisms. Proximo's specific bet is trust There's a tailwind that isn't just my opinion: the **OWASP MCP Top 10** now lists "Lack of Audit and Telemetry," and the official MCP security guidance explicitly names "blast radius" and "irrecoverable data loss on the host." PROVE is that recognized need, built; PLAN and UNDO go a step *beyond* what the spec has codified — ahead of the standard, not blessed by it. The direction, the design calls, and the trust model are mine — but I didn't build it alone, and I'd rather say so than have you wonder. It's an open human+AI partnership: **Claude** (Anthropic's model) did much of the actual implementation, and **Maude** (my own Claude-helper plugin) is the gates and second-lens that watched the work. Every commit carries its co-author trailer. For a tool whose whole pitch is transparency, telling you exactly how it was made felt like part of the deal. ``` uvx proximo-proxmox # or: pip install proximo-proxmox # A2A face: pip install 'proximo-proxmox[a2a]' && proximo-a2a ``` Wire it into your MCP client (Claude Desktop/Code, Cursor, …) as the `proximo` command with `PROXIMO_*` env vars. It's early, and I'd genuinely rather find the holes now than after someone trusts it with a real cluster. The blast-radius logic, the trust model, whether the honesty holds up — tear it apart in the comments or in an issue.