Skip to main content

Proximo

CI CodeQL Release PyPI Python 3.12+ License Apache-2.0

OpenSSF Scorecard OpenSSF Best Practices Glama score LobeHub — grade, tools, prompts

Enter the ludus ↗ · Quickstart · Setup · Trust layer · Demo · Tools · Install · Security · Docs

Named for Proximo, the lanista of Gladiator. The story is the design, joint for joint.

He armed his fighter with exactly what he needed, never more. He answered for every move in the arena. A lanista, not a jailer. The Spaniard earns his name by conduct, on the record, and the helmet comes off: truth said plainly, at cost. His last act opened the cages, holding the wooden sword of his own freedom. A tool should hope to end that well.

"Win the crowd and you will win your freedom."

The others make you pick: a read-only toy, or full keys and pray. Proximo won't. Every dangerous move is planned: the verdict, the live target and the change, before anything runs. Every move is proven: a tamper-evident record. And undoable wherever the platform gives us a primitive: a mutation captures the record it is about to change and puts it back through the vendor's own write; a risky in-container command can take a snapshot first, and refuses to run if it can't.

Trust built into the substrate, not bolted on after. Hand an AI agent the keys; keep the receipts.

Sovereign and agent-agnostic. Your metal, your token, a ledger you own. No cloud, no phone-home, no standing server unless you opt in.

What it does

Ask, in plain English: "why is ct 105 thrashing?" An AI agent pulls node and guest status, tails the logs, and (if you opened that lane) runs a diagnostic inside the container to find out.

If there's a fix, it shows you the plan before it touches anything: the verdict, the target as it stands, the exact change. Takes a snapshot first if you ask it to, and won't run if it can't. Applies. Hands you a keyed receipt of exactly what changed, with the before-state captured so it can be put back.

It does all of that with six tools, over every address the four Proxmox products publish. No wrappers, no catalog to page through, no tool per endpoint: find the address, plan it, read or call it, and prove the record. The whole surface fits a small local model's window.

That's the product: a hypervisor an AI can operate without being able to wreck it.

Read-only by default. No mutation runs on the first call: it returns its blast radius as a plan for you to see first. A tamper-evident receipt for every change.

The comparison isn't Proximo vs. the GUI. It's Proximo vs. handing an LLM your root token and hoping.

Don't take our word for any of it. Verify it yourself.

Verify in 60 seconds: three receipts, no trust required
# 1. The tool count is real. Ask the door itself, cold (=> 6).
#    (in a clone of this repo, after `uv sync`)
uv run python -c "import asyncio; from proximo.core.doors.mcp import build_server; \
print(len(asyncio.run(build_server().list_tools())))"

# 2. The container image is what the repo built. Sigstore provenance (exit 0 = verified):
gh attestation verify oci://ghcr.io/john-broadway/proximo:latest --owner john-broadway

# 3. The security posture is graded by a third party, not by us:
#    https://scorecard.dev/viewer/?uri=github.com/john-broadway/proximo

The rest is in VERIFY.md: forge a ledger byte and watch verify() refuse, grep the outbound surface for phone-home (there is none). These checks work on any tool, from any vendor. Demand them everywhere.


Proximo architecture: MCP clients (stdio and Streamable HTTP), A2A, and HTTP/OpenAPI clients all land on one governed spine, pass the six-pillar trust spine (PLAN, PROVE, UNDO, DIAGNOSE standing by default; CONSENT and CONTAIN yours to raise), sit on the Proxmox-enforced token floor, and reach four products — PVE, PBS, PMG, PDM

Every transport enters one governed dispatch and crosses the same trust spine; the token floor beneath it all is enforced by Proxmox itself.
Watch it hold in the Demo.

Quickstart

// your MCP client config (Claude Desktop / Claude Code / Cursor / …)
{
  "mcpServers": {
    "proximo": {
      "command": "uvx",
      "args": ["proximo-proxmox"],
      "timeout": 60,                                     // startup is ~3.5s; a 3s client default drops the server silently
      "env": {
        "PROXIMO_API_BASE_URL": "https://your-pve:8006/api2/json",
        "PROXIMO_TOKEN_PATH": "/path/to/token-file"   // USER@REALM!TOKENID=SECRET, by reference, never inlined
      }
    }
  }
}

Claude Code, one line:

claude mcp add proximo --env PROXIMO_API_BASE_URL=https://your-pve:8006/api2/json \
  --env PROXIMO_TOKEN_PATH=/path/to/token-file -- uvx proximo-proxmox

Or install with one click:

Install in VS Code Install in Cursor

Both prompt for the token file path; the secret never lands in client config. No token yet? uvx proximo-proxmox mint pve prints the least-privilege runbook.

Then preflight what your token can actually do (read-only):

uvx proximo-proxmox doctor

Start with a read-only token. Proximo is useful long before you grant it write. Full token-first walkthrough: docs/SETUP.md · more install paths: Install & run.

Why Proximo exists

The Proxmox MCP landscape is split. API-based servers manage nodes and VMs but structurally cannot run a command inside an LXC: the REST API has no exec endpoint. SSH-based servers can, through broad shell access with little scoping.

Proximo builds the principled whole. Both halves, one audited surface, least-privilege. Trust by construction:

Read-only inspector Full-access executor Proximo
Can mutate no, that's the safety yes yes, plan recorded first, then confirm=true
Preview before a change n/a rarely default: blast radius + live state, every mutation
Record of what happened no app logs, editable keyed hash-chained ledger, tamper-evident, on by default
Undo n/a rare snapshot-first, wherever the platform can snapshot
Command inside an LXC no broad SSH opt-in, fail-closed CTID allowlist
Products covered usually PVE usually PVE PVE + PBS + PMG + PDM, one audited plane
Verify the artifact you run varies varies signed image · PyPI provenance · SBOM · Scorecard

(The archetype columns describe the split above, not any specific project. There is no official Proxmox MCP; Proximo is a community project, standing on its own.)

The trust layer: what makes Proximo different

The spine has six pillars. Four stand by default:

Control What it does
PLAN Every mutation first returns a recorded preview: the exact change, live state, blast radius, an advisory risk rating. Nothing mutates without its plan recorded; one confirm=true call records and performs.
PROVE Keyed (HMAC-SHA256), hash-chained audit ledger; audit_verify catches edits, reordering, insertion. Pin the head off-box (expected_head) to catch truncation too: that's the strong guarantee, and it's opt-in.
UNDO One rule: every mutation with a GET twin captures the record before it runs, and the receipt carries an undo.id; the restore is the vendor's own write at the same path, with the captured record, as a governed mutation (planned, armed, receipted, itself undoable). A container command can take a snapshot first and then fail closed if it can't. Where the vendor publishes no write to put a record back (a delete, a collection, a path with no PUT) the answer is a sentence, never a guessed reverse call.
DIAGNOSE Read-only evidence battery + node health → advisory flags that surface incompleteness too, so an empty list never reads as a false clean bill.

Two are yours to raise, by design, off until their state paths exist, because both are only worth having if those paths sit outside the agent's reach. A pillar Proximo raised for you would be a pillar the agent could lower for itself:

Pillar (off until configured) What it holds
CONSENT Independent, out-of-band approval per plan: an agent (compromised, confused, or steered by injected text) cannot confirm its own mutation. Grants live in a directory only you write (PROXIMO_CONSENT_DIR), expire on a TTL, and never clear a taint.
CONTAIN The kill-switch: one trip file halts every mutation immediately, mid-incident, no redeploy and no restart. Checked fresh on every mutation; fails closed. Put the trip path where only you can write (PROXIMO_CONTAIN_TRIP_PATH).

proximo doctor reports the spine: which pillars stand, which sockets are empty, and exactly how to fill them. Four more controls ship off until configured: ARM (a mutation runs only while the served token is the write token), a FORBID/RATE ENVELOPE, TAINT (the prompt-injection mitigation), and PRINCIPAL (who-asked attribution). Scope and lease are not Proximo's any more: the write token's own ACL is the scope and its own expire is the lease, both enforced by Proxmox, and proximo mint prints the commands that make such a token. What each control defends against: SECURITY.md.

Honesty note (load-bearing): risk ratings are an advisory heuristic, not a sandbox — LOW means "no state change," not "safe," and the absence of a HIGH flag is not a safety signal. Review every change yourself. The floor beneath it all is the token you mint: Proxmox RBAC holds even if Proximo's process is fully compromised — a stronger guarantee than anything Proximo's own code provides. Scope it to exactly what you mean to grant: SECURITY.md.

Hold any tool to this, including this one: The Keys Test. Ten questions to ask before you hand an AI agent real infrastructure. Proximo's own scorecard published, partials included.

Demo

The record defends itself:

Hand-the-keys demo: three agent moves land in the keyed hash-chained ledger and audit_verify answers ok=True keyed=True; an in-place edit breaks the chain at the exact line (ok=False); a truncation that fools the forward walk is caught by the pinned head

Three agent moves land in the keyed ledger; one entry gets edited in place; audit_verify() breaks at the exact line, ok=False; the truncation a forward walk would miss is caught against the pinned head. Real code, real crypto, nothing staged, recorded on 0.30.0. Forge a byte yourself and watch the chain refuse: VERIFY.md, section 2.

Surfaces & tools: one control plane

Surface Backend For
Proxmox VE REST API + scoped token node/guest lifecycle, storage, SDN, identity, HA, firewall
Proxmox Backup Server REST API + scoped token datastores, namespaces, snapshots, sync, GC, verify, tape
Proxmox Mail Gateway Ticket auth mail flow, quarantine, filtering rules, domains, services
Proxmox Datacenter Manager API token federated fleet: reads plus governed control (power/snapshot/migrate, dry-run-first)
Container and node shell ssh → pct exec, a fixed host battery run-command-in-container, psql, log tailing, a host health read: what the API structurally can't do. Opt-in lanes, each behind its own switch and allowlist, judged like any mutation

Those backends are deliberately boring. Anyone can call them. The product is the trust layer over them.

Six tools, every address. The vendor publishes the API; Proximo serves it whole and governs each address by what it is: 1,804 published addresses across the four products, 884 reads, 785 mutations open to an armed operator each with an authored blast-radius tier, 32 opened by an operator's switch (guest agent, container and node shell), 5 on the download lane, 20 held on purpose with a sentence, 78 excluded as not JSON calls. The record is generated from the vendor's own schema and a stale copy fails the suite: docs/arena.md.

Where an operator actually starts, in the six-tool grammar:

You want to… Say Worth knowing
Find the address proximo_find "list datastores" verbs pick the method; the vendor's own words match
See the whole cluster at once proximo_read pve /cluster/resources lean rows (names, states, ids) and a total; fields=all for the vendor's rows
Find out why a container is sick proximo_read pve /nodes/{node}/lxc/{vmid} diagnose=true the battery: status, storage, failed tasks, and the shell probes if that lane is open
Power / lifecycle, any mutation proximo_plan, then proximo_call … confirm=true the plan reads the target first; nothing moves without confirm=true, an arm and a tier
Put it back proximo_call pve undo <undo.id> the captured record, written back through the vendor's own PUT
Preflight a token / config proximo doctor run this before wiring an agent
Prove the record wasn't touched audit_verify on every door, always

The six tools with typed inputs: docs/TOOLS.md · the walkthrough: docs/SETUP.md.

Install & run

The core alone, no model in the loop: the same install ships proximo-core pve GET /nodes/pve1/status (or --plan on any address: the verdict and the published schema, touching nothing). Its import closure is httpx and nothing else (measured by a test); every published address on all four products; the same arm gate, tiers and audit ledger as the MCP door. The core has its own network doors, each the 0.44 face's perimeter with the core behind it: proximo-mcp-http (MCP over streamable HTTP), proximo-http (REST, POST /tools/{name} with an OpenAPI document) and proximo-a2a (an Agent2Agent card whose skills are the six tools).

📦 0.45.0: on PyPI, GitHub, and GHCR (signed multi-arch image).

New in 0.45.0 (Proximo is the core). The 924 named wrappers are gone. Six tools reach every address PVE, PBS, PMG and PDM publish, and every call through every door passes the one seam where the six pillars run (CONSENT once you set its directory). Coming from 0.44: a wrapper you called by name (pve_backup, pve_doctor) is now proximo_find for its address, then proximo_plan and proximo_call on it. A set PROXIMO_SCOPE_PATH, or a PROXIMO_ARM_TTL above 0, stops every door at start and names what to set instead: the write token's own ACL and expire bound it now (proximo-core mint). The ledger is keyed, always. What 0.44 had that 0.45 does not is listed in CHANGELOG.md.

Recent: 0.44.2 gave a restored guest its own MAC address; 0.44.1 moved our pinned PyJWT and urllib3 past sixteen advisories. See SECURITY.md for what each control honestly holds.

Proximo runs on your machine, on demand. No daemon, no open port.

uvx proximo-proxmox            # zero-install run (PyPI package: proximo-proxmox; command stays `proximo`)
# or: pip install proximo-proxmox            the MCP core
# or: pip install "proximo-proxmox[a2a]"     + the optional A2A face
# or: pip install "proximo-proxmox[http]"    + the optional HTTP/OpenAPI face
# or: pip install "proximo-proxmox[mcp-http]" + the optional MCP-over-streamable-HTTP face
# or, from source:  git clone https://github.com/john-broadway/proximo.git && cd proximo && uv pip install -e .

Wire it into your MCP client as the command proximo, with the PROXIMO_* env vars; see packaging/proximo.env.example.

Docker (GHCR): docker run -i --rm … ghcr.io/john-broadway/proximo:latest. Multi-arch, SBOM, sigstore-signed provenance (gh attestation verify oci://ghcr.io/john-broadway/proximo --owner john-broadway). Mirrored to Docker Hub (docker.io/jebroadway/proximo, identical digest); GHCR stays the signed primary.

Safe by default: API-only out of the box. The two near-root edges are opt-in and say so loudly: LXC exec (PROXIMO_ENABLE_EXEC=1, near-root on the host) and the qemu-guest-agent edge (PROXIMO_ENABLE_AGENT=1, near-root in a guest). Each is scoped by its own fail-closed allowlist.

Smallest footprint by construction: the door advertises six schemas and nothing else. Measured on this release, tools/list over stdio is 5,544 bytes on the wire (about 1,400 tokens at the four-bytes-a-token heuristic; 1,568 as a stock 1.5B's chat template renders it, counted by its server), and that is the whole cost of connecting; the estate behind it is searched, not loaded. There is nothing to scope: a plane you have not configured is simply not reachable, a plane you have is reachable whole, and the gates do not shrink with the doorway. PLAN and PROVE apply to every address however small the model.

The network faces (experimental, opt-in): proximo-a2a speaks Agent2Agent. proximo-http serves plain HTTP + generated /openapi.json for no-code clients. proximo-mcp-http serves MCP itself over Streamable HTTP (the SDK's native transport) for networked MCP clients: no third-party stdio→HTTP bridge, so the perimeter stays Proximo's. LXC on your Proxmox host, one line: on the PVE node as root, bash -c "$(curl -fsSL https://raw.githubusercontent.com/john-broadway/proximo/main/packaging/lxc/ct/proximo.sh)" builds a Debian 13 container running proximo-mcp-http with Proximo from PyPI, its own service user, and a minted bearer on port 41243. Community-scripts engine (MIT) pointed at Proximo's own tree, their telemetry off; the same line inside the container updates it. Details: docs/SETUP.md, files: packaging/lxc/.

All three serve the full surface through the same spine as MCP. No second code path; trust spine and token scope inherited. Fail-closed perimeter: loopback, bearer-token required off-localhost, DNS-rebind and CSRF defended. Details: SECURITY.md.

At scale

One container is the demo. A cluster is the point.

  • The whole cluster in one call. proximo_read pve /cluster/resources: every VM, node, storage pool, SDN object, as lean rows with a total.
  • One tamper-evident record across every node. "Show me every state-changing action this month, and prove the log wasn't touched" becomes a query you can actually answer. No human at the CLI walks away with that.
  • Where the time comes back. On one node a senior at the CLI is faster, and that's fine. Across a dozen nodes and hundreds of guests, a bounded, audited agent earns its keep.

Many boxes, one Proximo: register remotes in a TOML file (secrets by reference, never inlined), point PROXIMO_TARGETS at it, aim a call with target="edge-pve" (the shell door: --target edge-pve). The target travels with the call. PLAN and EXECUTE hit the same box, the ledger records which, cross-plane calls error. Config shape: packaging/targets.example.toml.

Status: the arena record

  • 🩸 0.45.0: Proximo is the core: six tools over every address. The 924 wrappers, their config, memory, wiki and runbook prompts are cut; what is left is one engine with the six pillars at its one seam, served by every door (stdio MCP, MCP over HTTP, REST, A2A, the proximo-core shell). SCOPE and LEASE moved into the vendor's own token (mint); the ledger is keyed, always; proximo-core doctor reads the gate back. Every round had an adversarial lens, each folded; pyright joins ruff as a blocking gate in the release script and the internal CI. A stock 1.5B model drove the door in a 4,096-token window and did not finish its task, said plainly below. Every release before it (every pillar, every redteam, every fix) lives in CHANGELOG.md.

The numbers, honestly: six tools over 1,804 published addresses, governed by what each address is (its method decides read or write, total by construction; the blast-radius tier is the one human-authored column, and an untiered mutation is refused, armed or not). 1,598 in-process tests (ruff + pyright clean) pin the engine, the six pillars, the doors and the records, and a gate round neuters each pillar's gate one at a time and asks the suite to notice. This workspace administers its own Proxmox estate through Proximo daily (dogfood).

Proven live (not mocks): the governed path end to end against a real PVE 9 node through this door, plans reading the live target, receipts on the keyed chain, before-state captures and their restore. The 0.44 wrappers' live record (a 3-node cluster, PBS, PMG, PDM, a real cross-datacenter move) stays in CHANGELOG.md where it was earned; it is not re-claimed for the core. Not yet proven — said plainly: a small local model finishing a whole task through this door. Measured and driven on this release: a stock 1.5B behind llama.cpp with a 4,096-token context the server enforces, against a real PVE node, read-only. Its calls landed and the door's refusals named the fix each time (an invented field, the real ones listed); the prompt peaked at 3,074 tokens; the model did not finish the task, it invented a number. The window holds; a 1.5B does not. Hardware-watchdog fencing (needs physical iTCO/IPMI), and behavior at production scale. The 20 held addresses are never fired: refused by sentence, by design, not a gap.

Documentation

Document What it answers
Setup Token-first walkthrough: mint a least-privilege token, verify it, widen deliberately.
The Junction Why Proximo exists: two roots on two planes, and the door that governs both lanes.
Verify Every trust claim paired with the command that proves it. Run them cold.
Security The two-deployment trust model, every control, what each honestly holds, reporting.
Threat model What Proximo defends against, what it doesn't, where the boundaries sit.
Tools The six tools, typed inputs: find, plan, read, call, and the two ledger reads.
Agents The page written for the agent itself: Proximo's sharp edges, stated first.
Known issues What's broken or odd right now, said plainly.
Contributing Dev setup, the CI gates, what a PR is expected to keep intact.
Changelog Every release, every redteam, every fix: the full build history.

License

Apache-2.0, chosen for the patent grant that suits infrastructure tooling. Full text in LICENSE.

Credits

Built by John Broadway with Claude and Maude: a human-AI partnership, and the first thing we made on this box to give away to the world. Claude Opus 4.8 built the trust pillars and the original tool surface and has carried the work since; Claude Fable 5 ran the 101-agent release audit and the first publish. Every commit carries its co-author trailer.


"Are you not entertained?" Stars, issues, and sparring partners welcome. Strength and honor. ⚔️

Metadata

Release files for proximo-proxmox 0.45.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for proximo-proxmox 0.45.0
File Size Uploaded Provenance
proximo_proxmox-0.45.0.tar.gz 548.7 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for proximo-proxmox 0.45.0
File Interpreter ABI Platform
proximo_proxmox-0.45.0-py3-none-any.whl Python 3 none any Details

Total release size: 948.2 kB

Release files / proximo_proxmox-0.45.0.tar.gz

Download URL proximo_proxmox-0.45.0.tar.gz
Size 548.7 kB
Tags Source
SHA-256 checksum
How to use checksums
530a014625a4dc63d5983e7fe803095a2df0a90b83949f050041131310be0fdf
BLAKE2b-256 checksum
How to use checksums
abb608ba881ca6469d82985fe8d74806429fcb46c97183fc007ad5bba6042563
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 19, 2026.

Transparency log

Release files / proximo_proxmox-0.45.0-py3-none-any.whl

Download URL proximo_proxmox-0.45.0-py3-none-any.whl
Size 399.5 kB
Tags Python 3
SHA-256 checksum
How to use checksums
3bb78672e3c7711896a17e0372748ba035a6df50a5d88d88002414aedaf9c71d
BLAKE2b-256 checksum
How to use checksums
bc24d9ad58d241d28b928af068cee945a07fb8891af1966ef43a07ef2b1b22f1
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 19, 2026.

Transparency log

Security for proximo-proxmox 0.45.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for proximo_proxmox-0.45.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 19, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

Release history Release notifications | RSS feed

This release

0.45.0 This release

2 release files Full provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page