Skip to main content
The macOS collector embeds an on-device detection engine that evaluates kernel events as they happen. This section describes what that engine looks for and how findings reach the console. For raw telemetry, see Event coverage. For console hubs that display related activity, see Malware, Collectors (Credentials / Files tabs), Networks, and Overview.

Where detection happens

Detection runs on the endpoint, inside ESensor, before events leave the Mac. Because the engine sits on Apple’s Endpoint Security AUTH path, it can deny an operation in-kernel rather than only report it afterward. Every evaluated event carries code-signing trust and application attribution — rules grade who is acting, not only what happened.

Rule families


How the agent responds

Severity scales with the actor’s code-signing verdict. The collector protects its own app bundle and extensions — unauthorized kill/delete/rename attempts are denied in-kernel and surfaced as blocked tamper findings. Authorized MDM removal paths remain allowed; see Uninstall.

Shared finding layout

Findings typically include: What happened · Process responsible · What was touched · Why it matters · Evidence · Recommended action, plus severity/status and the responsible app’s trust verdict.

Kernel foundation (why macOS rows look different)

Every Endpoint Security event can carry:
  • Code-signing identity — platform, Developer ID, ad hoc, unsigned/invalid
  • Application attribution — owning app, not only comm
That is why persistence and tamper severity can be driven by who acted. Details: Event data model.

From finding to dashboard

Findings use the same authenticated ingest path as telemetry. Triage them in Malware and deep-dive evidence in Logs (macOS scope).
Detection rules ship with the collector and are versioned. The policy version on agent headers records which rule set a Mac is running.
Last modified on October 8, 2026