Begin with a bounded, evidence-led pilot.

What can be evaluated now

A scoped Linux assessment is the clearest starting point in the inspected implementation. Define a small set of authorised hosts and questions that their available collectors can answer. Begin with observation and reporting before considering any action capability.

No universal Linux version matrix, minimum CPU or memory specification, production performance benchmark, Windows endpoint deployment or turnkey network sensor is asserted here. Establish those requirements against the candidate build and the actual workload.

Where the parts run

The Linux component runs on the assessed host. Shared messaging can send structured information to a configured central endpoint. Central validation is represented by Go packages; that alone does not establish a packaged hosted service or an integration with the running Remedy SaaS application.

Self-hosted, Altari-hosted and hybrid arrangements should be discussed as deployment requirements until a particular model is confirmed with a working installation. Customer data residency and external AI processing must be agreed independently of where the public website is hosted.

Configuration and enrolment

The example Linux configuration keeps transport and remediation disabled. Collector selection, audit and monitoring intervals, endpoint configuration, certificate and key provisioning must be set deliberately for a pilot. Example values are not a production configuration.

The Linux identity package reads configured certificate information; issuance, rotation and revocation are delegated to the platform. The related Remedy Agent has a separate implemented pairing lifecycle, but a unified AI Defence enrolment path has not been verified. These integration responsibilities need an owner before rollout.

Connectivity and offline behaviour

Telemetry transport uses a configured HTTPS destination and contains offline queuing code. Determine the required outbound connectivity and the permitted recipients of evidence. Network discovery or validation needs separately authorised targets and bounds.

Test disconnected operation, queue limits, restart persistence, reconnection, stale observations and delivery failure in the candidate deployment. The presence of a queue does not establish unlimited offline retention or guaranteed delivery. Local observations made during an outage are not automatically evidence that central operators received them.

Integration status: distinguish the interface from the connection

The inspected Linux implementation has structured reports and a messaging interface. A format or interface is a starting point for integration; it is not a tested vendor connector.

From pilot to rollout

Use an agreed candidate build and inventory the hosts in scope. Record the observed capability coverage and which settings are enabled. Compare a representative report with the actual host state before adding more systems.

Any active change should be introduced as a separate pilot step, with an authorised operator, maintenance constraints and recovery evidence. Extend the deployment only after supported platforms, telemetry, permissions and failure behaviour are understood. This is a proposed evaluation method, not a claim of completed customer rollouts.

Maintenance, access and support

Agree who owns host installation, credentials, configuration, operating-system updates, service health and review of findings. An update process needs version identification, release evidence and a way to recover from a failed update; a proven automatic AI Defence fleet updater has not been established.

Altari supplies the product directly. Pilot scope, commercial terms, support hours, escalation paths and maintenance responsibilities are agreed for the engagement. No fixed SLA or around-the-clock managed security service is promised on this website.