Technical Reference

Under the Hood

Guardian runs two on-device anomaly-detection layers on Windows using ETW-derived features. Layer 1a scores short per-process event windows, while Layer 1b scores rolling 5-minute machine-wide behavior. Both run on-device, both feed the same alert system, and trusted local baselines can refine response thresholds without retraining shipped ONNX weights.

17 Layer 1a Input
Fast-path Features
12 Layer 1b Input
ETW Event-Rate Features
ONNX Inference Engine
Runtime, On-Device
0× Cloud Upload
All Inference Is Local
2 Detection Layers
Fast first pass

One process, one short burst

Layer 1a looks at a short ETW event window from one process and asks whether that burst looks ordinary.

Slower second pass

Whole-machine behavior over 5 minutes

Layer 1b looks across the machine. It rolls up 5 minutes of ETW activity and checks whether that wider pattern fits benign behavior.

Local personalization

Trusted recordings can tighten the response

Guardian can derive bounded local thresholds from clean app or system recordings. Those recordings shape your PC only; they do not rewrite the shipped ONNX weights.

How alerts work

Action depends on both score and process type

A high score does not always mean quarantine. Windows, signed, hardware, impersonation, and behavioral alerts are routed differently so the response stays safe.

Investigation queue

Investigation Required is not Action Required

Deviation Tier 3 items land in Investigation Required for evidence review. Operational Tier 4 (Action Required) needs corroboration before quarantine is offered on eligible paths.

Privacy boundary

Detection stays on the machine

ETW scoring, vault, baselines, and posture snapshots stay local. The only routine outbound call is subscription verify/activate, not behavioral telemetry or file contents.

01 — Architecture

Two-Layer Detection Pipeline

Guardian currently runs two anomaly-detection models at different scopes. Layer 1a is the fast per-process event-window lane, and Layer 1b is the slower machine-wide behavioral lane built from rolling 5-minute ETW aggregates. They feed the same alert pipeline, but they answer different questions and provide defense in-depth.

Runtime contract: both models are evaluated locally via ONNX Runtime; feature vectors and reconstruction scores are not sent to a remote model service. Shipped models and matching preprocessor metadata are installed with the app and updated with product releases rather than through silent, per-session model downloads.

Layer 1a

Fast-Path Autoencoder

Fires first. Guardian scores a short ETW event window for one process and turns reconstruction error into the first anomaly signal the desktop app can act on. In the current shipping build, this is a fast event-window lane rather than the older fully static PE-header alert path.

Layer 1b

Behavioral Autoencoder

Runs continuously in the background. It aggregates 12 ETW event-rate features over rolling 5-minute windows and compares each window against the benign behavioral model shipped with the app.

Design principle

Different Scope, Same Pipeline

Together they provide defense in depth: a fast, process-local check can flag odd bursts early, while a slower machine roll-up can flag coordinated or rare operational patterns that are invisible in a single process slice.

Training approach

No Signatures Required

Both models are trained on benign data. They learn what normal looks like, not what malware looks like. That means unusual structure or unusual behavior can raise the score even when the exact threat has never been cataloged before.

02 — Layer 1a

Fast-Path Autoencoder

The first model scores a short per-process event window locally and converts reconstruction error into the first anomaly signal the desktop app can surface.

64 Default Window Size
Per-Process Events
17 Input Dimensions
Fast-Path Feature Vector
ONNX Runtime
All Local Inference
3 Sensitivity Presets
Low / Medium / High
How It Works

In the current monitor path, Guardian buffers a short burst of ETW activity for one process, maps that burst into a 17-slot feature vector, and feeds the vector through the first ONNX model. The mean squared error (MSE) between the input and reconstruction is the anomaly score: low means the window is close to the benign patterns the model learned, while high means it falls outside that learned range.

The network is a compact symmetric autoencoder with an 8-dimensional bottleneck (a compressed internal representation of each window). Hidden layers use ReLU and the output layer is linear for reconstruction. Earlier public docs emphasized a fully static PE path; that richer path still exists in the codebase, but the live monitor currently surfaces alerts from the fast event-window lane documented here.

Network Architecture

Read this as a three-stage flow: the encoder compresses a raw event window into a compact behavior fingerprint, the bottleneck (latent) stores that compressed fingerprint, and the decoder tries to reconstruct the original window from that fingerprint. If reconstruction is poor, the window is more likely anomalous.

Encoder Bottleneck Decoder
17
event window in
→
32
compress stage 1
→
16
compress stage 2
→
8
latent fingerprint
→
16
rebuild stage 1
→
32
rebuild stage 2
→
17
reconstruction out
Input Feature Vector — 17 Dimensions

The current desktop build uses a summarized event-window feature vector rather than the older full PE-header extraction path. Several slots are placeholders kept so the live vector still matches the first model’s 17-input shape.

FeatureCurrent meaning
window_meanAverage risk weight across the recent event window.
window_stdSpread of event weights across the same window.
window_maxHighest-risk event observed in the window.
window_minLowest-risk event observed in the window.
high_risk_countCount of high-risk events in the window.
high_risk_ratioShare of the window made up of high-risk events.
event_countTotal number of events accumulated for the process.
scaled_mean_termScaled copy of the mean to preserve range information for the model.
scaled_std_termScaled copy of the spread to preserve variance information for the model.
FeatureCurrent meaning
reserved_timestamp_slotCurrently 0 in the live monitor path.
reserved_dll_slotCurrently 0 in the live monitor path.
reserved_debug_slotCurrently 0 in the live monitor path.
reserved_signature_slotCurrently 0 in the live monitor path.
dense_high_risk_flag1 when high-risk events dominate the window, otherwise 0.
reserved_extension_slotCurrently 0 in the live monitor path.
reserved_arch_slotCurrently 0 in the live monitor path.
fixed_subsystem_slotFixed compatibility value kept so the live vector still fits the model’s 17-input shape.
Design Notes
What this lane is today The shipping desktop build uses Layer 1a as a fast event-window detector. The richer PE-aware path exists in the codebase, but it is not the main path the live monitor currently uses to surface alerts.
Why the window is short Layer 1a runs after a per-process window fills (64 events by default, with a smaller floor for short-lived processes). The goal is low latency: raise a first flag quickly, then let the slower 5-minute behavioral lane add broader context.
Sensitivity behavior The desktop presets set the shipped Layer 1a starting points:
  • Low = 0.625
  • Medium = 0.223
  • High = 0.136
Trusted local recordings can then derive bounded per-process Layer 1a thresholds on top of those presets. Layer 1b is not driven by this control.
Reserved slots in the 17-vector Several feature names in the tables above are placeholders: they stay at zero in the live fast path so the monitor still feeds a vector with the exact 17 dimensions the shipped ONNX model expects. That keeps runtime behavior aligned with training without re-exporting weights when the event-window lane evolves.
03 — Layer 1b

Behavioral Autoencoder

Watches what the whole machine does in aggregate every 5 minutes. Flags windows that fall outside the benign behavioral envelope the shipped model expects, then optionally tightens that envelope with trusted local recordings from the same PC.

0.000507 Anomaly Threshold
MSE Reconstruction Error
5 min Window Size
Rolling ETW Aggregation
13,880 Training windows
Benign behavioral data
MinMax Preprocessor
Clip + Per-Feature Scale
How It Works

Every 5 minutes, Guardian collapses machine-wide ETW operational activity into 12 normalized rate features. The behavioral autoencoder reconstructs each new window from benign patterns learned during training. A high reconstruction error means the observed window falls outside the expected benign envelope.

Guardian also includes local baseline-recording tools so you can capture trusted app or system sessions on your own machine. Those recordings do not retrain the ONNX weights. Instead, they contribute clean 5-minute windows that let the desktop monitor derive a bounded local Layer 1b threshold when enough coverage exists. Until then, Layer 1b stays on its shipped threshold of 0.000507.

Network Architecture

This layer follows the same idea as Layer 1a but on machine-wide 5-minute behavior windows: encode into a compact latent representation, then decode back to expected benign behavior. Large reconstruction gaps indicate behavior that does not match the model's benign baseline.

Encoder Bottleneck Decoder
12
5-minute rates in
→
32
compress stage 1
→
16
compress stage 2
→
8
latent fingerprint
→
16
rebuild stage 1
→
32
rebuild stage 2
→
12
reconstruction out
ETW Feature Vector — 12 Dimensions

Each feature is an event count divided by window duration (events/sec). All 12 are clipped at the 99th percentile then scaled to [0, 1] per feature using MinMax normalization to prevent rare bursts from dominating the anomaly score.

Feature ETW Source What It Captures
wmi_query_rateWMI-Activity / 5857, 5858Rate of WMI queries. Malware heavily abuses WMI for reconnaissance, lateral movement, and execution.
task_register_rateTaskScheduler / 106, 107Rate of scheduled task registrations. Attackers register persistence tasks; high rates outside maintenance windows are suspicious.
task_run_rateTaskScheduler / 200, 201, 202Rate of task executions. A spike after a registration event strongly suggests a newly placed persistence mechanism firing.
bits_event_rateBits-Client / any EventIDBITS is commonly abused for stealthy C2 downloads via system-trusted network channels.
fw_rule_change_rateFirewall / 2097, 2052, 2002Malware modifies firewall rules to open inbound ports or allow C2 traffic to pass through.
rdp_session_rateTermSvc-LocalSessionMgrExpected near-zero on single-user workstations. Non-zero on machines without RDP enabled is always anomalous.
smb_access_rateSMBClient / any EventIDNear-zero on isolated workstations. Elevated rates suggest lateral movement scanning or unexpected share access.
error_event_rateEventLog / Level = Error, CriticalRate of error and critical events system-wide. Malware causes cascading errors through injection failures or service crashes.
total_event_rateAll ETW channelsOverall system event rate. Captures gross activity spikes that do not fit any specific category.
unique_channel_countDistinct provider channelsNumber of distinct event channels fired in the window. Unusual proliferation suggests broad system manipulation.
group_policy_rateGroupPolicy / any EventIDLegitimate GP activity is periodic and predictable. Manipulation attempts generate irregular bursts.
shell_core_rateShell-Core / any EventIDShell lifecycle events. Naturally sparse; spikes correlate with software installation activity.
Design Notes
Why an autoencoder, not a classifier? A classifier requires labeled attack samples. An autoencoder trained only on benign data has no concept of what attacks look like; it just learns what normal is. Anything outside normal produces high reconstruction error, whether or not it has ever been documented. This is what makes anomaly detection effective against zero-days.
Why 5-minute windows? Most attack sequences involving system manipulation leave traces over minutes, not milliseconds. A 5-minute window is long enough to capture a full attack phase but short enough to alert before the next phase begins. Windows shorter than 2 minutes produce noisy rates; longer than 10 minutes delay alerts.
Preprocessor design Raw counts are clipped at the 99th percentile and scaled to [0, 1] per feature. Clipping values are stored in preprocessor_config.json alongside scaler parameters so the on-device ONNX runtime applies identical preprocessing without needing a scikit-learn object.
04 — Inference

ONNX Runtime Pipeline

Both models are exported to ONNX and run entirely on your machine via ONNX Runtime. No inference request is sent to a cloud model and no behavioral feature vector needs to leave the device.

Layer 1a flow

Fast-Path Inference

Per-process ETW events are buffered until the fast-path window fills. Each event category contributes to the 17-slot Layer 1a vector, and the first ONNX model returns a reconstruction error. The desktop app then compares that score against the active Layer 1a threshold in effect for that process: shipped preset when no trusted recording exists, or a bounded locally derived threshold once a clean baseline has been recorded.

Layer 1b flow

Behavioral Window Inference

The ETW recorder accumulates machine-wide operational counts in a rolling in-memory buffer. At each 5-minute boundary, counts are converted to 12 rate features, preprocessing is applied (clip → MinMax), and the vector is passed through the behavioral autoencoder. An alert fires when the MSE exceeds the active Layer 1b threshold: the shipped 0.000507 threshold by default, or a bounded local threshold if enough trusted clean behavioral windows have been recorded on that machine.

Runtime choice

Single Native Library, No Python

PyTorch and TensorFlow models require a full Python runtime to embed. ONNX Runtime ships as a single native library with Rust bindings (ort crate), adding roughly 30 MB to the binary. Inference latency on both models is sub-millisecond on modern hardware.

Model versioning

Versioned Local Files

Models and preprocessors ship as versioned local artifacts with the app. They are loaded from disk at startup and updated as part of normal product releases, not by sending live telemetry to a remote inference service.

05 — Alert Logic

Alert Tier Classification

Not all anomalies are equally urgent. The desktop UI accumulates confidence over time, routes protected process classes separately, and only exposes aggressive actions when the process is both actionable and high confidence.

Monitoring
Tier 1
Marginal scores, known-good process classes, or single-window behavioral spikes stay in the background list. Guardian keeps history so repeated activity can promote the same process later.
Under Review
Tier 2
Consistent anomalous activity or protected-class review routing. User-installed processes appear in actionable lanes; Windows, signed, and hardware categories use their dedicated tabs.
Investigation Required
Tier 3 deviation
Strong sustained deviation: a behavioral signal, not a verdict. Routed to the Investigation Required sidebar view for evidence review and Suggested Actions on protected categories before operational escalation.
Action Required
Tier 4 operational
Corroborated operational Tier 4 only (since 1.0.26): correlated secondary indicators, Defender-confirmed routing for unknowns, or equivalent escalation. Quarantine when eligible; protected categories still use guidance instead of removal.
Corroboration gate (Tier 4) Action Required is not raised from a single Layer 1a or Layer 1b spike alone. The desktop app waits for corroborating signals (for example repeated high-confidence flags plus a secondary indicator, or Defender-confirmed routing for unknown binaries) before offering quarantine on eligible user-installed paths.
Windows Defender and unsigned Guardian builds Because Guardian is not yet publisher-signed, Defender may flag the installer or monitor with heuristic names (for example ML detections on unknown security tools). That is not the same as Layer 1b behavioral scoring. Use exclusions under %LOCALAPPDATA%\AI Malware Guardian\ if needed, reinstall from the official download, and submit a Microsoft false-positive report when appropriate.
Protected Category Routing
Windows processes Core Windows process names such as svchost.exe and lsass.exe are routed to Windows review views. Quarantine is blocked because removing them can destabilize the operating system.
Signed software Known trusted apps and valid Authenticode-signed executables are treated more cautiously. They can still be flagged, but the app routes them to guidance instead of offering quarantine.
Hardware processes Known GPU, audio, networking, and peripheral service names from vendors such as AMD, NVIDIA, Intel, Realtek, ASUS, Corsair, Logitech, and Razer are routed to Hardware Processes. The app prefers review or driver guidance instead of removal.
Impersonation and behavioral windows A Windows-named process running from the wrong path is routed as suspicious impersonation, and machine-wide behavioral windows surface as investigate/review context rather than single-file quarantine events.
Game install paths and launcher children The desktop UI also classifies process origin for game-related scenarios. When an executable lives under a detected game installation directory (for example a Steam or Epic game library path), the UI can show a Game origin advisory badge so you review before aggressive actions. A process spawned as a child of a game launcher may not get that badge: it is not necessarily a game binary, and the app keeps quarantine and confirmation stricter there to avoid accidental removal of support tools. Elevated or automation-heavy dev tools (build systems, script runners, game anti-cheat services) may surface Under Review or Investigation Required more often; Action Required stays corroboration-gated. These signals are advisory and sit alongside, not in place of, the Windows, signed, and hardware routes above.
07 — Configuration Posture

Local Windows Configuration Snapshots

Separate from ETW/ML baselines: Guardian captures a narrow Windows configuration surface on-device and compares it to a reference you establish.

What is captured (schema v2) Defender real-time protection, cloud reporting, tamper protection, PUA blocking, sample-submission consent, firewall enabled state per profile (Domain / Private / Public), and a SHA-256 hash of the hosts file (512 KB cap). Policy registry paths are preferred where Group Policy sets values.
Where it lives Encrypted snapshots rotate as ref.posture and cur.posture. They are stored under:
%APPDATA%\AiMalwareGuardian\security_posture\
A summary JSON and plain incident log also live on-device. No cloud upload for posture scoring.
How the UI uses it The Configuration Posture sidebar view shows drift against your reference. Unacknowledged warn/critical incidents can surface a synthetic Tier 2 row in Actionable Alerts. Re-establish reference writes the current capture as the new baseline and clears summary drift (incidents may still need acknowledgement).
Local-first boundary Detection and posture evaluation run on-device. The expected outbound calls are subscription verify/activate on the Worker, not behavioral telemetry or file contents.
Elevated monitor The background monitor is launched via elevated scheduled tasks (not HKCU Run) so ETW collection can run with the privileges Windows expects for security tooling.
Scheduled checks Windows-only background loop: 120s after startup, then every 60 minutes. Emits posture-updated to refresh the Configuration Posture view.
06 — Baseline & Sensitivity

Personal Baseline Methodology

Guardian keeps the shipped models fixed while still letting trusted local recordings shape bounded thresholds on the specific machine where they were captured.

The shipping models were trained on large benign corpora before release. Guardian also includes local baseline-recording tools so you can capture app or system sessions on your own machine in the same runtime feature spaces.

Those recordings do not retrain model weights. Instead, they populate encrypted local indexes that derive bounded thresholds from trusted clean windows: per-process for Layer 1a and machine-wide for Layer 1b once enough clean 5-minute windows exist. The result is a detector that becomes more specific to your machine while keeping threshold behavior auditable.

Baseline recording is manual Baselines are started and stopped from the desktop UI. Captured samples stay on the machine, are encrypted at rest, and are not uploaded for cloud-side scoring. Guardian only trusts the windows you deliberately recorded.
App mode and system mode both exist App recordings focus on one executable and directly personalize Layer 1a for that process. System recordings capture a wider machine snapshot and can expand both Layer 1a coverage and the Layer 1b behavioral envelope. The desktop app can list, merge, and delete those recordings later so you keep only the baselines you actually trust.
Sensitivity controls Global sensitivity changes only the shipped Layer 1a presets:
  • Low = 0.625
  • Medium = 0.223
  • High = 0.136
Layer 1b ignores this control and changes only when enough trusted clean behavioral windows exist to activate a bounded local threshold.
On-device detection

See how Guardian turns local models, trusted baselines, and safe response rules into a desktop workflow.

← Back to home Get Protected