On this page

• Overview
• Service Threat Detection
• Session Threat Detection
• Severity & alerts
• One-click response
• Privacy

Overview

Most breaches aren't loud. A web server quietly spawns a shell, an administrator reads a password file “just once,” a scheduled job appears overnight. Threat Detection watches for exactly these moments and tells you — in plain English — what happened, how serious it is, and what to do about it. No rules to write, no dashboard to babysit.

It covers the two ways servers get abused: compromised software and users acting outside their scope. Each is a separate mode you can switch on independently, per server or for a whole group — Linux only, alongside your other agent settings.

Service Threat Detection

Service Threat Detection watches the software running on your servers — web servers, databases, mail daemons, background jobs — for the tell-tale signs of compromise, as they happen:

• A web server or database suddenly launching a shell — a classic remote-code-execution footprint.
• A service reading password files, SSH keys, or other secrets it has no business touching.
• Reverse-shell patterns — piping bash through /dev/tcp or launching nc -e.
• New persistence appearing — scheduled jobs, startup services, or login keys planted to survive a reboot.
• A server quietly reaching out to the internet — the signature of data theft or remote control.

The instant something matches, the AI writes a short explanation of why it matters and raises an alert — so you hear about a break-in in seconds, not days later from a log review.

Session Threat Detection

Session Threat Detection watches what every mapped user does once they're logged into the server. The AI evaluates each SSH and sudo session against the user's permitted scope — built from the skills they're allowed to use on that host, plus an optional free-text role description (e.g. “database administrator for production PostgreSQL”) that adds context. A user with no skills and no role is judged as a standard, non-privileged account, so administrative actions still alert. Examples of what gets flagged:

• A database admin editing the SSH or web-server configuration.
• A web admin reading password files, dumping audit logs, or running network reconnaissance.
• Deleting shell history before logging out.
• Installing kernel modules, planting cron entries, or modifying systemd units outside the user's scope.
• Sudo escalations to operations the user's skills and role don't cover.

The AI judges the whole session arc, not isolated commands — stopping a service to work on it and starting it again is normal admin work and won't trigger a false alarm. Sessions are evaluated three times: as activity builds up, again at logout, and after 10 minutes of idleness — so a risky session can be flagged (and stopped) while the user is still connected. A login whose user doesn't map to a ManageLM user is skipped entirely.

Severity & alerts

Every alert carries an AI-assigned severity: High for a clear compromise or behavior wholly outside the user's scope that needs attention now, and Medium for something unusual but plausibly legitimate that's worth a quick glance.

Alerts appear in Audit Logs → Threat Alerts in the portal — the time, the agent, who or what was involved, the severity, the rule that fired, the plain-English narrative, and a status badge (Unhandled, Discarded, Stopped, or Ended) — and arrive by email too, so you don't have to be watching the screen to know something happened. Service alerts go to admins and members with access to the agent; Session alerts are restricted to platform admins, so members can't see reviews of their own activity.

One-click response

Every alert email has the response built in. Depending on what happened you can Kill Service (terminate the offending process tree on the host), Kill Session (terminate the user's login session), or Discard Alert to mark it a false positive — Discard also tells the agent to stop alerting on the same activity for that rule and target on that host. Each action is a single click with a confirmation screen; email links expire in one hour and can be used once.

Privacy

Threat Detection is built privacy-first. For Session Threat Detection, the details of what was typed — commands, file paths, network destinations — never leave the host; only the AI's verdict and a short excerpt are kept with the alert. On a self-hosted install with a local AI model, the analysis runs entirely on your own infrastructure, so nothing about your servers is sent anywhere.