-
Notifications
You must be signed in to change notification settings - Fork 1
The Trust Spine
Proximo's protection comes from two layers that do not fail the same way. Keeping them straight is the whole game.
Proximo cannot exceed the RBAC grants on the credential you give it. That's enforced server-side, by Proxmox itself — not by any line of Proximo's own code. So it holds even if the Proximo process is fully compromised: a prompt-injected agent, a poisoned dependency, an attacker with a shell in the MCP client. Whatever the token can't do, nothing running as Proximo can do either.
This is the only layer that assumes Proximo's own process might be hostile. It's why Proximo is safe to hand to an agent at all. Scope the token, and the floor holds no matter what happens above it.
These raise the bar within Proximo's own trust domain. They don't assume Proximo is hostile — they make an honest agent productive and accountable. Four are structural and always on:
| Pillar | What it guarantees |
|---|---|
| PLAN | No mutation lands without a dry-run preview first — the exact change, the live state, a blast-radius accounting, an advisory risk rating. You can't mutate without a plan, and the plan is recorded. |
| PROVE | Every plan and confirmed action lands in a tamper-evident, hash-chained ledger (keyed HMAC-SHA256 by default). Edits, reordering, and truncation are detectable via audit_verify. An off-box head anchor (opt-in) extends that to full-wipe detection. |
| UNDO | Where Proxmox has a rollback primitive — guest config, container exec, guest snapshot — Proximo takes the snapshot before it acts, fail-closed. It covers the snapshottable surface, not every mutation (firewall/SDN/ACL have no Proxmox rollback primitive — stated plainly, not hidden). |
| DIAGNOSE | Read-only evidence is gathered before acting, so decisions are grounded. It flags incompleteness, so "no warnings" never falsely reads as "safe." |
Think of it as six pillars — four ship standing, two are yours to erect. The other two (Security Model) can only ever be raised by you, because their whole value is that their state lives outside the agent's reach. A pillar Proximo raised for you would be a pillar the agent could lower for itself.
Layer 2's gates run in the same process, same OS user as the agent they constrain. If that agent (or whatever hijacked it) can also write to a gate's own state, it can potentially clear its own gate. They become a real boundary — not just a speed bump — only when their state directories live outside the agent's write reach: a different OS user, mount, or host. See Security Model for how to place them, and for the full list of honest limits.
And the risk ratings? An advisory heuristic, not a sandbox. LOW means "no state
change," not "safe." Always review the plan.
Layer 1 is why it's safe. Layer 2 is why it's useful. Neither pretends to be the other.
Getting started
How it works
More