AI Defence / AI & operator controls
AI can advise. Authority needs explicit controls.
The product name does not establish which decisions use an AI model. The inspected Linux assessment uses deterministic rules and heuristics. The central planner accepts advisory recommendations; a connected AI Defence model and production data flow have not been verified.
What is implemented without an AI model
Linux collection, periodic monitoring and the limited vulnerability rules inspect available facts using code-defined logic. Findings carry structured explanations and recommendations. These functions should not be described as model-trained behavioural detection or attributed to a proprietary AI.
The central planner represents an explicit decision boundary around a recommendation. That is useful architecture: an advisory suggestion can be checked against registered capabilities and scope. It is not evidence of a deployed AI assistant.
The intended AI role
The documented direction is central assistance with reasoning, explanations and proposed checks or responses. Local adapters collect evidence and carry out supported typed operations. The design keeps policy and cryptographic authorisation separate from a model’s recommendation.
An AI-generated explanation must be treated as an interpretation of evidence. It should not upgrade an unavailable check to a pass, invent an observation or grant itself authority. These are design requirements, and unresolved review findings mean the complete enforcement chain is not presented as proven.
What information a model receives
An actual AI Defence provider, model, prompt pipeline and configured input set could not be established from the inspected evidence. It would be inaccurate to claim that all processing remains on the endpoint, or that a particular external provider receives no customer information.
Model inputs, privacy terms and deployment location need to be agreed before AI-assisted processing is enabled. The related Remedy model adapters belong to a separate implementation and do not resolve this question for AI Defence.
Human review, uncertainty and unavailable services
The operating model distinguishes a recommendation, an approved action, an attempted action and a verified outcome. The operator needs the scope, evidence, likely impact and available recovery procedure before authorising a material change.
The source does not establish a complete AI Defence user interface for overrides, a production model-outage policy or a fully tested fallback. Until that is demonstrated, no automatic response should be inferred from a generated recommendation or from this illustrative tour.
Deterministic controls handle defined conditions
A cryptographic mismatch, revoked device certificate, prohibited network path, known malicious hash, invalid signature or failed posture requirement can support a defined policy action without waiting for an AI interpretation. Decoy interaction can similarly produce evidence for a bounded response.
The architecture should preserve its intended protective behaviour when an external AI service is unavailable. Local containment and current policy must not disappear simply because an advisory model cannot be reached. Actual failure behaviour requires acceptance evidence.
Use AI where ambiguity benefits from analysis
Potential advisory inputs include scripts and macros, JavaScript, PowerShell, decompiled routines, suspicious imports, process trees, embedded URLs and bounded behavioural traces. AI may help explain a finding, correlate context, summarise an incident or recommend further investigation.
An AI output is evidence to evaluate, not an infallible malware verdict or permission to run an arbitrary command. Known bad content need not execute for analysis. Where uncertainty remains, supported isolation and minimum authority offer a separate protective boundary.
Automation follows policy and supported capability
Low-risk, policy-approved actions can be candidates for automation. Destructive work, production changes, wipe/rebuild, restoration and major policy changes may require human approval tied to the actual target and impact.
The important loop is detect, decide, remediate and verify. The existence of a recommendation does not establish a matching action or a proven recovery path. These controls remain applicable whether the recommendation comes from a rule, a model or a human.
Questions answered
Talk directly to Altari
Bring the environment.
Start with the right questions.
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.