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.
A Windows desktop, the same way in
Not every job is a shell. Windows hosts open a full graphical desktop in the same browser tab, on the same terms: no RDP port exposed, no VPN, no jump host. The portal drives the RDP session on your behalf and the agent is the only thing that ever touches the host’s own 127.0.0.1:3389, so the server still listens on nothing.
Your browser receives drawing instructions, never the RDP stream and never the credentials. Windows will not hand out an existing account’s password, so the agent owns a dedicated account and mints it a fresh random password for each session, disabling the account and scrambling the password again on every way out.
It is the same grant and the same passkey. A desktop is a privileged session on a host exactly as a shell is, so it is handed out on identical terms: the per-server console grant, the passkey confirmed at the moment it opens, the idle lock. There is no separate desktop permission to forget about.
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.
Recording the session
An audit line says a console was opened. A recording says what happened in it. Turn on Record Admin Sessions for a server or a group and every privileged session on it is captured and replayable in the browser — scrubbed, paused, read back at your own pace.
One switch, and it covers the way in that does not go through us. The two browser consoles are recorded by the portal, and the same switch asks the agent to record direct SSH logins on the host itself — so ssh root@server from someone’s laptop is recorded too, and lands in the same player. That one captures output only, never keystrokes, so a password typed at a sudo prompt is never in the file. Where a dozen people’s keys share root’s authorized_keys, the session is attributed by the fingerprint of the key that actually authenticated.
- Stored in your own bucket. Recordings go to the S3 storage you configured, compressed and encrypted with a key of their own.
- Kept as long as you say. Retention is an account setting, and expired recordings are deleted on a schedule rather than left to accumulate.
- Replaying is itself audited. The log says who opened the session and, separately, who went back and watched it.
- Optionally mandatory. Left off, a session that cannot be recorded opens anyway and says so. Switched on, it is refused instead — including if the recording stops midway.
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.