Glossary

One-line definitions for Imunify-specific terms used across these docs: Sensor, Event, Approval, Override, Rule, Token types, OpenClaw, and Unlock.

Short definitions for the terms used across this documentation. If you want depth, each entry links to the page that covers the concept in full.

Sensor

The small Linux system service Imunify installs on each of your hosts. It intercepts system calls in the kernel, runs each one through your active rules, and reports the result to the Panel. See the Sensor section.

Event

A single record of something the sensor caught and made a decision on (allowed, blocked, or held for approval). Events stream from each host to the Panel and show up on the Events page. See Your first event.

Approval

An event whose matching rule says “ask the user before deciding.” The system call pauses on the host until you allow or deny it from the Panel, Telegram, or Discord, or until the rule’s timeout expires. See Approvals page.

Rule

One policy entry that describes what the sensor should do when it sees a given kind of activity — for example, “block any process that writes to /etc.” Rules live in the Panel and are pushed to your sensors over the gRPC stream.

Override

A permanent exception you create by clicking Allow Always or Deny Always on an approval card (or directly from the Overrides page). By default an override applies to all the sensors on your account; you can narrow it to one named sensor. Overrides survive sensor restarts.

Install token

A short-lived, single-use token that lets a fresh host register itself as a sensor on your Panel. You generate one from Add Sensor in the header dropdown; the host uses it once during install and it is consumed. See Install the sensor.

Sensor token

The long-lived credential each registered sensor uses to authenticate to the Panel after install. The format is sk-sensor-EXAMPLE. You should never need to handle it by hand — the installer writes it for you and the sensor presents it on every connection. See your Panel’s authenticated API documentation (Settings → API documentation).

User token

Your own long-lived API token for scripting the Panel. The format is sk-user-EXAMPLE. You hold one per account and use it as Authorization: Bearer ... against the REST API. User tokens cannot unlock encrypted content — for that you need a password sign-in. See the Authentication section of your Panel’s API documentation.

Protected agent

A process whose activity the sensor is actively scoping rules around. Typically your application or AI agent — the thing whose system calls you want to gate. The sensor names protected agents by their process command (comm) or executable path so rules can be scoped to them.

OpenClaw

The container runtime Imunify primarily targets in the current release. When you see “OpenClaw container” or “OpenClaw replica” in the docs, that is the workload your sensor is watching from the host side. The Panel exposes an OpenClaw-specific plugin for richer in-process visibility.

Enforcement tier

How the sensor enforces a decision on the host. Tier 1 — the only supported tier today — uses LSM BPF and synchronous seccomp notification, which lets the sensor block or kill the offending syscall in real time before it executes. The older fallback tracepoint tier no longer ships.

Unlock

The act of decrypting your private content key so the Panel can show you event and approval content. After sign-in, the Panel prompts you for your password again to unlock; the unwrapped key lives only in server memory for the current sign-in session. See Encryption — User view.