Hi,
I made a small tool for people who already use an AI agent such as Claude Code and want it to check or install guest updates without handing it a general-purpose shell or unrestricted Proxmox access.
It is not a replacement for cron, unattended-upgrades, or Ansible. It is for the workflow of asking an agent, for example, “what needs updating?” or “install the security updates on VMx”, while restricting the actions available to it. Pool scope is enforced by the Proxmox API token; the guest-side command restriction is enforced by sshd with a forced command, not by the prompt.
It is early software (0.1.x), but I use it daily on PVE 9. PVE 8 should work—the installer handles the permission differences—but I have not tested it myself, so feedback from PVE 8 users would be particularly useful.
Repository, short demo, and security-model notes: https://github.com/matousfiser/pvewarden
Questions and critical feedback are welcome.
I made a small tool for people who already use an AI agent such as Claude Code and want it to check or install guest updates without handing it a general-purpose shell or unrestricted Proxmox access.
It is not a replacement for cron, unattended-upgrades, or Ansible. It is for the workflow of asking an agent, for example, “what needs updating?” or “install the security updates on VMx”, while restricting the actions available to it. Pool scope is enforced by the Proxmox API token; the guest-side command restriction is enforced by sshd with a forced command, not by the prompt.
Proxmox side
- A single installer script creates a pool, a minimal role, and an API token restricted to that pool. It also creates a small Debian container for the server.
- The token can see guests in its pool, create snapshots, roll back, and start, stop, or reboot guests. Actions require the opt-in tags. It cannot create, delete, or reconfigure guests, and it has no host access.
- Guests are opted in through tags: pvewarden-update permits updates and pvewarden-reboot permits reboots. You control those tags.
- It waits for Proxmox guest locks, such as during a backup.
- Nothing remains running on the host after installation. --dry-run shows the planned steps without making changes.
Guest side
Supported guests are Debian 12/13 and Ubuntu 22.04 or newer: LXC containers and VMs with the QEMU Guest Agent.- Each enrolled guest gets a pvewarden user and its own SSH key. The key is restricted to a forced command that accepts a small fixed set of commands (check, status, upgrade-security, etc.); there is no shell or forwarding.
- Updates are snapshot-first: if snapshot creation fails, no packages are installed unless you explicitly confirm an update without a snapshot.
- Only the distribution’s official archives are used. Packages from third-party repositories (for example Docker or PHP) are reported but not installed. Distribution release upgrades are not performed.
- Rolling back and deleting snapshots require an explicit confirmation in the client; the agent cannot provide it.
- Enrolment installs unattended-upgrades and sudo, and adds sudoers rules for five fixed commands. On Debian, it can also enable daily automatic updates; the installer asks whether to keep them off or turn them on. pvewarden-enroll --uninstall <vmid> removes the guest-side setup but leaves those packages in place. pvewarden-setup uninstall removes the Proxmox-side installation.
It is early software (0.1.x), but I use it daily on PVE 9. PVE 8 should work—the installer handles the permission differences—but I have not tested it myself, so feedback from PVE 8 users would be particularly useful.
Repository, short demo, and security-model notes: https://github.com/matousfiser/pvewarden
Questions and critical feedback are welcome.