The assistant suggests. You press Enter.
A real root shell on any managed server, in your browser, with an AI that reads your screen and proposes the next command. It has no shell of its own and executes nothing. Every command that runs on your infrastructure ran because a person chose it.
On this page
Overview
Open a terminal on any managed server from your browser — no SSH client, no VPN, no jump host, nothing installed. Underneath the terminal there is a question box. Ask “why did that fail?” or “what should I check next?” and the assistant answers using what is already on your screen. You never paste a log or explain the context: it sees what you see.
Sometimes it offers a command. Two buttons appear: Run types it and presses Enter for you, Insert types it onto the prompt and stops so you can read it, edit it, or think again. There is no third button that lets it act by itself, because there is no mechanism for it to act by itself.
AI-assisted vs. agentic
Most AI infrastructure tooling being sold today is agentic: you state a goal, and the model plans and executes on its own until it decides it is finished. That is genuinely useful for a scratch VM. On production servers it means handing an autonomous process the root account and reading about the result afterwards.
The model decides and executes
- An autonomous loop holds root and acts without a human in it.
- You review the transcript after the fact — on a production box, after is too late.
- Text the server printed becomes instructions the model may follow.
- The blast radius of one bad inference is the whole machine.
- The audit trail says what the AI did, not what anyone approved.
- Stopping it mid-run means killing a process, not declining a suggestion.
The model proposes, you decide
- The assistant has no shell and no connection to the host. It cannot execute anything.
- One command at a time, on your prompt, waiting for your key.
- Malicious text in a log degrades to a suggestion you can simply read and reject.
- The blast radius is one line you looked at.
- The audit trail records what a person ran — and whether they ran it or only inserted it.
- Declining costs nothing: ignore it and keep typing.
This is not a smaller version of an agent. It is a different division of labour: the AI does the reading, remembering and recalling — the part it is genuinely better at — and the human keeps the authority. You still get the flag you could never remember and the reason a service is refusing to start. You never get a process that decided to restart the database on its own.
ManageLM does run automated work — deliberately elsewhere. Security audits, inventories, certificate deployment, credential rotation and backups all run without a person watching, because each is a bounded operation the platform drives with validated commands. An open-ended root shell is the one place that guarantee cannot be made, so it is the one place the AI does not act.
Why it matters on a root shell
The assistant reasons about text your server printed — log lines, file contents, a login banner. That text is not always trustworthy. Anyone who can write to a log your assistant later reads can write wording aimed at the assistant rather than at you. It is the oldest trick in the new book, and against an agentic tool holding root it is a remote-execution path.
Here, the same attempt reaches a suggestion box. The worst outcome is a command you did not ask for, sitting on your prompt, waiting for a key you will not press. That is why Insert exists next to Run: on a root shell, one glance at the line costs nothing.
What the assistant does
- Reads your screen. Your question travels with the last of your terminal output, so there is nothing to paste and nothing to describe.
- Explains. Why a command failed, what a log line means, which of three plausible causes fits what is actually on screen.
- Suggests one command. Never a script, never a chain of steps to approve in bulk — a single line you can read in a second.
- Uses your own model. The same LLM the agent already uses for that server, per-agent, per-site, or your account default. A model on your own network works, and there is nothing extra to configure.
- Stays out of the way. The panel folds away when you click back into the terminal;
Ctrl+Shift+Abrings it back. Stop ends an answer in progress.
Getting in
The browser never talks to your server. Keystrokes go to the portal, the portal forwards them down the connection the agent already holds open, and output comes back the same way. Your server keeps listening on nothing — no port to open, no bastion to run, no VPN to maintain, and nothing to expose when someone needs a shell from a hotel.
- A passkey every single time. Confirmed at the moment the console opens, even though the same passkey signed you in. A stolen session is not enough to become a root shell. No passkey enrolled means no console at all — not a warning, a refusal.
- Granted one server at a time. Console is not an account-wide permission and no role carries it: it is switched on for a person on a specific server, or on a group of them. An account owner has no shell anywhere until somebody grants one.
- People only. API keys and machine tokens can never open a console. It is a person at a keyboard, so it takes a signed-in browser session.
- Revocation is immediate. Take the grant away and any shell that person has open closes within the minute.
Step away and the screen locks. After ten minutes without a keystroke the portal stops forwarding output and refuses input until you confirm your passkey again. Your work survives — the shell keeps running and everything it printed behind the lock is replayed when you come back. The lock is enforced by the portal rather than drawn over the page, so it holds even if the browser is tampered with.
What leaves your server
Only what was already on your screen, and only when you ask a question — about 8 KB of recent output. Your keystrokes are never sent, so a password typed at a sudo prompt, which the shell does not echo, is never part of it. Obvious secrets that were printed — token lines, a private key — are masked in your browser before anything leaves it. The conversation lives in that window and disappears with the session; nothing is stored.
Self-hosted with a local model, nothing leaves your network at all. The assistant uses whatever LLM that server is already configured with. Point it at a model on your own infrastructure and the entire loop — your screen, the question, the answer — stays inside your perimeter.
What gets recorded
Opening and closing a console are both written to the Audit Log: who, which host, from which address, how long it lasted and how it ended. Both also fire to webhooks and notification connectors, so a root shell opening on a production host can reach your SIEM or a chat channel while it is happening.
Acting on a suggestion is recorded separately — the host, the command, and whether you ran it or only inserted it. What a model proposed and what a person chose to run are different facts, and only the second one is a decision. The Audit Log keeps the decision.
Pairs with SSH & Sudo Access and Activity Audit. Access mapping shows who could reach a server, the activity audit shows what they did once they were on it, and the console is the way in that leaves a record by construction rather than by configuration.
Keep the shell. Add the reading.
A root terminal in your browser, an assistant that already sees your screen, and not one command that runs without you.