Core. Glass. HQ. One measured trust model.

What the platform is for

A host can look correctly configured while a service remains exposed. A successful maintenance action can leave the original problem unresolved. AI Defence’s central idea is to connect a security observation to a scoped recommendation, an authorised response and relevant post-change evidence.

The source reviewed for this website contains a Linux agent and a central validation package. These are development components on a review branch. An integrated production release, customer deployment and complete multi-platform coverage have not been established. The capability guide separates implemented source, configuration dependencies and planned work.

How the components connect

The Linux component gathers local facts and produces findings. Shared packages provide reporting, message transport and supporting controls. The central validation package defines checks and brings their results together. Each layer has a distinct responsibility; a collector result is an input to a decision.

The Linux component: evidence close to the workload

The Linux agent runs on a Linux host. Its collector dispatcher covers system, users, network, services, storage, security, applications, cloud-related configuration, containers and processes. Collection depends on what the host exposes and the permissions granted to the process. A collector category is not a promise to discover every cloud resource or every machine on a network.

The agent can perform an initial assessment and repeat it on a configured schedule. A separate monitoring loop samples selected file integrity, process, authentication-log and configuration signals. It produces observations, findings and reports for review. This is periodic sampling, not a complete recording of every endpoint event.

Shared services: communication and reporting

The shared messaging implementation contains HTTPS transport, certificate configuration, signed message envelopes and an offline queue. The Linux agent can publish heartbeat, inventory, findings, reports and observations through that transport.

The supplied example configuration disables transport. Enabling a real deployment requires an ingest endpoint, provisioned credentials and certificates, agreed data handling and validation of delivery. The offline queue is a code capability; capacity, durability and delivery after a long outage still need operational acceptance.

Central validation: compare the result with the requirement

The central package includes a module catalogue, planning, evidence correlation, lifecycle records and audit-related components. A deterministic planner accepts advisory recommendations within its checks. The intended workflow compares the evidence with the security property that a change was supposed to establish.

Cross-platform validation remains incomplete. Windows and network production probers are explicitly unavailable in the reviewed source. Later review material also records unresolved issues in evidence verification, observer matching, closure and durable recovery. This website does not present the central package as a proven production closure guarantee.

The relationship with Remedy

Remedy is the related Altari platform for software repair and runtime operations. Its separate implementation includes host registration, pairing, heartbeat, scoped evidence and a host-management dashboard. Those are useful foundations, but their existence does not establish that the AI Defence security engine is wired into that dashboard.

The product tour illustrates the security workflow with synthetic data. It does not show a live AI Defence console. Altari supplies AI Defence directly and can discuss the current implementation and integration evidence for a proposed pilot.

Remedy Core: the host and its permitted actions

Core is the architectural role for endpoint and server posture, selected telemetry, identity, containment, registered corrective actions and recovery coordination. Windows endpoints, Windows servers and Linux workloads have different supported mechanisms and operational needs.

The inspected Linux implementation provides local collection and periodic selected observations. The broader Core name does not turn the planned Windows, network enforcement and recovery functions into released capabilities. Each candidate deployment needs its own supported scope.

Remedy Glass: authority around an external task

Glass is the planned isolation layer for attachments, downloads, removable-media files, scripts and higher-risk browsing. It is intended to route content using provenance, certification and risk, then grant only the temporary resources appropriate to the task.

Outputs need a separate promotion decision before entering trusted storage. Internet Glass and Document Glass have different connectivity and file-access needs; neither should automatically inherit the full authority of the employee’s workstation.

Remedy HQ: explain and govern the shared decision

HQ is the intended policy, evidence, incident and orchestration layer. An administrator should be able to see the previous and current state, why trust changed, what was held or isolated, which action was authorised and what remains unresolved.

A shared view should connect integrity changes, device posture, network context and validation without hiding uncertainty. The separate Remedy host dashboard is a useful foundation, but its existence does not establish a fully integrated AI Defence console.