The OS support matrix, in depth — and what the labels actually mean

The <a href="/en/supported-os/">Supported OS page</a> publishes the per-platform table. This page defines the labels behind it, because a matrix without definitions is a marketing table. Capability levels are set by current engineering tests, not intentions: FULL, LIMITED, UNAVAILABLE — plus PLANNED for rows that are on the roadmap and not shipped.

Definitions, one level at a time

• FULL — the capability works on this platform in the shipped build, at the stated privilege level, with the observation actually reaching disk
• LIMITED — it works, but with a named constraint: typically a polling cadence instead of real-time events, or richer output behind an optional elevated session
• UNAVAILABLE — we do not claim it; the row is empty on purpose
• PLANNED — a roadmap item for this platform; nothing here pretends the code exists today

How the three platforms differ, in one paragraph each

• Windows: user-mode observation runs without admin rights; an ETW kernel session (admin, optional) widens network visibility. Kernel-level pre-action protection is a planned row. SmartScreen guidance and the unsigned-by-budget reality are on the install guide.
• macOS: zero-privilege libproc polling is what ships today; real-time events wait on the Apple EndpointSecurity entitlement path, which is approval-gated and pending. The Intel build row stays marked pending verification until a field report exists.
• Linux: a single static binary reading procfs in user mode; auditd can widen kernel-event coverage; eBPF enforcement is the deliberate Phase-2 step.

Why the gaps stay visible

Every OS update runs compatibility contract tests — API, enforcement, performance, recovery — so an OS update must never force a core rewrite. When a row moves from LIMITED to FULL, or PLANNED to shipped, the table moves first; changelog entries follow. A capability that is missing is stated as missing on the same page where its siblings are advertised — that symmetry is the point.

For the per-agent side of the same question (integration depth differs by agent family, not just OS), see <a href="/en/supported-agents/">supported agents</a>. To run any of this against your own platform, start with the <a href="/en/docs/install/">install guide</a> or the quiet, no-service route in <a href="/en/docs/install-quiet-uninstall/">install and uninstall without leaving a service behind</a>; the current build line and checksums are on the <a href="/en/download/">downloads page</a>.