Let AI run the server, not break it

Atlas can open its own Model Context Protocol server for those who want one, and offers a command box inside the panel. It is a separate component: it does not arrive with the installation, whoever wants it adds it from the panel with one button, and on a machine that does not want it the component is never present. Once added, the state of the server is read, a fault is worked through, and work can be carried out by typing what is needed. The boundary is drawn by Proxmox: whatever a user can touch, the AI touches only that much. No new permission concept appears. The AI is plugged into Atlas, not into Proxmox. Proxmox sits underneath, but the model never reaches it directly; it uses only what Atlas can do.

What it costs today to give a model server access

There is only one way today to let an AI assistant work with Proxmox: hand it an SSH session or a fully privileged API token. That means handing over root, and from that point nothing stands between the model and the hardware.

The risk comes from missing context, not from bad intent. A model can see a disk as empty and treat it as removable, when the disk belongs to a machine that is simply powered off. It can read a degraded pool and propose rebuilding it, when the right step is replacing one drive. The command is written correctly and the result is data loss.

So in serious environments the model is kept outside the server. The loss shows up in diagnosis: reading long logs and finding what broke is exactly what a model is good at, and that is exactly the work it cannot do.

What can be asked

The command box inside the panel is where asking and instructing happen in one conversation. The examples below are the asking side: the model reads the state of the server and answers with the record it relied on, and nothing changes in them.

Why did tonight the backup fail, at which step did it stop, was there room on the target storage?

Why has this virtual machine been slow since last night, is the bottleneck the processor or the disk?

Why is the pool degraded, which drive dropped out, is data at risk right now?

Which of the pending updates asks for a restart and which services will it stop?

What does this error in the log mean, has it happened before, is it repeating?

At this rate when does capacity run out, which machine is growing fastest?

What can be done

This is what people call VibeOps: running a server by talking to it. Vibe coding means writing without reading the code, and on Proxmox that is not an option, so here every step stays visible. Work is done in the same box: the request is typed in plain language. Atlas first reports what it is going to do and where it will touch: the steps, the machines and storages affected, and the way back. The work is carried out only after approval. No new permission concept appears: the command box works with the permissions of the Proxmox account it connects as. Anyone who wants a narrower AI gives it a narrowly scoped Proxmox account, and the scope is written in that account’s permissions. Writing can be turned off for a single session, leaving only reading. Every step lands in the audit log.

Give this machine two more cores and raise its memory to eight gigabytes.

Set up a backup at three in the morning for every machine in this pool.

Install the pending security patches, leave the ones needing a restart for the maintenance window.

Set the restart policy of that container to always.

Give this user backup rights only, nothing else.

Move that disk to the new pool, take a snapshot before moving it.

The model goes through the same gate a person does

The MCP server opens no side road. The protections Atlas already runs for a human user apply to the model as well, in the same order.

Permissions come from Proxmox

The model works with the permissions of the user it connects as, not with an account of its own. Whatever Proxmox closes to that user stays closed to the model. Atlas builds no permission system of its own.

The Proxmox account sets the scope

The command box works with the permissions of the Proxmox account it connects as; Atlas introduces no permission concept of its own. Anyone who wants a narrow scope gives it a narrow account, and that scope is written in the account’s permissions and read back from there in an audit. Turning writing off for a single session is one tap.

Impact is shown first

When a change is proposed, the steps to be applied, the resources affected and the way back are shown to a person. Approval happens on screen, not inside the conversation.

Hard confirmation for irreversible work

If the account it connects as holds no permission, deleting, formatting and tearing down a pool cannot happen at all. Where permission exists, the hard confirmation the product uses elsewhere still applies: the name has to be typed to confirm, one click is not enough. Anyone who wants one more step turns it on: write operations ask for a one time code, the same two step verification the account already uses.

Every step is recorded

Everything the model reads and every operation it asks for goes into the audit log: which user, which model, when, with what result. The record cannot be altered afterwards.

Answers show their source

The model says where it drew a conclusion from: which log line, which measurement, which configuration. An answer that cannot be checked does not count as an answer.

What the model cannot do

The limits live in the product, not in the conversation. How the model is asked, or how hard someone tries to talk it around, makes no difference. In an organisation that connects its own model the same limits apply, because the rule is enforced in the server and not in the model.

It cannot widen its own permissions or create a new user or access key.

It cannot apply any write operation without approval.

If the account it connects as holds no write permission, it changes nothing and only reads.

It cannot open a shell on the server or drop into a command line. That is rarely needed, because work that demands depth is covered too: from ZFS pools to Ceph, from bridges to OVS, from pinning a kernel to handing over permissions, and that coverage widens with every release. For the rare job that falls outside, it writes the command and explains the risk, and the command is run by a human, not by the model.

It cannot delete or alter the audit record.

Where the data goes

The MCP server is a separate component and does not come with the default installation. It is added from the panel with one button; on a machine that does not want it, not even its files are present. Once installed, which resources it may look at and how long it stays open remain the customer’s decisions.

Which model it connects to is also the customer’s choice. With a local model running on the server itself, no data leaves the machine and the product stays offline. If an outside service is chosen, the content to be sent is visible before it is sent.

For organisations under strict regulation

No certification is claimed. The product is designed to meet the requirements of frameworks with hard audit conditions, and an organisation’s own audit can use these behaviours as evidence.

AI management system (ISO/IEC 42001): what the model may do is written down, the limits are enforced in the product, every use is recorded.

Information security (ISO/IEC 27001): access comes from the identity system the organisation already runs, privilege follows least privilege, records cannot be altered.

AI risk management (ISO/IEC 23894 and the NIST AI RMF): no autonomous action, human approval is a required step in the flow.

Personal data (GDPR and equivalents): data stays on the customer’s machine; if it is to leave, it is visible first and the decision belongs to the customer.

Critical infrastructure (NIS2 and AI transparency provisions): after an incident, who did what, what the model proposed and who approved it can be read back.

Frequently asked