Giving an AI assistant access to Proxmox: where the boundary has to sit

There is a real and slightly frustrating asymmetry here. Reading two thousand lines of log and finding the line where something broke is exactly what a language model is good at. It is also exactly the work most people cannot let it do, because of how access is granted.

The question is not whether a model should touch a server. It is where the boundary sits, and today it usually sits in the wrong place.

Why the usual setup is uncomfortable

There are two common ways to connect an assistant to Proxmox: give it an SSH session, or give it an API token with full privileges. Both amount to the same thing. From that moment nothing stands between the model and the hardware, and every safeguard lives in the wording of a prompt.

A prompt is not a boundary. It is a request, made to a system that is designed to be helpful, in a language that has no enforcement.

The risk is missing context, not bad intent

This is the part that gets misdiagnosed. The failure mode is rarely a model deciding to do damage. It is a model acting correctly on an incomplete picture.

A disk that looks empty. The model reads a device with no mounted filesystem and treats it as free. The device belongs to a machine that is simply powered off.

A degraded pool. The model reads the degraded state and proposes rebuilding the array. The correct step was replacing one drive, and rebuilding is how the remaining data gets lost.

A service that is "not running". It is not running because it runs on a schedule and finished. Restarting it is harmless; disabling it because it "keeps stopping" is not.

In all three the command is written correctly. It is the premise that is wrong, and a correct command on a wrong premise is indistinguishable from sabotage after the fact.

Read-only helps, and it is not the whole answer

The obvious response is to grant read-only access, and it genuinely removes the worst outcomes. Two things remain.

Reading is not free. Configuration, logs and audit records contain hostnames, addresses, user names and sometimes tokens that were pasted where they should not have been. A read-only assistant with full read scope is an export of your infrastructure.

Diagnosis without action stops half way. If the useful answer is "restart this one service", a read-only setup hands the finding back to a human to retype. That is fine, and it is also why people quietly widen the permissions later.

So read-only is a good starting point and a poor destination. The destination is narrow write access with the same gates a person passes.

Where the boundary actually belongs

Not in the prompt, and not inside the model. In the layer that executes, because that is the only place that can refuse.

Three properties make such a layer trustworthy, and all three are checkable rather than promised.

Permissions come from the system that already has them. If the assistant connects as an existing account, whatever that account may touch is exactly what the assistant may touch. No second permission model is invented, so there is nothing to keep in sync and no way for the two to disagree.

Destructive operations pass the same gate a human passes. If deleting a disk asks a person for confirmation, it must ask when a model requests it too. A path that is safe for people and open for automation is not a boundary, it is a shortcut with a nice name.

Every step lands in the audit log. Who, what, when, on what, and with what result. Without this the useful question after an incident, "did the assistant do this", has no answer, and the absence of an answer is itself a reason not to grant access.

The question to ask about any such tool

Not "is it safe" but "what refuses, and where does it live?"

If the answer is "the model is instructed not to", there is no boundary. If the answer is "the executing layer checks the account's permissions and gates destructive steps", there is one, and you can test it: connect as a restricted account and confirm the refusal is real.

What Atlas does

⚠️ This layer is planned, not shipped. What follows is the design it is being built to, written here because the question above deserves an honest answer rather than a marketing one.

The intent is that the assistant plugs into Atlas rather than into Proxmox. Proxmox sits underneath and the model never reaches it directly; it can use only what Atlas itself can do, which means every existing gate stays in the path.

The boundary is drawn by Proxmox permissions, which is the first property above: whatever the connecting account may touch, the assistant touches only that much, and no new permission concept appears. Destructive operations keep the confirmation they already have, and the audit log already records who, what, when, on what and with what result for every privileged action, including refused ones.

It is also meant to be a separate component rather than part of the installation: a machine that does not want it never has it present. That matters for the same reason the rest of this article does. The safest boundary for a capability you have not chosen is its absence.