AI Defence / How it works
Follow one finding from observation to review.
A fictional Linux host, lab-web-01, has a service configuration that differs from its agreed baseline. The following example explains the development workflow. Every asset, event and result shown is synthetic; no security operations are performed.
The whole sequence
Start with the evidence, then review the proposed response. The sequence below is readable without opening any technical detail. It shows the implemented collection concept and the operator-led steps needed to evaluate a change.
- 01
Observe
Collect permitted host facts and selected changes.
Linux development code - 02
Evaluate
Apply local rules; review the finding in context.
Rules and heuristics - 03
Decide
Assess impact and authorise a supported response.
Operator / agreed process - 04
Validate
Compare post-change observations and coverage.
Central package under review - 05
Review
Keep unresolved evidence visible in the decision.
Illustrated operator workflow
01 / Observe the authorised host
The Linux collector gathers permitted system and service configuration. Its periodic monitor observes a configuration digest change on lab-web-01. The fictional record has an asset name, observation time and source so a reviewer can identify what was observed.
The current implementation samples selected inputs. It is not a record of all processes, every file modification or all traffic. Missing permissions or a disconnected transport must be considered when interpreting an apparently quiet host.
What this stage collects
Host inventory and selected configuration, process, file-integrity and authentication-log observations. The exact selected files, available records and permissions belong in the pilot scope. File hashes do not imply collection of complete file contents, but the wider collectors and logs may still contain sensitive information.
02 / Evaluate the signal
Local rules and heuristics evaluate the observed posture. In this synthetic example, the service configuration warrants review because it differs from the expected state. A structured finding explains the condition and recommends checking whether the change was authorised.
A changed setting is not proof of an intrusion. The reviewer compares it with release records, maintenance work and the service’s business purpose. The source does not establish an AI model detecting this event, so this walkthrough does not attribute the finding to AI.
03 / Review context and the proposed response
The reviewer establishes the affected workload, intended configuration and legitimate dependencies. If the change was expected, the record needs that context. If a correction is appropriate, the proposal should state the target, expected outcome and possible disruption.
The development validation package can represent checks and evidence requirements. It does not remove the need to assess gaps in available modules. An independent network check that has no production implementation cannot be presented as completed.
04 / Decide what is allowed
The proposed action is reviewed against the agreed scope. A supported typed action still needs the configured authorisation boundary. Work outside the implemented action set stays with an authorised administrator. The example Linux configuration has remediation disabled.
For this walkthrough, the administrator reviews the recommendation and performs any agreed maintenance through their established change process. Clicking through the tour only changes the illustrative display. It grants no authority and sends no command.
05 / Containment and isolation: define the actual boundary
No verified end-to-end AI Defence endpoint isolation-and-release implementation was established for this website. The walkthrough therefore does not show the product disconnecting lab-web-01. Where containment is required, the organisation must use its existing authorised controls and agreed operational procedure.
Network isolation restricts communication. It does not itself restore files, reverse encryption or prove that propagation has stopped. Any future supported isolation workflow needs a defined scope, a surviving management path, status and failure reporting, and an authorised release procedure.
06 / Compare post-change evidence
After a permitted correction, collect the relevant configuration again and review service health through approved tools. Compare the actual result with the expected outcome. A successful change command alone is insufficient to establish resolution.
In the tour, the local result is “pass” but independent network evidence is “unavailable”. The display keeps the case unverified. This illustrates the intended evidence discipline; it does not claim the current central engine’s closure controls are fully proven.
07 / Recover, review and keep the record
Recovery in this example means the administrator follows an agreed recovery plan if maintenance affects the service. The implementation has remediation and rollback structures, but a production restore, backup integration and encrypted-file restoration are not established capabilities.
Retain the finding, decision, action record, post-change evidence and remaining uncertainty. An accepted risk is a decision about a remaining condition; it must be distinguished from a verified technical correction. The unified analyst workflow shown in the tour is illustrative.
Talk directly to Altari
Bring the environment.
Start with the right questions.
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.