Security & architecture

How it works, and why your file never leaves your machine.

The deep-dive for the technical evaluator. The homepage stays tight; this page is where the structure of the trust model lives.

The local-first model

PayloadGlass analyzes files where they already are. In a deployment, the engine runs on your own infrastructure. In the browser workbench, the same production analysis engine is compiled to WebAssembly and runs entirely in a Worker in your own tab — there is no analysis backend to send a file to. The page loads its own app assets, and it fetches a sample if you pick one, but your file's content, its name, and the derived report are never transmitted — file-content egress is zero. You can verify it: open your browser's network panel and confirm no request carries your file. Disconnect from the internet after the page loads and analysis keeps working.

What the engine actually does

The SIS engine parses a file's real structure rather than a flattened preview: the recursive object graph, embedded and nested objects, active content (scripts, macros, actions), and the parser-level tricks that text filters and LLM guardrails never see. Every finding is typed and carries an evidence span — the byte range or node that triggered it — plus the coverage of the parse and the policy that acted. Verdicts are explainable by construction, not a score you have to trust.

The five risk axes

A single "malicious / clean" label hides the fact that risk depends on what you're about to do with the content. PayloadGlass reads five orthogonal axes over one evidence graph — one artefact routinely scores on several at once:

• Hostility — could this content harm a system, user, or agent by executing, exploiting, fetching, evading, or chaining? (JS/macros, LNK, SVG smuggling, droppers)
• Deception — does it manipulate a human into an unsafe action? (QR phishing, fake login, ClickFix, brand impersonation)
• AI-ingestion — could it corrupt or manipulate an AI/RAG/agent workflow? (hidden prompts, retrieval-visible instructions, tool-use directives)
• Sensitivity — would exposure, indexing, retention, or sharing cause harm? (secrets, credentials, PII, regulated or confidential data)
• Provenance — does origin, custody, or trust context increase risk? (MOTW loss, external sender, unauthenticated source)

Two disciplines make this trustworthy. The security verdict (malicious / suspicious / benign) is the worst of just three lenses — hostility, deception, and AI-ingestion. Sensitivity and provenance are advisory governance lenses that never feed the threat score: a document full of secrets is not thereby "malicious." And governance (what's safe to open, index, share, or send to an agent) is a derived, destination-aware projection over the lenses — not a detector verdict, and not generic DLP.

Where the lenses stand today: the three verdict-driving lenses and the secret/PII detection feeding sensitivity ship (evidence-safe, verdict-inert, local). Sensitivity is advisory — it gates nothing yet. Provenance reads unknown on a bare scan until a host connector supplies origin facts (MOTW, sender, custody) — a roadmap item, distinct from the tamper-forensic findings, which do ship. The layer still being built is the enforcing one above them: the destination-aware projections (safe_to_index, safe_to_forward_external, …) and one coverage-gated policy decision.

The rules the system holds itself to

These are load-bearing invariants, not implementation trivia. They are what make a finding mean the same thing on the command line, in CI, in the browser and on the desktop.

• Unknown is not clean. Unsupported, not run, not measured, incomplete, budget-exhausted and failed are distinct states, and they stay visible. Missing evidence is never silently projected as a pass.
• Route is not identity. Several exact formats may share one analysis lane; the exact format and every accepted interpretation are retained rather than collapsed into one guess.
• Evidence timing matters. Evidence shown beside a verdict is not presented as having influenced it unless it existed when that verdict was taken.
• Projection is not authority. Browser, desktop, reports and gateways consume shared contracts; they never redefine what a finding means.
• Nested provenance survives. A finding discovered several layers deep keeps its native identity and lineage when lifted into the parent investigation.
• Operations are revision-bound. An action is requested against an exact subject and revision, so it cannot silently act on replaced bytes or stale authority.

Transform: the safe-text derivative

Inspection is only half the job. Where policy calls for it, the engine emits a safe-text derivative — a model-safe version of the document with active content and hidden channels removed, paired with a log of exactly what was stripped, what was preserved, and what residual risk is still flagged. This ships today and is distinct from full content disarm & reconstruction (CDR), whose broad reconstruction guarantees are still hardening. The derivative never silently rewrites: every change is evidenced, which is what makes "prove what remains" a literal artefact rather than a slogan.

WASM & cross-origin isolation

The workbench runs the engine as WebAssembly, and where it relies on threads and SharedArrayBuffer for performance, the browser requires the page to be cross-origin isolated. That deploy therefore serves:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Content-Type: application/wasm   (for .wasm assets)

Those headers live on the separate workbench deploy (workbench.payloadglass.com), not on the marketing site — they would otherwise interfere with embeds and analytics here. It is also why the workbench is hosted on infrastructure we control (Netlify / Cloudflare Pages with a _headers file) rather than a host that can't set custom headers.

Sample files in the workbench

The bundled samples are crafted, controlled files that trigger detectors without being genuinely dangerous to the visitor, and they're labelled as such. The workbench never needs — and you should never feed it — a live, genuinely dangerous malware sample.