Talk to your servers like you talk to a person.

One step, and it is yours to make. Under Setup, the model she thinks with: the provider — Anthropic, OpenAI, xAI, or a local server such as Ollama, LM Studio or vLLM — the model's API name, typed exactly as the provider spells it, how much one answer may write, and the API key — kept encrypted on your computer, never in the map document and never sent anywhere but to the provider you chose.

Then there is nothing to allow. She answers on any Vigia server with a shell open — one you opened, or one Vigia opens for the question. Until you ask her something, nothing happens: no agent, no cost, no call to anybody, and she does not read that server at all.

An action that reports success is not the same as an action that worked. After a change, the outcome of every card — run, failed or declined — goes back to her with your next question, and she reads the box again and shows the evidence: the rules as they now stand, in the order they will actually be evaluated, with the comment that explains why they exist. If something did not land, you learn it from her rather than from a customer.

And she does not stop at the question. Reading the firewall to confirm ten blocked addresses is also reading the firewall — so when SSH turns out to be open to the world, she says so, explains why a denylist does not fix it, and offers to lock the port down to your address. Proposed, of course. Never done.

Ask in English, German, Spanish, Portuguese, French — whatever you would type without stopping to translate. She reads the box in its own language, which is Linux, and answers you in yours. The commands she proposes are the same commands either way; only the conversation changes.

Vigia reads the server before she speaks: which distribution and package manager, which firewall — ufw, firewalld or neither — which web server, which FTP server, which database engines, which services are running. Those facts go to her with your question, so what she proposes is written for that box rather than for a generic one. Blocking an address on a ufw box and on a firewalld box are different commands, and she writes the right one because she was told which is there.

One change is one proposal, not one per item: ten addresses to block is a single card. And when a question is only a question, the answer is only an answer — there is nothing to press, because nothing needs doing.

A terminal pane on a server has a Themis button. She opens beside the screen, never over it, and reads what is on it — the last command and what it printed — so What am I looking at and What went wrong need nothing pasted. She lays one command on the prompt: a read goes on by itself, anything that changes the box waits on its card for Type it, and Enter is always yours. Send what's on screen can be turned off when the screen holds something she should not read.

Other screens hand her their question the same way — a site's findings, a container's logs — and she answers in a sheet beside the page, in the same conversation the server's own Themis screen holds.

Effective sshd, the firewall, every listener, the updates, the accounts, the kernel switches, the certificates, the auth log — read first, then checked against each other. What comes out is not a scanner's list: it is a document with a risk level, a table of every open port and who can actually reach it, and findings that carry their evidence.

On one real audit she found three things worth a person's time. MongoDB was running and enabled although Vigia's own ledger recorded it uninstalled sixty seconds earlier — she read the service, the package and the journal, said the removal did not take or something restarted it, and noted the exposure is limited because it binds to loopback with authorization on. She caught Vigia contradicting itself, and said so. Redis carried a weak password: reachable only from four named addresses today, so the finding is not "you are breached" but "if any of those four is ever widened, that password is the only control left". And a broken FTP service with its port still open and nothing behind it: not an exposure, but a feature silently down.

Then the section that separates an audit from a scan: NOT FINDINGS. SSH open to the whole internet on 22 — key-only, root disabled, password authentication off — is the correct, ordinary design, and she says so rather than padding the list. Redis on a public address but firewall-restricted to four peers: the control is real and working. Port 21 open with nothing behind it. A container port Docker publishes that the probes jointly prove is not externally reachable. An account created by mistake with sudo and locked the same day: already remediated. Everything she chose not to alarm you about, with the reason.

Resources, services, performance, disk, errors, pending maintenance — and recommendations that never propose deleting logs to free space. Load against core count rather than a bare number; memory with the headroom named; the one failed unit out of forty pulled to the front with the exact exit code and the second it happened; the top consumers by memory with what each one actually is.

The judgement is in the recommendation. On one box the failed service was FTP, and she did not simply say restart it: if FTP is meant to be in service, restart it and read the log; if it is not needed, leave it disabled rather than re-triggering the failure. And when she does offer the restart, the proposal says what it costs — only that service, briefly unavailable — because a recommendation without its blast radius is not advice.

Pick an hour, six, a day, a week, a month, or type a window of your own, and press Investigate. Everything for that window is gathered first — the auth log, the sessions, sudo, service and package changes, cron, Fail2Ban, the firewall log, the files modified since — and only then investigated. Two rules are built into how she reads it: usernames stuffed into a log are noise rather than evidence, and shell history is never trusted.

What comes out is an executive summary, a timeline with a source on every single row — this journal unit, this Vigia ledger line, this dpkg log, this firewall tail — and threats ranked. Including a category most tools do not have: UNEXPLAINED. Where the record and the live state disagree and she cannot resolve it from the box, she says so plainly instead of guessing, and tells you what to check.

One investigation came back clean, and the interesting part is how it got there. A brand-new account created with sudo, revoked and locked inside ninety seconds looks exactly like an intrusion — she matched it to the operator's own actions in the Vigia ledger and called it what it was. A broken service at 18:40:31 looks like an attack — the sudo log shows a config push one second earlier, so the cause is self-inflicted. And the brute-force noise that fills the log is reported as contained, with the numbers: hundreds of failed attempts, none reaching the password stage, because password authentication is off.

Her chair has two kinds of page. Ask Themis is a question about the servers picked in the column on the right — the same pick Actions, Snippets and Flows use: Pick Servers… chooses them by name, by group or from a saved set, and each row carries a dot that says whether its shell is open. A group is servers asked about together, kept with what she is told about them and a conversation of its own; Save as Group, under the picked servers, makes one from the pick.

Nothing has to be done to a box first: no authorization, no step per server, nothing written before the first question. Delete a group and the servers stay exactly where they are, with anything she kept on them.

Pick servers from anywhere on the map. Nothing moves: a box stays in its group on the map and can sit in as many of these as there are questions about it. What makes a group more than a list is the two fields beside its name.

What it is, handed to her before she reads a byte: the six boxes that take write traffic for the California and Tampa pools; MDB-1 is the primary, the others are replicas. And what matters: never restart the primary during business hours; replication lag over ten seconds is a problem. From then on every answer about that group is written knowing it — which box must not be touched, what counts as a problem here, what not to suggest. It is the difference between an assistant that knows Linux and one that knows your Linux.

She reads each server through its own session, so the question does not start until the sessions exist. Vigia opens them, counts them in on screen with every name showing, and waits. A box that will not open inside forty-five seconds is left out — and Vigia names it, rather than quietly reporting on fifteen servers while you believe you asked about sixteen.

Sixteen servers in one question is more than a conversation holds well. Instead of quietly giving you a thinner answer, Vigia says so above the conversation, before you ask, as soon as more than ten are in it: past a dozen boxes the reading stops fitting, expect a slower answer and a thinner one, and the ten that matter will answer better.

Software that warns you its own output is about to get worse is rarer than it should be. It is the same instinct as the rest of Vigia: say what is true about the box, including when the box is this one.