The Edge agent is packaged for Windows x86-64, Linux x86-64 and Apple Silicon macOS. It collects native telemetry, runs deterministic detection and can isolate a host when a high-confidence ransomware policy fires. Non-ransomware response remains approval-gated. The agent can buffer while disconnected; a fully self-hosted, air-gapped platform remains on the roadmap.
The agent uses a common codebase with platform-specific collectors and packaging. Supported release channels are explicit: Linux x86-64, Windows x86-64 and Apple Silicon macOS. Package support and collection depth still depend on the operating system and host configuration.
Native Windows Event Log subscription with bookmarks and resubscription, including Sysmon and other configured channels. Delivered through a customer-scoped MSI.
eBPF process monitoring where supported, with an audit-based fallback, plus journald and Syslog collection. Delivered as customer-scoped DEB and RPM packages.
macOS collection and posture checks delivered through the customer-scoped package workflow. Required permissions are managed through the deployment profile.
Supported hosts continue deterministic evaluation and buffer telemetry when the cloud link is interrupted, then resume transport after reconnection.
Remote sites, manufacturing networks, maritime operations and other segmented estates cannot assume a continuous cloud path. Edg3 keeps deterministic controls on the host and returns buffered evidence to the tenant when connectivity resumes.
Ransomware is the only response class enabled for autonomous isolation by default. A high-confidence ransomware verdict can move the host into its platform-specific isolation state without a cloud round trip. Lower-confidence signals wait for central correlation; other response classes remain approval-gated.
Endpoint evidence is evaluated against the active deterministic rules and the configured autonomous-isolation confidence threshold.
A high-confidence ransomware verdict can trigger the local isolation path. A marginal signal is held for the bounded central-decision window.
The platform-specific firewall path restricts host connectivity while retaining the Edg3 control path needed for review and recovery.
Isolation transitions are written to the local state and published through the offline-capable response path for the tenant investigation timeline.
The analyst can confirm or clear the action. An enabled deadman restores connectivity after its configured offline or absolute backstop if control is not re-established.
Autonomous response beyond ransomware is a shorter-term cost saving and a longer-term incident. An agent that quarantines the wrong account at 03:00 is the kind of story that ends product evaluations. Edg3 therefore keeps the default autonomy surface narrow and routes other response workflows through explicit approval.
Non-ransomware workflows are designed to require an explicit approval decision. The available action and evidence record depend on the integration configured for that tenant; approval identity and workflow state stay attached to the orchestration record.
| Action | Default mode | Typical approver | Audit artefact |
|---|---|---|---|
| Ransomware containment | AUTO | · (platform) | Isolation state + response event |
| Host isolation | HUMAN | SOC tier-two | Approval + operator identity |
| Credential revoke / session kill | HUMAN | SOC tier-two + IAM team | Workflow approval record |
| Firewall / DNS block | HUMAN | Network operations | Workflow and provider result |
| Endpoint reimage | HUMAN | Endpoint operations manager | Workflow and provider result |
| Cloud resource quarantine | HUMAN | Cloud-platform owner | Tenant approval + provider result |
The rows above describe the intended gate, not a guarantee that every provider action is enabled in every tenant. Customer configuration and integration readiness determine which approval-gated actions can be dispatched.
Edg3 orchestration flows are YAML and version-controlled. Changes can be reviewed as code, and the flow definition exposes the trigger, approval gate and downstream action without a separate proprietary workflow representation.
Slack approval and notification flows are present in the orchestration layer. Other provider actions are enabled only after their tenant credentials, permissions and failure behaviour have been validated.
The current provisioning workflow creates an isolated AWS-backed tenant and its supporting services. Additional hosting models should be treated as roadmap until tested.
Customer-scoped Windows MSI, Linux DEB/RPM and macOS package workflows produce the installer paths used during onboarding.
A full offline installer with bundled models, signed images and update channel is on the roadmap — update cadence controlled by your SCIF policy, not our release train.
A customer-operated control plane in a chosen environment, with its own release and update channel, is on the roadmap.
A security agent with a large privilege surface is itself a high-value target. Edge is architected on the assumption that the next supply-chain attack will target a vendor like us. The mitigations below are the baseline, not the premium tier.
Security evaluation should include package provenance, tenant messaging scope, update rejection, offline behaviour and isolation recovery. Ask the product team for the current validation evidence for the release you intend to deploy.