Remedy Core
Host posture, selected telemetry and governed corrective work across the endpoint and server architecture.
Explore Remedy Core ↗AI Defence by Altari Systems
Security that adapts when trust changes.
Measure trust. Limit authority. Verify the response.
Remedy Defence is being designed to connect users, devices, applications, files and networks through one measured trust model. Isolate uncertainty, govern corrective work and examine the evidence afterwards. For UK businesses, MSPs and security teams.
In developmentLinux foundations; broader trust architecture planned. View current status
ILLUSTRATIVE / SYNTHETIC DATA
Case AD-DEMO-014
A local pass is one piece of the picture.
Configuration review · lab-web-01
Local configurationPass
Independent network checkUnavailable
Overall reviewUnverified
An illustration of the intended review discipline. No live result or proven production closure guarantee.
The Remedy Defence platform
Trust should follow the evidence.
A login, a familiar filename or a place on the network should never grant unlimited authority. Remedy’s architecture keeps the decision tied to the current state.
Remedy Glass
Disposable, minimum-authority tasks for external documents, attachments, downloads and risky browsing.
Explore Remedy Glass ↗Continuous Integrity
Trust the measured file, application and configuration state. Revalidate when unexplained change occurs.
Explore Continuous Integrity ↗Remedy HQ
Shared policy, incident context and evidence that explains what changed and what remains unresolved.
Explore Remedy HQ ↗The same rule, across the estate
Unknown should not mean unrestricted.
A changed file, unfamiliar device or risky session needs a proportionate decision. The planned trust engine combines identity, integrity, provenance, device posture, network context and behaviour.
Expected, certified activity uses the appropriate fast path. Uncertainty receives limited authority, further analysis or isolation. Required evidence determines when trust can be restored.
The unified trust decisionArchitecture
User · Device · Content · Application · ConnectionThe subject, object and requested action
Remedy Trust EngineIdentity + integrity + provenance + posture + network context + behaviour
Policy decisionWhat is the minimum authority justified now?
AllowScoped, appropriate fast path
IsolateA bounded Glass task
RestrictQuarantine or limited capability
BlockDeny the request; retain incident evidence
What it brings together
Make the next security decision
with a clearer picture.
Start with the host’s actual state. Understand what a finding means. Review the evidence needed to judge a response.
Understand the host
Linux development collectors assemble local system, account, service, software and configuration context.
Linux assessment ↗Review what changed
Periodic observations cover selected file integrity, processes, authentication logs and configuration digests.
Monitoring and limits ↗Examine the outcome
Central validation packages bring checks and evidence into a review model. Production integration and closure controls remain under review.
Validation architecture ↗How the parts connect
Local observations.
A shared review.
The Linux component collects and evaluates local facts. Shared services handle configured messaging and reports. Central validation packages define checks and correlate evidence.
Recommendations and commands have different roles. A proposed correction still needs the right capability, configuration and authority.
Explore the architecture and dependencies ↗Windows and network production validation are unavailable in the reviewed source. No integrated production release is asserted.
COMPONENT MAPIn development
Linux host componentInventory · configuration · periodic observations
Findings, reports & heartbeat Configured HTTPS transport
Shared servicesMessaging and reporting
Evidence
Central validationCheck planning and evidence review
Recommendation & result
Operator decisionScope, impact and authority
A practical walkthrough
One finding. Every decision visible.
A fictional Linux configuration change shows the path from an observation to an operator’s review. Synthetic data keeps the explanation concrete.
- 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
Inside the intended workflow
Explore the product tour.
Read the host context, inspect a recommendation and compare available evidence. These interfaces illustrate the intended experience; they are not a live security console.
Fit within your operation
Start with a specific question.
Evaluate the evidence.
Assess a Linux host, review a configuration change or examine a proposed correction. Define a pilot around the available components and the checks your environment needs.
Keep existing endpoint protection, monitoring and backups in place. A native SIEM integration, automatic isolation and file restoration are not established capabilities in the evidence reviewed here.
Explore evaluation scenarios ↗Part of Altari Systems
Clear responsibilities across the product family.
AI Defence / Remedy Defence
The security programme: measured trust, isolation, governed remediation and validation, with clear development boundaries.
Product status ↗Remedy
The related software repair and runtime-operations platform, with a separate agent and host-management implementation.
Explore Remedy ↗Nexus
Altari’s software engineering control plane. Product integration needs its own implementation and deployment evidence.
Explore Nexus ↗Talk directly to Altari
Bring the environment.
Start with the right questions.
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.