DemoLog inContactDE
Native Endpoint Governance

Every dispatch is a signed write. Every failure is a logged refusal.

Jamf macOS, Intune Windows and Kandji wrapped in one deterministic dispatch plane — circuit-broken, evidence-captured, WORM-recorded. Native MDM, not a passive inventory dashboard.

See the dispatch planeBook a demo

Why most MDM dashboards lie quietly

Generic endpoint consoles paint a device green from the last inventory pull, even if the live MDM API just refused the write. When the auditor asks "did this command actually land?", the dashboard has no answer — only a colour. Lojycal's plane refuses to ship that ambiguity.

The 3-step deterministic dispatch model

[ DISPATCH REQUEST ] ──> [ CIRCUIT-BREAKER + EVIDENCE ] ──> [ WORM AUDIT LEDGER ]
                          - 5-fail OPEN / 60s HALF-OPEN     - mdm_dispatch_failures
                          - Vendor raw evidence captured    - audit_log row signed
  1. Step 1
    Dispatch request

    Admin or automation issues an MDM action. Pre-flight reachability is checked per platform before fan-out (cap 5 in flight per vendor).

  2. Step 2
    Circuit-breaker + evidence

    withCircuitBreaker gates the call. Vendor raw response (Classic + v2 for Jamf) is captured into the dispatch flight panel for every device.

  3. Step 3
    WORM audit ledger

    Success writes the action to audit_log via AFTER trigger. Failure writes to mdm_dispatch_failures. Both rows are immutable — worm_block_mutation triggers reject UPDATE and DELETE for everyone, including platform admins.

What the plane guarantees

Dispatch is gated, not guessed

Every MDM write to Jamf, Intune or Kandji is wrapped by a circuit-breaker — 5 consecutive failures trip OPEN, a 60-second cooldown forces a HALF-OPEN probe before the plane resumes. Dead vendor APIs cannot be silently retried into a fleet.

No force-green fallbacks

If the live vendor write fails, the UI surfaces the failure with the raw Classic and v2 evidence. Cached config_profiles, lastContactTime or last-known device state never override a red verdict. The constraint is hard-coded across Jamf and Kandji adapters.

Every failure is auditable

Failed dispatches land in the mdm_dispatch_failures WORM table via recordDispatchFailure — vendor, command, attempt, raw response, breaker state. The same row feeds the dispatch board and the auditor's evidence pack.

Native refresh paths only

Jamf inventory uses a managed jamf recon policy (vendor confirmed the Classic and v2 APIs reject remote inventory writes). Kandji uses native blankpush; Intune Windows uses a managed Entra group, ephemeral deviceManagementScripts and syncDevice.

Webhook integrity

The Kandji webhook requires HMAC verification, UNIQUE(org, event_id) dedupe and a ±5-minute occurred_at skew window. Replays and spoofed payloads are rejected before any row mutates.

Daily drift verification

kandji-blueprint-verify-daily runs at 03:30 UTC, writes a verification row and emits a kandji.blueprint.drift_detected audit event the moment a blueprint diverges from its expected state.

Governance on by default

  • Per-org RLS via is_org_member / has_org_role — no cross-tenant device reads.
  • AAL2 required for privileged actions where the org sets force_mfa.
  • Vendor secrets (Kandji webhook, Jamf OAuth) live in dedicated secret tables with REVOKE SELECT from authenticated.
  • Dispatch failures are WORM — blocked from UPDATE and DELETE for everyone, including platform admins.
  • No force-green: failed live writes never inherit a green verdict from cached state.
  • Every action emits an audit_log row via AFTER trigger — actor, target, before/after.

Native endpoint governance, not a passive console.

One dispatch plane across Jamf, Intune and Kandji. One ledger your auditors can quote verbatim. Zero room for a green tile to hide a failed write.

Book a demoBrowser EndpointsSee pricingSee Browser Endpoints