Install on Windows

The sensor reads Event Tracing for Windows (ETW) and needs no driver. It reports file opens after the fact and cannot stop a read or block a connection.

Install

Use one installer per machine: they share service and task names. To switch, uninstall with the one that installed Guard.

Zip with install.ps1. From an elevated PowerShell in the unzipped folder:

.\install.ps1            # or .\install.ps1 -Network to report AI endpoint connections

MSI. For a silent install through Intune or other software distribution:

msiexec /i runeward-guard-0.1.0-windows-x86_64.msi /qn            # NETWORK=1 also reports AI endpoint connections

A higher MSI version upgrades in place; a lower one is refused. The MSI hasn't been deployed from an Intune tenant or through Group Policy yet, and Cloud enrollment, policy and audit retention are not MSI properties. Both installers register the per-user MCP inventory task, though an upload from it hasn't been tested end to end yet. Add -RepairHooks or REPAIRHOOKS=1 to schedule hook repair. Neither installer registers boot recovery after an interrupted update; guard-update.exe enable-boot-recovery does (see limits).

Both install the binaries to %ProgramFiles%\Rune Guard and register the RunewardGuardSensor service. It runs guard-sensor.exe service as LocalSystem, starts automatically and restarts on failure. Its Guard home is %ProgramData%\Rune Guard. Run guard doctor from an elevated prompt to read its health.

After the install, each user runs guard.exe hooks install all. A user's own Guard home is %USERPROFILE%\.runeward-guard.

Service privileges

The service token keeps only these privileges; every other LocalSystem privilege is removed at start.

It is still LocalSystem, with that account's group memberships, so it can read every profile. An administrator can stop or change the service; Guard Cloud is told when that happens, but nothing prevents it.

Command lines of short-lived processes

Guard reads short-lived command lines from a private kernel ETW session. If that session can't start, it can fall back to Security audit event 4688, which is off by default.

Warning: Turning on the audit fallback makes Windows write the command line of every process, for every user, to the Security log, where every reader of that log can see it. Command lines can contain secrets. Guard reads only AI tools' events and uploads none of them.

To accept this, run the installer with both -AuditProcessCreation -AcceptSystemWideAudit. -AuditProcessCreation alone stops with the disclosure before changing anything. See the privacy statement.

Windows Filtering Platform events

With -Network, the sensor also reads outbound connection events 5156 and 5157 from the Security log. Windows writes them only with "Filtering Platform Connection" success auditing on; an administrator or Group Policy turns it on, never Guard. Every allowed connection then becomes a Security log event, so size the log for it. While auditing is off, guard doctor reports wfp: audit_policy_missing.

Antivirus and EDR

Defender Antivirus raised no detection on the Windows test laptop; CrowdStrike Falcon, SentinelOne and Defender for Endpoint in EDR block mode haven't been tested alongside Guard. They may flag Guard reading command lines, checking signatures, adding isolation filters and using job objects. No exclusions are needed; if scanning slows a machine, exclude only %ProgramFiles%\Rune Guard\, %ProgramData%\Rune Guard\ and guard-sensor.exe. Guard needs two of the 64 real-time ETW sessions all tools share, and won't start without them. With two products isolating the network, traffic flows only where both allow it.

WSL2

The Windows sensor doesn't see inside WSL2. For agents run there, install the Linux package in the distribution; see WSL2. Install hooks on each side: guard.exe hooks install for harnesses started in Windows, and guard hooks install inside WSL2. Claude Code's hooks have run live on both sides.

Then enroll the device with Guard Cloud. To remove Guard, see Uninstall a package install.