How Legit AI works

The path an event takes from a sensor to an alert an analyst can act on, and where each part runs.

Where it runs

On your own server, the API and detection engine, the console, the database and the AI model all run on machines you control, and nothing needs the internet. In Legit AI’s cloud they run on Legit AI’s servers. See Choose your path.

The platform contacts public services only in two cases. Lookups it would start on its own — IP geolocation, the Tor exit list, CVE and abuse.ch feeds — are off unless they are allowed. In Legit AI’s cloud they are on. Services an administrator configures with their own key, such as VirusTotal, are used because that configuration is the consent.

A platform installed on your own server runs in air-gap mode and refuses both. On a server with internet, Legit AI switches the lookups on at your request — see Changing a setting.

Where events come from

Source	How it arrives
Windows machines	The Windows agent reads the Security, System and Sysmon logs and sends them in batches with its own key.
Linux servers and other SSH hosts	The platform connects every 30 seconds with its own SSH key and reads logins, the top processes, listening ports, installed packages, hashes of critical files and the state of the auth log. Nothing is installed. See SSH servers.
Firewalls, switches and other devices	Syslog sent to port 514, over UDP or TCP — on your own server. See Connect data sources.
Anything that speaks HTTP	JSON, syslog or CEF sent to the ingest API with an API key — log shippers such as Fluent Bit and Vector included. CloudTrail and Azure Monitor records have their own endpoints.
Log files	Syslog, CEF, NDJSON or a Windows `.evtx` export uploaded from the console, up to 5,000 records per file.

What happens to each event

Every event takes the same path, whichever way it arrived.

Normalised. It is mapped onto one schema, legit.event.v1. The server stamps the time it received the event, so an attacker who rewrites the timestamp in a log does not move the event in time.
Checked on arrival. Fileless-malware heuristics, known indicators of compromise, active canary tokens and removable-device rules are applied.
Stored, then enriched. Tags that need history are computed from earlier events: a port scan, a regular beacon, an admin logon out of hours.
Matched against rules. A rule fires only when every condition it states holds. See Detection rules.
Suppressed, if a suppression rule says so. The decision is written to the audit log.
Scored. A deterministic analysis gives the event a risk score. It becomes an alert if a rule matched or the score is 45 or more.
Deduplicated. The same rule on the same entity within an hour adds to the existing alert’s count instead of opening a new one. A known vulnerability stays one alert for as long as it is open.
Correlated. Multi-step patterns are joined into one finding — failed logins followed by a success, a scan followed by an exploit, logins hopping from server to server, data staged and then sent out — and each host’s kill-chain stage advances.
Learned from. The host’s behavioural baseline is updated. After seven days of learning, departures from it are scored.

An event that cannot be parsed goes to a dead-letter queue that administrators can read. It is not dropped silently.

From alert to response

An alert lands in the alert queue with its evidence, rule matches and MITRE ATT&CK techniques. An analyst confirms it, dismisses it with a reason, or escalates it into an investigation.

Response actions that change a machine — isolating it, ending a process, quarantining a file, blocking USB storage — run only on a person’s decision: a second person’s approval, or, where your organisation allows one person to act, a fresh authenticator code. See Isolation and process kill.

Storage

By default the platform keeps its data in one SQLite database file in WAL mode, so readers do not block writers. Uploaded files and evidence are kept on the server’s own disk.