Talk to your servers like you talk to a person.

Two steps, and both of them are yours to make. First the model she thinks with: the provider, the model, how much she may write, and the API key — kept sealed on your computer under the key drive, never in the map document and never sent anywhere but to the provider you chose.

Then, per box, you allow her. That is the moment /var/lib/lens appears — and nothing else happens: no agent, no cost, no call to anybody. Until you ask her something, she does not read that server at all. Allow one, or run Authorize All in the background over the shells that are already open.

You do not have to know the tool, the flag or the file. Say what is wrong in the words you would use with a colleague — sloppy, joking, half-technical — and she reads the box and answers with what she found.

The three screens below are one real exchange on a live server, start to finish. The question was asked in plain, unserious English: somebody is hammering port 22, list them. She came back with the roster — every source address from the last day of the auth log with its failed attempts, biggest first — and with the thing that actually mattered, which nobody asked for: Fail2Ban had banned those addresses twenty-six times, but every ban had expired, so at that moment none of them were blocked.

The answer to "block all ten, permanently" is one card, not ten: the addresses, what the rule does, and what it does not touch — dropped ahead of every allow rule, nothing else on the box changed, your own address unaffected. Three verbs: No, Show me, Run. After Run, she does the part most people skip: she reads the firewall back and proves it — ten DENY rules, each ahead of the SSH allows, with the reason written into the comment. And then she flags something nobody asked about: port 22 is still open to the whole internet, and a list of ten blocked addresses is not a substitute for that. Want it locked to your address instead?

An action that reports success is not the same as an action that worked. After a change, Themis 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.

Lens 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.

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 the real audit below she found three things worth a person's time. MongoDB was running and enabled although Lens'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 Lens 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 the box below 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. 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 Lens 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.

The investigation below 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 Lens 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.

The chair keeps two lists and no ambiguity: the servers Themis is allowed on, and the ones awaiting authorization — where she has not been allowed, cannot read anything, and has nothing of hers on the box. Allow them one at a time, or all of them, five or ten in parallel; the work carries on if you leave the screen, and each row says what it is doing right now.

The screen states its own footprint, in the same words this page does: no agent, no daemon, nothing listening on a port, nothing added to systemd. One folder, holding her reports, the baseline the next report is compared against, and the run ledger. Withdraw and the folder is deleted — after which the server holds no trace of her at all.

Pick servers from anywhere on the map. Nothing moves: a box stays in its group and can sit in as many fleets as there are questions about it. What makes a fleet more than a list is the two boxes underneath.

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 fleet 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. Lens 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 the answer says so, rather than quietly reporting on fifteen servers while you believe you asked about sixteen.

Ask for a table of what is installed on each and you get one — sixteen rows read from sixteen boxes. Ask a follow-up about operating systems and versions and you get that, on the same conversation, no re-reading and no re-asking. Ask whether anything needs an update or a reboot and the answer is a table with the pending count, the security count, whether a reboot is required and what triggered it — the exact packages, kernel image included.

And in each answer, the line nobody asked for. That only one member of the fleet runs the web and database stack. That two of the sixteen are the RHEL-family boxes running firewalld while the rest run ufw. That one box is on a release whose standard support ended in April 2025, and is worth a look if it is not on extended maintenance. That is the difference between a tool that answers the question and a colleague who was reading while they worked.

Sixteen servers in one question is more than a conversation holds well. Instead of quietly giving you a thinner answer, Lens says so above the box, before you ask: past a dozen boxes the reading stops fitting, expect a slower answer and a shallower one, and a fleet of 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 Lens: say what is true about the box, including when the box is this one.