Does every file get sandboxed?
No. The design distinguishes unchanged certified content, known malicious content and uncertain content. Policy selects an appropriate fast path, block or stronger analysis and isolation.
AI Defence / Remedy architecture
Open the unknown with less authority.
Remedy Glass is the planned external-content isolation layer of Remedy Defence. It is designed to give an unfamiliar task only the resources it needs, while policy evaluates whether its content and output can be trusted.
Planned architecture · This page explains the intended design. Current capabilities and release limits are documented in the product status guide.
What is task-level isolation?
Task-level isolation places a particular activity inside a disposable environment with tightly bounded permissions. For Glass, that activity might be opening an external spreadsheet, inspecting an archive or visiting a higher-risk website. The user continues working with familiar applications; the security boundary belongs around the risky task.
An unknown file should not automatically inherit the employee’s access to shared folders, administrative services, backups or reusable corporate credentials. Glass is intended to use temporary copies and explicitly limited CPU, memory, storage and connectivity. An isolated process still needs a secure isolation mechanism and correct policy: isolation reduces exposure without proving that every threat is harmless.
Unknown is a state to contain and evaluate. It is neither a malware verdict nor permission for unrestricted access.
External content through GlassArchitecture
External contentFingerprint, source and current certification
Glass Risk RouterSelect a supported policy path
Certified and expectedAppropriate fast path
Known maliciousBlock before execution
Unknown or ambiguousAnalyse; isolate where needed
SuspiciousDisposable, minimum-authority task
Behaviour and output reviewContinue within policy, or freeze, restrict and terminate
Promotion BrokerApprove measured output, hold uncertainty or reject
Internet Glass and Document Glass
These profiles separate two very different needs. An internet task may need outbound web connectivity without access to corporate files. A document task needs the selected file, but usually has no reason to contact the internet, neighbouring workstations or internal management systems.
The intended router chooses an appropriate supported protection mechanism. Native browser sandboxing, Protected View, remote browser isolation and stronger disposable execution are complementary options, subject to platform capability and integration testing. Glass is an orchestration design, rather than a claim that a single sandbox fits every workload.
| Profile | Resources the task may need | Authority withheld by default |
|---|---|---|
| Internet Glass | Policy-permitted internet access and temporary session state | Corporate LAN, authoritative files, backup systems and unrelated credentials |
| Document Glass | A bounded copy of the chosen object and temporary working storage | Normal internet access, corporate network access and unrelated files |
Check before execution; isolate when uncertainty remains
The proposed analysis starts with the exact cryptographic fingerprint, previous certification, source, publisher and signature. Reputation and threat intelligence can identify known bad content before it runs. Static inspection can then examine scripts, macros, embedded URLs, imports or other relevant features.
When ordinary rules leave uncertainty, bounded AI assistance, emulation or behavioural analysis may add evidence. Deeper analysis consumes resources, so the design reserves it for new, changed, external, suspicious or otherwise high-risk content. Unchanged certified activity can use the fastest path allowed by current policy and evidence. Known malicious content does not need deliberate execution merely to demonstrate that it is malicious.
Email attachments, links and browser downloads
The intended email model preserves the normal Outlook or other supported mail experience. Provider-side or API-side analysis of phishing and business email compromise is a separate layer from what happens after someone opens a link or attachment. Those integration categories are planned, with no active provider connector implied.
An external link can be evaluated against browsing policy. A download remains external content when it reaches the endpoint; it does not become trusted because the browser successfully downloaded it. Suspicious Word or Excel documents, PDFs, archives and executables can be routed into a bounded task. Browser isolation does not independently solve identity theft, fraudulent instructions or every session attack.
USB files and script security
Removable media carries its own provenance. Where supported and appropriate, policy can apply read-only access or deny execution before files are evaluated. Plugging in a USB stick should not grant its contents the authority of the person using the workstation.
PowerShell, JavaScript, VBA, Python and shell scripts can change behaviour after a very small edit. Fingerprinting, static rules, relevant reputation and optional deeper analysis therefore belong before renewed certification. A permitted document does not automatically authorise an embedded macro or every child process it might start.
Observe the task and control its output
The design allows suspicious behaviour to trigger a bounded containment sequence: freeze the task, remove its permitted connectivity, capture relevant evidence, terminate execution and destroy temporary state. Local enforcement should retain its protective policy without waiting for an external AI service. These are architectural requirements, not an asserted production action chain.
Saving an output is a separate trust decision. A promotion broker is intended to inspect the proposed output, its lineage and the applicable policy before it enters trusted storage. Merely finishing execution does not make a file safe. Suspicious or inconclusive output stays held; an approved output acquires its own measured identity and record.
Familiar work, with understandable decisions
The intended experience avoids hundreds of technical approval prompts. Policy, provenance, certification and risk should handle ordinary decisions. Where a task needs a delay or review, a short explanation such as “This external file is being checked before it can be saved” makes the reason understandable. This is illustrative interface wording.
Glass, its risk router and its promotion controls are planned architecture. A technical evaluation must establish supported applications, isolation boundaries, resource limits, escape handling, disconnected behaviour and output controls before relying on them. Keep established endpoint and email protection in place.
Questions answered
Does Glass replace Windows, Chrome or Outlook?
No. Glass is intended to coordinate protection around particular tasks while retaining familiar applications. Supported mechanisms and integrations still require implementation and validation.
What happens to a malicious attachment?
Known malicious content can be blocked before execution. If suspicious behaviour appears during an isolated task, the intended response restricts and terminates that task and withholds its output. This workflow is planned, not generally available.
Talk directly to Altari
Bring the environment.
Start with the right questions.
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.