AI Defence / Remedy architecture
Remedy Defence is being designed as a security control plane around measured, scoped and revocable trust. AI Defence is the Altari Systems website and programme for that security work, spanning the local host, external content, identity, network and recovery lifecycle.
Remedy Core is the proposed endpoint/server layer for posture, telemetry, bounded enforcement and corrective work. Glass coordinates disposable isolation around risky external tasks. HQ is the intended central policy, evidence, incident and orchestration layer.
Continuous Integrity supplies measured object and application state. Network Trust supplies device and connection context. Zero Trust evaluates user, device and action requirements. Deception provides isolated defensive observations. Adversarial Validation checks the condition after remediation. These names describe the architecture; they do not assert that all components are released.
| Surface | Intended components | Principal role |
|---|---|---|
| Windows endpoint | Core + Glass where appropriate | Device posture and bounded external-content tasks |
| Windows server | Core-style server controls | Workload, configuration and access protection |
| Linux server | Core-style assessment and monitoring | Host evidence, registered actions and validation |
| Network and identity | Supported policy enforcement integrations | Scoped access, posture requirements and quarantine |
| Remedy HQ | Policy, evidence and orchestration | Explain decisions and govern the shared lifecycle |
Unknown or materially changed state does not automatically inherit broad authority. A familiar filename, valid account or recognised address is not enough to grant access in every other dimension. The policy asks which minimum capability is justified for the present task.
Deterministic conditions can produce immediate policy decisions: a mismatched fingerprint, revoked certificate, prohibited path or known malicious object. AI may assist analysis or explanation, but an external model must not become a prerequisite for the intended protective controls.
A security observation becomes more useful when linked to the user, device, session, application, document, embedded script, package, service and network context involved. The proposed graph also relates those objects to policy, incidents, remediation and evidence.
For example, a new network address alone is weak evidence. Combined with a changed device identity, failed posture and unexpected decoy interaction, it can justify a different review. The graph is a conceptual relationship model; this page does not claim a production graph database or fully integrated correlation engine.
The architecture can draw on established endpoint protection, malware scanners, remote browser isolation, content disarm and reconstruction, vulnerability assessment, identity providers, firewalls, backup systems, network access control and SIEM services. Each integration needs a supported contract, permissions and validation.
Threat intelligence can inform known malicious hashes, domains, URLs, address reputation, vulnerabilities and package risk. Remedy does not claim a proprietary database on the scale of global security vendors. The current Linux advisory implementation is deliberately limited; broad live feeds and the complete integration set are not established.
HQ is intended to show the previous and current state, when evidence changed, why trust was reduced, which task or connection was restricted, what was attempted and what remains unresolved. Policy versions, identity, timestamps, technical evidence and verification results make the record assessable.
The user experience should remain quiet when work is expected and supported by current evidence. When intervention is necessary, it should explain the reason in ordinary language. Illustrative messages such as “This device needs verification before accessing this resource” convey the decision without claiming a finished interface.
The proposed lifecycle measures state, grants bounded trust, monitors relevant changes, reduces or revokes authority, isolates uncertainty and coordinates authorised remediation or recovery. Fresh validation then informs a new certification or continued restriction.
Trust levels such as pending, changed, restricted, inconclusive and quarantined matter because uncertainty is operational information. Not every issue can be repaired autonomously, and higher-impact actions may require human approval. A local component should not be able to grant itself universal verified closure.
The inspected Linux development code includes host collectors, periodic selected observations, structured findings and registered remediation structures. Transport and action availability are configuration-dependent, and the integrated central workflow requires further proof. Validation packages exist with unresolved review findings.
Glass, broad Continuous Integrity certification, adaptive quarantine, integrated MFA/step-up, Deception and recovery orchestration are planned. Windows and network production probers are unavailable in the reviewed source. The product status page separates this architecture from source-backed development and any future accepted release.
Its intended organising model joins measured state, bounded authority, revocation, isolation and evidence after corrective work. The underlying disciplines are established, and mature products already combine many of them.
That is an architectural requirement: deterministic policy and supported local containment should retain their protective behaviour. Actual disconnected behaviour needs implementation and verification.
Talk directly to Altari
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.
