Skip to main content
This guide describes the Hilt macOS Collector: a notarized macOS app that extends Hilt’s endpoint detection and response coverage from Linux servers to employee Macs, what it observes, how it’s deployed standalone or through MDM, and how it integrates with the Hilt data-plane you received separately.
The macOS collector is in early access. The notarized .pkg with System Integrity Protection (SIP) left enabled, described throughout this guide, is the target shipping model. Capabilities and configuration may change, and some features available on Linux (auto-update, on-device quarantine response) are not yet available on macOS. Contact your account team to enable it for your deployment.
In bundle identifiers, service names, and Kafka topics you may see the prefix edr or dag.endpoint.* (e.g. Hilt.EDRApp.ESensor, dag.endpoint.exec). This is the internal codename of Hilt’s endpoint telemetry engine and is functionally equivalent to “Hilt macOS Collector” throughout this documentation.

What is the macOS collector

The macOS collector is a single notarized macOS application, Hilt EDR (bundle EDRApp.app, signed by team Cybe Corporation / MVMB6LCP2A), that embeds two Apple System Extensions. Everything runs in user space on Apple’s modern frameworks — there is no kernel extension (kext). The key story is what makes this possible on a normal, hardened Mac:
  • Restricted entitlement, granted by Apple. ESensor uses the restricted entitlement com.apple.developer.endpoint-security.client, which Apple granted to the Cybe Corporation team.
  • Signed, profiled, hardened, notarized. The app and both extensions are signed with a Developer ID Application certificate, carry an embedded provisioning profile that authorizes the ES entitlement, use the Hardened Runtime, and are notarized and stapled by Apple.
  • SIP stays on. Because of the above, the collector runs with System Integrity Protection (SIP) enabled — no csrutil disable, no developer mode, no third-party kext approval. This is the headline: a normal, hardened Mac.
  • No App Sandbox on the ES extension. The ES extension must not use the App Sandbox; doing so makes es_new_client fail with ERR_NOT_PERMITTED.
Once installed and approved, ESensor emits events as JSON lines, a small forwarder LaunchDaemon ships them over outbound HTTPS to the Hilt edr-collector, and they land in the same dashboard you use for Linux hosts — with a macOS host-type badge in the Collectors fleet and full presence in the Investigate, Networks, Files, and Users views. See End-to-end data flow for the full pipeline.

The macOS differentiator

Unlike the Linux collector, every macOS event carries code-signing trust and application attribution as first-class fields:
  • Code-signing trust: code_signature verdict (platform | developer_id | adhoc | unsigned_or_invalid), signing_id (e.g. com.google.Chrome), team_id (Apple developer Team ID), and cdhash (binary integrity hash on exec).
  • Application attribution: application_id and application_display_name (helpers fold to the owning app, e.g. “Google Chrome Helper” becomes “Google Chrome”), responsible_pid (Apple ES “responsible process”), session_id (per app-instance session), and device_name (the human Mac name).
This means a query like “which unsigned app read ~/.ssh” is a single WHERE clause — something the Linux collector cannot express. See the Event data model and Event coverage for the full field and event catalogs.

What the collector does not do

The macOS collector is overwhelmingly observational (NOTIFY telemetry). It does not:
  • Read file contents. It captures only metadata — path, operation type, size, and the signing/attribution fields above. It never opens or reads the bytes of your files.
  • Log keystrokes or capture screen content. There is no screen recording and no keylogging. Paste detection uses a listen-only event tap scoped to Cmd+V: it never modifies the keystroke and never records or transmits key content. Detecting paste does require macOS Input Monitoring, whose system prompt reads “would like to receive keystrokes from any application” — that is Apple’s wording for the permission, not a description of what Hilt records. See Clipboard and data movement.
  • Block, modify, or quarantine arbitrary activity. Telemetry is overwhelmingly NOTIFY — the collector does not perform inline user/process/network blocking or on-device quarantine of arbitrary activity. Exception: a small AUTH set (signal, file_unlink, file_rename) denies unauthorized kill/delete/rename of the agent itself in-kernel; those denials surface as blocked findings. See Event coverage and Tamper detection. NetFilter observes flows for attribution without dropping or rewriting them. Console-driven on-device quarantine response is not yet available on macOS during early access.
  • Capture packet payloads. Network events carry connection metadata only — destination, ports, byte counts, and the owning bundle id — not the contents of the traffic.
  • Install a kernel extension. Everything rides Apple’s user-space System Extensions on the Endpoint Security and NetworkExtension frameworks. There is no kext, no csrutil disable, and SIP stays enabled.
  • Expose network services. The collector only makes outbound HTTPS to your configured ingest endpoint. There are no inbound sockets.
  • Perform external callbacks. No license checks, telemetry beacons, or “phone-home” behavior. The only outbound communication is the configured event stream.

Clipboard and data movement

The metadata-only rule above has one deliberate exception, and it is the most invasive thing the collector does. It is called out here rather than buried in a table. The macOS agent includes a clipboard sensor, and it is on by default: By default the copied content itself is stored, not only its metadata — which on a real endpoint means passwords, API keys, and personal data pasted by your users will be written to your Hilt deployment. Content is classified on-device (secret / pii / none) and the classification is always recorded; the raw text is what this setting controls. Mitigations, all on by default:
  • Raw content is returned by the API only to a global administrator, and truncated.
  • Raw content carries a 30-day column lifetime, shorter than the 90-day event retention.
  • The content is stored once, on the copy — not repeated per paste.
To collect clipboard metadata only — app, timing, size, SHA-256, and the on-device classification, with no raw text — set the managed preference clipboard_capture_content to off in the ai.hilt.edr domain. To disable the clipboard sensor entirely, including the Input Monitoring prompt, set clipboard to off. Both are delivered by your MDM.
Per-person control of these features from the Hilt console — so a given Mac is never granted the permission or prompted for it — is in development. Until it ships, the settings above are machine-wide and applied through your MDM.

AirDrop

AirDrop transfers are detected from ordinary file activity by the sharingd system service — both files received and files sent. This requires no additional permission and no additional collection: it is derived from file metadata the collector already reports. The receiving device is recorded as a display name where one is visible, which is not a verified identity.

In this guide

Last modified on October 8, 2026