Isolation and process kill

Response actions change a real machine, so none of them runs on one person’s word alone. Either a second person approves it, or — where the organisation allows one person to act (Secure terminal → Policy, Solo) — the person proves it is them with a fresh authenticator code and the platform’s guard rails take the second person’s place. See Secure terminal for what each mode allows.

From the console

1. In the alert’s Quick response panel, choose Isolate host, Kill process — optionally with every process it started — or Quarantine file, and confirm.

2. Four eyes: the request waits under Pending approvals in the top bar, and someone other than the requester — ANALYST or above — approves or rejects it. Solo: you type your code (and, to isolate, the host’s name) and it runs at once; everyone in the organisation is told, and it is recorded as approved by you (step-up), never as a second person.

3. On approval the platform sends the command to the machine and reports the machine’s own answer: done, or failed with the reason the endpoint gave.

Through the API the same commands can be queued directly for an agent — POST /api/agents/{agent_id}/commands with {"command": "isolate_host", "params": {}} — and then the approval needs a different ADMIN: POST /api/agents/{agent_id}/commands/{id}/approve.

Five minutes to reach the machine

The agent must have checked in within the last ten minutes to be sent a command, and a command it has not collected within five minutes of the request expires. An agent that has gone quiet fails the action at once, with that said, rather than reporting success.

On a Windows machine

The agent carries out the command. From version 1.1.6 it carries out only commands signed with a key unique to your organisation, and refuses anything unsigned, signed for another agent, expired or repeated. Agents do not update themselves: 1.1.6 is installed by hand, with the command from the console.

Isolation

• Windows Firewall blocks all traffic in both directions except to and from the Legit AI server, so the agent keeps reporting and can still receive the release.
• If the firewall is off on a profile, the agent turns it on: rules on a disabled profile are ignored, and isolation would report success while isolating nothing.
• The release time is written to disk before anything changes. When it passes, the agent lifts the isolation itself — without the server, and across a restart of the agent or the machine.
• An isolation lasts 60 minutes unless set otherwise, and at most 24 hours. Release lifts it earlier.
• Every change is checked; if one fails, what was already changed is put back.

Ending a process

By PID or by name. The agent looks the PID up first and refuses to end:

• the Windows kernel (PIDs 0 and 4);
• processes Windows cannot run without: smss.exe, csrss.exe, wininit.exe, winlogon.exe, services.exe, lsass.exe, lsaiso.exe, svchost.exe, fontdrvhost.exe, dwm.exe and the system processes;
• the Legit AI agent itself.

Quarantining a file

The agent hashes the file, moves it into a locked quarantine folder under a random name, and limits its permissions to SYSTEM and Administrators. A quarantined file can be restored to where it was.

On a Linux server

Servers watched over SSH are isolated through the same SSH channel:

• the platform adds its own iptables chains, leaving the server’s existing rules and default policies alone, and drops all traffic except its own connection;
• the isolation releases itself after 15 minutes as a fail-safe; Release removes exactly what was added;
• the account the platform uses needs passwordless sudo for iptables and kill. Without it, the action reports unavailable — the platform never asks for or stores a sudo password.

Record

Every request, approval, rejection and result is written to the audit log, with who did it.