Security Model

Security Model

The honest version. Read The Trust Spine first for the two-layer framing; this page is the detail, including what Proximo is not.

Controls & defaults

Every control ships either on by default or fully inert until its env var is set — there's no partial-on state. Don't assume a name here is protecting you unless you've configured it.

Control	Defends against	Default	Turn on with
PLAN	A mutation landing with no preview or blast-radius accounting	On, always	— not optional
PROVE	An edited, reordered, or truncated mutation history	On (keyed HMAC-SHA256)	PROXIMO_AUDIT_KEYED (default on); off-box wipe detection via PROXIMO_AUDIT_EXPECTED_HEAD / PROXIMO_AUDIT_ANCHOR_*
UNDO	An unrecoverable mistake on a snapshottable plane	On where a rollback primitive exists (fail-closed)	— always applied where Proxmox supports it
DIAGNOSE	Acting with no read-only evidence first	On, always	— read-only
CONSENT	An agent confirming its own mutation with no independent, out-of-band grant	Off	PROXIMO_CONSENT_DIR (+ PROXIMO_CONSENT_TTL_SECONDS)
CONTAIN (kill-switch)	Needing to halt every mutation instantly, mid-incident	Off	PROXIMO_CONTAIN_TRIP_PATH
LEASE (arm-TTL)	A write-armed token staying armed indefinitely	Off	PROXIMO_ARM_TTL (+ PROXIMO_TOKEN_PATH)
SCOPE	An agent mutating a box outside the ones authorized at arm-time	Off	PROXIMO_SCOPE_PATH
ENVELOPE (forbid + rate)	Blast radius under hijack — unlimited-speed or explicitly-forbidden mutation	Off	PROXIMO_FORBID + PROXIMO_RATE_MAX / PROXIMO_RATE_WINDOW
TAINT	Prompt injection riding in on adversarial read output, then steering a mutation	Off	PROXIMO_TAINT_TRACK, then PROXIMO_TAINT_FORBID and/or PROXIMO_TAINT_REQUIRE_CONSENT

The seam that decides whether the opt-in gates are real

CONSENT, CONTAIN, LEASE, SCOPE, ENVELOPE, and TAINT are enforced by code in the same process and OS user as the agent they constrain. If the agent can write to a gate's own state — its consent directory, trip-file, scope file, rate-reservation directory — it can potentially clear its own gate.

They become a real boundary only when their PROXIMO_*_DIR / PROXIMO_*_PATH live outside the agent's write reach: a different OS user, a different mount, a different host. Place them there, or treat them as advisory. This isn't a weakness Proximo hides — it's the single most important deployment decision, and proximo doctor reports which sockets you've filled (without echoing the paths back, so a hijacked session can't learn where your switch is).

Two flags that widen, not protect

PROXIMO_ENABLE_EXEC (near-root ssh → pct exec) and PROXIMO_ENABLE_AGENT (in-guest qemu-agent ops) expand what Proximo can do. Both are off by default and each bounded by its own fail-closed CTID/VMID allowlist. Don't mistake them for gates.

One flag that narrows

PROXIMO_SURFACES (e.g. pve,exec) registers only the named planes' tools; the rest are removed from the MCP registry before serving, so they never reach the client's context. This is context hygiene and attack-surface reduction — not an authorization control. The token's ACL remains the real boundary.

What Proximo is not

• Not a sandbox. Risk ratings are heuristics. Defense in depth ≠ containment.
• Not a gateway. The gates are domain-specific (they understand a Proxmox VM, an ACL, a blast radius) — that's their strength, but they run in-process, so see the seam above.
• Not first, not the most tools, not the only one with a trust story. Proximo's bet is trust by construction — plan + prove + undo in-band and fail-closed — across the governance plane, honestly documented. See FAQ.

Reporting

Found a way past a boundary described here? That's exactly the review that's wanted — see SECURITY.md for how to report.