AI Defence / Remedy architecture
Ransomware protection combines prevention, detection, restricted authority and recoverability. Remedy’s planned contribution is to limit what an unfamiliar process can reach, connect suspicious behaviour to containment, and require evidence after remediation.
A malicious process may execute with the rights of the employee who opened it. Those rights can include enumerating and changing local files, writing to mapped drives and network shares, accessing synchronised cloud folders and interacting with other services. The consequences depend on the process’s actual privileges and reachable resources.
Endpoint detection remains important. But a process can cause harm before it is recognised, particularly when it already holds useful access. The architectural question is therefore both whether a process is malicious and what resources it can touch while that remains uncertain.
In ordinary execution, an attachment may run within the user’s normal environment. In the Glass design, external provenance can trigger a separate task with a temporary copy and bounded resources. Corporate LAN access, authoritative storage, backups, administrative rights and broad reusable credentials are withheld unless specifically justified.
This is intended to reduce the resources available to an unknown malicious task. It does not make ransomware impossible, guarantee containment on every path or replace a tested endpoint protection product. The chosen isolation mechanism and policy must be secure and supported.
| Question | Ordinary user execution | Planned Glass task |
|---|---|---|
| Which files are visible? | Potentially everything the user can read | The selected temporary input and permitted task state |
| Where can it write? | User-writable local, shared or synced resources | Bounded temporary storage until output approval |
| What can it reach? | Network resources available to that session | Only explicitly permitted connectivity |
| What happens to output? | May immediately affect normal storage | Promotion policy evaluates entry into trusted state |
Glass addresses high-risk external tasks. Continuous Integrity is intended to reassess changed applications, scripts and security configuration. Network Trust aims to remove unnecessary peer-to-peer authority and restrict devices whose identity, posture or behaviour no longer meets policy.
A compromised endpoint should not automatically be able to reach backup consoles, management systems or every workstation. These boundaries are enforced through supported host, network and identity controls. No single layer covers every attack path; identity theft and authorised-session abuse need their own controls.
An intended response can freeze an isolated task, remove its network capability, capture bounded evidence and terminate it. Broader endpoint restrictions need a supported enforcement path and a way to preserve essential management communication.
Low-risk actions may be automated when tenant policy permits. Production changes, destructive cleanup, rebuilding and restoration can require human approval. An automated action is useful only when its scope, effects and failure handling are understood. A command returning success does not establish that every affected resource is safe.
Protected backups, appropriate immutable or off-domain copies and rehearsed recovery procedures are essential because some attacks may still succeed. Synchronised storage alone is not a complete recovery design: unwanted changes can propagate with legitimate changes.
Recovery may require an endpoint rebuild, storage restoration, database recovery, renewed credentials and post-restoration checks. Decide ownership and the evidence for a safe return before an incident. The website does not promise a recovery time, recovery point, decryption service or restoration of data for which no usable backup exists.
The current product evidence supports limited Linux development assessment and monitoring, alongside remediation and validation packages that need further integration and review. Glass, integrated quarantine and the broader ransomware containment and recovery chain remain planned.
A useful technical discussion starts with the workloads, storage paths, endpoint tools, network boundaries and recoverable copies in your environment. A pilot should identify the narrow condition being tested, supported controls, permitted actions and evidence needed to judge the result.
Restricting the task’s access to network storage can reduce that exposure. The outcome depends on supported enforcement, correct configuration and attack paths. No universal prevention claim is made.
No. The architecture is intended to work alongside established endpoint prevention and detection, adding coordinated trust, authority and evidence decisions where supported.
No general file restoration or decryption service is established in the reviewed evidence. Recovery depends on usable protected copies and an implemented, validated recovery procedure.
Talk directly to Altari
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.
