AI Defence / Controlled remediation
Define the action before granting authority.
The Linux implementation contains registered remediation primitives and a signed-command interface. Remediation is disabled in the supplied example configuration. Supported code and a proposed action are the beginning of evaluation; they do not establish safe operation in a customer environment.
Recommendations and executable actions are different
A finding can recommend that a setting, package or service be reviewed. It does not mean the agent has a matching executable action, permission to use it or a tested recovery path. The operator needs to identify the exact supported action and target.
The development approach uses typed, registered operations with configuration and authorisation controls. It does not present an AI-generated suggestion as permission to run arbitrary commands. No execution capability is exposed by this public website.
Make the decision reviewable
Before considering a material change, describe the present condition, intended result and likely effect on the workload. Identify dependencies, administrator access and the procedure if the action fails. A service restart or permission correction can affect legitimate work.
The agreed process must distinguish proposed, authorised, attempted, failed and verified states. A customer’s approval applies to its stated scope. If the environment or assumptions change, the operator needs to reassess rather than infer an open-ended instruction.
What the inspected implementation establishes
The Linux branch contains remediation structures and local action handling. Example configuration gates the capability off. The code also contains verification and rollback-related structures, but live action execution, every error path and dependable reversal were not checked for this website.
The separate Remedy Agent defines allowlisted runtime actions such as approved service or container restarts. Those belong to Remedy’s implementation and policies; they are not evidence that AI Defence currently performs every hardening, isolation or recovery operation.
Containment and endpoint isolation
A complete AI Defence isolate, retain-management, report-state and release sequence has not been substantiated. The site therefore does not claim automatic device isolation or imply that a simulated button protects a real host.
If such functionality is proposed for a pilot, establish exactly which communication is restricted, what remains reachable, who can release the restriction and what happens if the action fails. Connectivity restriction does not itself reverse encryption or guarantee that an incident is contained everywhere.
Recovery and verification
A rollback description is guidance about how a change might be reversed. A tested rollback mechanism, service recovery, restored connectivity, backup restoration and decryption are separate capabilities. The current evidence does not establish them as a complete AI Defence recovery service.
After a permitted change, review the relevant host state and required workload behaviour. Missing independent validation must remain part of the decision. Unresolved central validation review findings mean a guaranteed production closure rule cannot be asserted.
From policy-approved automation to evidence of repair
Remedy’s wider architecture joins detection, trust decisions, permitted action and verification. Automation is most useful when the action is supported, narrowly scoped and permitted by current tenant policy. A higher-impact operation needs an approval appropriate to its consequences.
A material state change can invalidate an earlier approval or its assumptions. The action should then be reviewed against the current target and policy. After corrective work, fresh checks inform whether the condition is resolved and whether restricted authority can be restored.
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.