Either the rule was violated,
or it wasn’t.

Detection by guesswork has a cost.

Your current stack watches the same events invariantd does — then asks a model whether they look suspicious. The model hedges. It says “suspicious activity detected” and hands the doubt to a human, hours after the process it was worried about has already done its work.

85–95%

of EDR alerts are false positives

2–4 hours

of analyst time to triage each one

“Suspicious”

is the most detailed explanation you get

A probabilistic detector cannot tell you what happened. It can only tell you what it suspects — and by the time a human confirms it, the response is late. The triage queue is where that difference is paid for.

Observe. Model. Verify.

1. 2.1 Observe

   An eBPF agent under 10 MB attaches to kernel tracepoints and streams process, file, network, and privilege events through a ring buffer — microsecond timestamps, under 3% CPU, nothing leaves the host.

2. 2.2 Model

   Events build a live temporal graph: every process, file, user, and connection is a node; every action is an edge with a time interval. The graph is the ground truth of what your system actually did.

3. 2.3 Verify

   Your rules compile into an incremental evaluation network that checks each event as it lands. When a rule matches, the violation is emitted with its causal chain — kernel event to verdict in under half a millisecond.

Catching it is half the job.

A verdict in half a millisecond is only useful if something acts on it. So every host runs a companion — invariantd-responder — that subscribes to the daemon’s verified violations and enforces a response policy you control. Because a process is killed on the host where it ran, response scales as one small agent per machine: no central bottleneck, no round-trip to a cloud.

The shipped defaults are deliberately conservative — nothing ambiguous is ever touched:

Every decision — enforced, escalated, or blocked by the safety guard — is written to a durable audit trail. Nothing is killed silently: the responder ships in dry-run by default, protects init, sshd, and itself unconditionally, and answers “what did it do, and why” for every action it takes.

Rules you can read.

Rules are written in a small, formal language — declarative enough to review in a pull request, precise enough to compile. This one says: a web server must never spawn a shell — and what to do the instant one does.

invariant no_shell_from_web {
    @severity(critical)
    @respond(kill)
    never (p:Process)-[:spawns]->(c:Process)
        where p.name in {"nginx", "apache2"}
          and c.path in {"/bin/sh", "/bin/bash"}
}

Sixty-six rules ship in the box, covering all ten MITRE ATT&CK tactics — web shells, reverse shells, credential theft, container escape, persistence, exfiltration, ransomware behavior. Every one delivers a causal chain, and carries its own response.

• Initial access5
• Persistence8
• Privilege escalation6
• Credential access6
• Lateral movement4
• Collection4
• Exfiltration7
• Defense evasion6
• Impact5
• Container security8
• Infrastructure baseline7

Verification, next to detection.

Detection and verification answer different questions. EDR asks “does this look like an attack?” invariantd asks “did the system break a rule?” — and the second question has an exact answer you can act on in microseconds.

One binary. Your hosts. Nothing else.

A static daemon, a companion responder, and a systemd unit. Linux kernel 5.8 or later. Events, graph, verification, and response all stay on the host — there is no agent phone-home, no vendor cloud, no data residency question to answer.

The source is available under BUSL-1.1; production use takes a commercial license. You can read every line of the engine that decides whether your infrastructure broke a rule — and of the responder that acts when it did.

One honest limitation: invariantd verifies the rules you write. It makes no claim about what you haven’t specified. That precision is the point — but it means the rulebook, not a model, is where your judgment lives.

Questions, answered plainly.

What is invariantd?

invariantd is runtime verification for Linux infrastructure. It verifies every process spawn, file write, network connection, and privilege change on your hosts against formal rules you write, and produces a violation — with its exact causal chain — the moment a rule breaks.

How is it different from EDR?

Traditional EDR uses ML models and signatures to guess whether activity looks suspicious, producing 85–95% false positives. invariantd evaluates formal rules, so a violation is a fact, not a probability — 0% false positives by construction — and the alert names exactly what happened.

Does it respond to threats, or only detect them?

It responds. A per-host companion, invariantd-responder, enforces a policy: critical, unambiguous violations are terminated on the host in under 2 milliseconds; high-severity is escalated to a human; the rest is recorded. Defaults are conservative, dry-run by default, and every action is written to a durable audit trail.

Where does it run?

Entirely on your hosts. A single static binary and a systemd unit on Linux kernel 5.8 or later. Events, graph, verification, and response all stay on the machine — no cloud dependency and no data residency question.

What does it cost?

The source is available under BUSL-1.1; production use takes a commercial license. At 10,000 hosts it runs roughly $250K per year, compared with about $2M per year for traditional EDR.

What does it detect out of the box?

Sixty-six rules ship built in, covering all ten MITRE ATT&CK tactics — web shells, reverse shells, credential theft, container escape, persistence, exfiltration, and ransomware behavior — each delivering a causal chain and carrying its own response.