Is Remedy Windows-only?
No. The architecture spans Windows endpoints, Windows servers, Linux servers and network/identity boundaries. The strongest inspected implementation evidence currently concerns limited Linux development functions.
AI Defence / Remedy architecture
Connect Windows posture with the authority of each task.
The Windows architecture combines Remedy Core for security state and control with Glass for risky external interactions. Its aim is to work with established Windows protections while giving policy a consistent view of device, application, content and network trust.
Planned architecture · This page explains the intended design. Current capabilities and release limits are documented in the product status guide.
Remedy Core on a Windows endpoint
Core is the planned endpoint layer for posture, selected telemetry, identity, containment, remediation and recovery coordination. A useful posture picture can consider protection settings, firewall state, privileges, services, updates and relevant application configuration.
A device’s role matters. A normal employee workstation, an administrator’s machine and a specialised operational endpoint need different permissions and change windows. The intended policy should use the required business task and current evidence instead of assuming all devices deserve the same authority.
Use native security controls and established engines
Microsoft Defender and other mature endpoint tools already offer prevention, behavioural detection and response. Windows provides isolation and application-protection primitives that may be appropriate for particular tasks. Remedy’s intended value is coordinating measured state and decisions across supported components.
That does not establish active Defender, identity, isolation or management connectors. A deployment must confirm the actual Windows edition, supported isolation mechanisms, hardware requirements, licensing, endpoint products and integration permissions. Vendor names on this page describe the ecosystem, not partnerships.
Put Glass around risky external work
Opening an attachment, downloading an executable or inspecting files on removable media is a distinct activity. Glass is intended to route these tasks according to provenance, fingerprint, reputation and policy. A task can receive a temporary copy without the employee’s normal corporate-storage or network privileges.
Internet Glass and Document Glass have different needs. The former may require controlled internet access without corporate files; the latter ordinarily needs the selected document without internet or corporate LAN access. Outputs must be evaluated before promotion into trusted storage.
Re-evaluate changed applications and device posture
Continuous Integrity is designed to check the relevant binary, modules, extensions and configuration against the state previously certified. A legitimate vendor update can be revalidated using its source and lineage. An unexplained change should not inherit yesterday’s permissions.
The same principle applies to device posture. Disabled protection, unexpected administrative privilege or failed attestation may require reduced access. Stronger user authentication cannot independently repair the endpoint. A supported remediation and verification workflow is needed before recertification.
Windows servers have a different interaction model
A server normally runs defined workloads rather than opening employees’ external attachments. Core-style assessment, configuration, identity, network and recovery controls are therefore the relevant focus. A graphical Glass layer is generally unnecessary for that server role.
Server changes must preserve the workload, management paths and recovery capability. An application restart, policy modification or rebuild needs its own supported action and operational plan. Endpoint and server support cannot be inferred from one another.
Current Windows status
The Windows Core and Glass experience described here is planned architecture. The reviewed Windows production validation checks are unavailable; no complete production Windows protection or isolation workflow is asserted.
Discuss a bounded technical walkthrough with Altari to identify what exists in the candidate build and what remains to implement. Keep current endpoint protection, identity controls, patching and backups in place, and evaluate supported tasks rather than an assumed all-Windows capability.
Questions answered
Does a Linux server need Glass?
Normally no. The Linux server scope focuses on Core-style host posture, monitoring, identity, remediation and validation. Glass addresses external-content interactions where they are actually needed.
Talk directly to Altari
Bring the environment.
Start with the right questions.
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.