An AI copilot for infrastructure: what it can and cannot do

The gain is mostly recall. A competent operator knows perhaps a dozen tools deeply and another twenty vaguely. A model returns the exact journalctl invocation, the nginx directive matching the behaviour you described, the field worth reading in systemctl show, without hesitation. On a diagnostic it compresses the time spent looking up the right phrasing, not the time spent thinking. That is a modest claim, and it is still worth a lot on a machine you have not touched in six months.

The gap never moves: invisible state. A cron rewriting a config file, a systemd unit edited by hand and never committed, an undeclared dependency between two services. None of that shows up in command output, so none of it exists for the model. And the same command carries different weight on different machines: systemctl restart postgresql reads identically on a throwaway VPS and on the primary of a replication pair. The useful question is not whether the model is good, it is what its mistakes cost.

The failure mode specific to agents is chaining. Each output becomes the next turn's input, so when the third command returns something odd, the model rarely concludes it was wrong; it rationalises and carries on. Server side effects do not replay backwards. A truncated file stays truncated, a flushed iptables table kills the session in progress, a service stopped under load leaves a backlog nothing catches up on.

There is also a structural risk that gets waved away too easily: command output is text the model reads, which makes it an input channel. A log line, a login banner, a filename crafted by an attacker all become candidate instructions. Nobody has a complete answer to that today. On its own it is reason enough to keep the decision to execute a human act rather than a setting.

Three regimes cover most situations. Observation: the model inspects, anything not classified as safe is refused outright rather than queued for approval, and the conversation exists to understand. Systematic review: the operator sees the exact command, in its final form, before it leaves, and approves one command at a time. Supervised autonomy: routine work runs, and only destructive commands halt the flow. In Servor these are called Ask, Plan and Auto; Plan is the default, and the mode can be switched mid-session.

One thing is worth stating plainly, because it is oversold elsewhere: approval applies to a command, not to a plan. There is no frozen plan object to sign off in one go before execution starts; the agent moves, proposes, stops. That is a less comfortable story to tell, and it keeps the decision at the level where the effect happens. The real trap sits elsewhere: approval fatigue. Forty prompts in a row and the forty-first gets clicked unread. The number of stops has to stay proportional to real risk, which means classifying each command rather than relying on the session mode alone.

The two do not compete, they cover different ground. A playbook is deterministic, idempotent, reviewable, versioned alongside the rest of your code. Anything you do twice a month belongs there, because codifying it is safer and cheaper than asking a model again. What stays outside is the first hour of an incident, the inherited box nobody documented, the once-a-year operation, the log format you have never seen. That is where a copilot replaces six browser tabs, not where it replaces the playbook.

ChatOps already had the right shape: run operations through a shared channel where the command is visible, discussed, approved, and where the record writes itself. A copilot changes who drafts the proposal, not who carries responsibility. AIOps, for its part, mostly addressed signal correlation to detect problems earlier; acting stayed a human call. Treating a copilot as a very fast junior operator whose work you always read describes reality better than any autonomy claim.

A denied-command list is worth something only when it is enforced beyond the interface; a filter that lives in the browser alone disappears with the first bypass. In Servor it is applied both server side and agent side, from the same shared list: recursive deletion of the root, raw disk writes, fork bombs, writes to /etc/passwd, /etc/shadow or /etc/sudoers. Alongside it sit syntactic analysis of the command, a risk classification, a rate limit, and logging of every execution. A server can also be installed for monitoring only, in which case the control plane refuses any execution whatever mode the console is in.

Traceability is the guardrail everyone ignores until the first post-mortem. Every command, whatever its origin, manual, AI, runbook or terminal, is stored with its output, exit code and duration, and the audit log is hash-chained and write-protected at the database level so an entry can be neither edited nor deleted. None of this makes mistakes impossible. These mechanisms lower the probability and the reach of an incident; they do not take either to zero, and responsibility stays with whoever approved the command.

The mechanism fits in three sentences. Exactly one tool is exposed to the model: run a command. The tool call comes back to the browser, which classifies the risk, applies the mode policy, shows the approval prompt, then relays the execution. The command is signed in the browser with an Ed25519 key derived from the vault key, and that signature is verified on the target machine rather than on the server that carried the request; a per-server option makes the signature mandatory. The vault key itself comes from a passphrase that is never transmitted: it is derived in the browser with Argon2id, a deliberately slow and memory-hungry function, and unwraps an X25519 private key that never leaves the page.

The resulting property is worth stating without drama: a compromised control plane cannot forge an execution, because it does not hold the key that signs one. That is not invulnerability, it is a smaller blast radius. A successful attack on the platform does not hand anyone a shell on your fleet. The same reasoning governs the agent on the machine: it opens an outbound connection with no inbound port to expose, never receives a credential, and runs as the system user you configured.

Day to day, the console keeps one unified history: a command issued by the copilot, by a runbook, by the execution form or from the web terminal all land in the same place, with output, exit code and duration. Twenty-seven official runbooks cover the usual installs and hardening work, from nginx and PostgreSQL to Docker, fail2ban, UFW, WireGuard, Prometheus and node_exporter. What is already written and reviewed does not need to be asked of a model.

The copilot ships with the AI plan, at 29 € excl. VAT per month with 3,000 monthly credits. A credit maps to the real cost of the tokens processed, so a short question consumes little and a long diagnostic session consumes more. The Free and Operations plans include no AI, and everyday operations work without a copilot.