AI Defence / Frequently asked questions
These answers reflect the inspected implementation and documented limits. Product availability must be established for the exact candidate deployment.
AI Defence is being developed to connect Linux security assessment, periodic monitoring, controlled remediation and central evidence validation. The inspected code is on a review branch; an integrated production release has not been verified.
The Linux implementation uses deterministic local rules, heuristics and periodic observations of selected configuration, process, file-integrity and authentication-log data. The limited advisory set is not a complete live CVE feed. A suspicious observation needs context and is not proof of compromise.
Containment restricts the ability of an affected system or account to communicate or act. A verified end-to-end AI Defence containment implementation was not established here; any current response must use supported, authorised controls and an agreed procedure.
No replacement capability is claimed. Keep the endpoint protection, monitoring, backup and operational controls required for your environment. A future integration or overlap needs to be evaluated against the exact implemented functions.
The documented direction is central assistance with reasoning and recommendations. The inspected planner accepts an advisory recommendation, but an active AI Defence model, provider and data flow have not been verified. Linux collection and the described checks use code-defined logic.
The inspected implementation contains Linux host assessment and monitoring code. A production distribution/version matrix has not been established. Windows and network production validation probers are explicitly unavailable in the reviewed source.
The Linux component performs local collection, periodic monitoring, assessment and report generation. Configured shared transport can send heartbeat, inventory, findings, reports and observations centrally. Registered local remediation requires separate configuration and authorisation.
Shared transport includes offline queuing code. Its capacity, restart durability, retention and successful replay need testing in the actual deployment. A disconnected host or missing heartbeat must not be interpreted as a clean security result.
The intended model keeps the operator’s authority separate from recommendations. The Linux example disables remediation, and registered actions have configuration and authorisation requirements. A complete, production-verified approval interface for AI Defence has not been established.
A working AI Defence isolation-and-release path has not been verified, so no product-specific reversal procedure is published. Any isolation capability considered for a deployment must demonstrate its scope, management access, release authorisation and failure handling first.
The development code contains remediation and rollback structures and descriptions. It does not establish a working backup restore, universal rollback, encrypted-file restoration or ransomware decryption service. Recovery responsibilities and tested mechanisms must be agreed for the proposed actions.
When configured, the Linux transport can publish heartbeat, inventory, findings, reports and observations. These can include sensitive operational or personal context. The example disables transport; the exact enabled fields and recipients must be reviewed before delivery is enabled.
Local assessment runs on the host; central delivery requires a configured endpoint. Customer hosting, storage location, retention and any AI provider are not established by the public website and need agreement for the actual deployment.
The inspected source has structured reports and generic HTTPS messaging. No built and tested native AI Defence SIEM connector was verified. Remedy has separate host-management services and a dashboard; security-engine integration requires its own evidence.
A pilot needs an agreed candidate build, supported hosts, collector permissions, certificate provisioning, telemetry endpoint and an operator review process. Updates, rollback, central-service integration and maintenance ownership must be confirmed for the engagement.
Altari supplies AI Defence directly. Support hours, escalation routes, maintenance responsibilities and commercial terms are agreed for the scope; this website does not promise a fixed SLA or a managed 24-hour SOC.
Contact Altari to discuss a bounded evaluation, beginning with the available Linux collection and reporting functions. The pilot should specify what runs, what is simulated, what is unavailable and which evidence will be used to judge the outcome.
Glass is the planned external-content isolation layer, using task-level minimum authority for uncertain attachments, downloads, scripts, removable media and higher-risk browsing. Outputs need a separate promotion decision.
The intended Continuous Integrity model evaluates the new fingerprint and its lineage. Normal authorised edits can use a lighter revalidation path; unexplained changes do not automatically inherit the previous certification.
Adaptive Network Trust includes restricted enrolment/remediation paths in the planned architecture. Complete production admission, containment and release workflows have not been established.
Addresses can change, be shared or be spoofed. They are contextual signals alongside stronger enrolled identity, device posture, authenticated session and behaviour.
No. User authentication and device health are independent. The design requires the relevant posture and action conditions as well as appropriate authentication.
No. Production access is denied first. Selected suspicious interaction may be observed using isolated synthetic resources with no production data, useful credentials or route back into production.
No. The planned router uses current certification, provenance, risk and policy to choose an appropriate fast path, analysis, isolation or block.
Talk directly to Altari
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.
