How operations work

Virtual colleagues can act on real systems: check a service, read a log, restart something. They do it through three kinds of target, all reached through the runner, a separate container that the installation package configures.

Targets

Target	What it is	Set up in
Hosts	Machines reached over SSH: a POSIX shell on Linux, PowerShell on Windows (OpenSSH works on Windows too).	Admin → Hosts, plus each person's credential
The runner	Commands that run inside the runner itself: network diagnostics such as ping, dig, nmap or curl, and database clients such as psql, mariadb and sqlcmd.	Nothing to set up
MCP servers	Tools offered by an MCP server, remote or started inside the runner.	Admin → Operations, per office

A colleague sees only the hosts where its person has a credential, and only the MCP servers of its office. Disabled hosts are not offered. Asked about a host where its person has no credential, the colleague says so and points to Account → Credentials.

From a question to a result

1. You ask. "Is nginx running on web01?"
2. The colleague proposes a command, with the target and the reason, for example systemctl status nginx on web01.
3. Orlok classifies it. Read-only, catastrophic, or something in between. What happens next depends on the mode of the profile and on the command types you approved.
4. If approval is needed, it waits for you, in a strip above the message box. Only you see it. See Approvals.
5. The runner runs it with your credential for that host. The credential is read at that moment and never shown to the colleague.
6. The output comes back, live, with likely secrets masked, and the colleague reads it and answers.

A command has a time limit: 2 minutes by default, up to 30 if the colleague asks for more. The output kept for the colleague stops at about 64 KB, and a running command can be stopped.

Plans

For a change made of several commands, the colleague proposes a plan: a title, what it does, its risks and how to roll it back, and up to 20 steps. You approve the whole plan or each step. Steps run in order, and a failed step stops the rest.

Who acts as whom

On a host the command runs as the account of your credential, so the server's permissions, sudo rules and logs work as they do for you. In Orlok every job is recorded: which colleague asked, for whom, on which target, as which account, and the decision. See Audit.

The colleague is as strong as your account. If your credential is root, so is your colleague on that host. Store the account with the least rights that does the job.

Where to look

• Your requests and their output: in the conversation.
• Your approved command types: Account → Approved command types.
• The runner's status, the MCP servers and the logs: Admin → Operations, for administrators.