Every file, taken apart and made again

Two engines, working on the same file

Glasswall runs two engines over the same file. One manufactures a clean file, safe to open, by building a new one to the format's published specification instead of judging whether the original was dangerous. The other, AI threat prediction, judges the original separately, so as well as a safe file you learn what you were actually sent.

Deterministic

Manufacture the clean file

Inspect, repair, remove, deliver. The file is taken apart first, so that everything after it works on a description of the file rather than on the bytes that arrived.

1

DeconstructThe file is broken into its constituent structural elements, turning its document object model into schema-checkable intermediate files. Three kinds come out:

• Structural schemaAn organised tree defining the valid structure, hierarchy and relationships of the document objects, according to the manufacturer's specification.
• Content streamsThe raw text, data blocks and body content, stripped of executable layout behaviours.
• Embedded binary assetsImages, fonts and media pulled out as distinct individual files, so each can be processed and checked on its own.

2

InspectEvery structure in that description is validated against the published specification. Each finding is tagged with the kind of change resolving it would make.

3

Repair and removeStructures that do not conform are repaired to the specification, and high-risk content is removed to your policy. Four things act here, on the description rather than the original file:

• Find & RedactSensitive information found across content, metadata, comments and properties, and removed.
• QR codesFound by their corner patterns and painted out, so a link nobody can read cannot be followed.
• Hidden payloads in imagesData concealed inside pictures is disrupted, targeting the channel while leaving the image usable.
• Image resizingOversized images are exported, reduced to fit and reinserted, holding visual similarity above 90%.

4

Build to the specificationA new file is built from what conforms. The specification is the recipe, what the file should be and how to put one together; the content that survived is the ingredients.

Nothing has to be recognised. The output is not the original with parts taken out; it is a new file assembled to a published standard. A payload nobody has catalogued, or one written by a model this morning, has nowhere to sit in it.

Predictive

AI threat prediction

Machine-learning models read the structure of the original file, before anything is taken apart, and judge how likely it was to be weaponised. No signatures to keep current, and nothing is detonated to find out.

1

Runs first, on the original fileThe assessment happens before the file is taken apart, so its verdict is available to everything that follows. The models work from how a file is built, so a threat nobody has seen before is not automatically invisible.

2

Nothing is executedNo sandbox, no detonation, no waiting for behaviour to appear. There is nothing for a file to detect and hide from.

3

Runs where the files areIt works offline, making no outbound calls while it analyses, so it suits isolated and regulated environments.

4

Returns a judgement you can route onOne of three assessments, which quarantine, SOC and remediation workflows can act on directly.

• Malicious
• Suspicious
• No threats detected

5

Its verdict can steer the policyBecause the score lands before the rebuild starts, it can select the policy the CDR then works to. A file predicted malicious is handled more strictly than one that is not.

It answers a different question. Manufacturing a clean file makes it safe to open. This tells you what you were sent, which is what decides whether an incident needs opening at all.

Before the rebuild

Six stages run first. A file has to be identified, opened and made readable before any rule can judge it or the rebuild can take it apart.

Every finding says what fixing it would cost

No action is anonymous. Each one carries a marker, so you can see at a glance whether a rule changes what a reader sees, how the file behaves, or nothing visible at all.

• [visual]

  Changes what the reader sees on the page.

• [functional]

  Changes how the file behaves when it is opened.

• [structural]

  Invisible hardening. Nothing changes for the reader.

Six things your policy can do with a finding

One posture is set across the organisation, then refined by file type, content type, workflow or individual rule. The engine does not decide what happens; you do.

• ReportRecord the finding and change nothing in the file.
• RevealUn-hide content someone concealed, such as a hidden row, sheet, slide or run of text, rather than deleting it.
• ReplaceOverwrite the offending value in place, such as setting an author name to a safe placeholder.
• RemoveDelete the content, such as stripping a macro or an embedded object.
• RejectBlock the whole file. No cleaned output is written.
• OmitTurn the rule off, so it produces no finding at all.

Report, reject and omit apply to every rule. Reveal, replace and remove are available only where they make sense for the content a rule detects.

What comes out

The output is checked again before it is handed over, and it never leaves without a record of what happened to it.

What the engine itself brings

Properties of the engine rather than steps in the flow, but they decide what the pipeline can be pointed at and how much you can trust the thing doing the work.

• 140+

  File extensions covered, from everyday documents and email to geospatial, CAD, audio, video and imagery.

• Rebuilt in native format

  A document comes back as a document, not flattened to PDF. CMYK-accurate images, embedded fonts intact, coordinates untouched.

• Memory-safe by construction

  The parser that handles hostile files is managed code, so it cannot itself be hijacked through the flaws that recur in native engines.

• Runs where you need it

  A self-contained binary across Linux, Windows and macOS on x64 and Arm64, including hardened and air-gapped deployments.

Where the rules come from

What counts as non-conformant is not a matter of opinion. The rules are published and version-controlled, and every action traces back to a specific rule and its source.

• NSA guidance

  Published Inspection and Sanitisation Guidance, wherever it exists for a format.

• Glasswall research

  Glasswall's own rule sets, anchored to the format specification and its CVE history, for formats without published guidance.

• The specification itself

  Structural constraints taken directly from the format's published specification, as the default stance.