No telemetry, no analytics, no account
The only outbound connection is an explicit, user-initiated VirusTotal hash lookup: a hash, never file contents. VirusTotal is off unless you supply your own key, and --no-network refuses it regardless.
SECURITY POSTURE
A security tool that overstates its protection is worse than one that admits a gap.
WinSight distinguishes the desired mode you persisted from the effective runtime state it can actually prove against the live filtering engine. If it cannot verify enforcement exactly, it reports Degraded, never Active.
The privileged boundary is authenticated IPC, not the UI
The dashboard is an unprivileged IPC client and cannot change policy on its own. An unelevated administrator is refused exactly like a standard user.
Enforcement is opt-in and starts audit-only
Nothing is filtered until an elevated operator arms it, and there is no command-line path to arming: that is the security property, not a missing feature. Direct WFP mutation aliases are disabled.
Desired intent and effective state are never conflated
WinSight claims filtering only from the service's proven effective Active state, re-verified on every status read rather than assumed from what was persisted.
Enforcement survives reboots
Through service boot persistence, and the state is re-verified against the live filtering engine on every read.
Path-trust hardened installation
The service refuses to install from any path an unprivileged principal can write, and re-checks the file's 128-bit NTFS identity before use so it cannot be swapped in between.
No kernel driver
Driver-backed interception is deferred rather than half-built, because a production driver needs signing and a separate safety programme.
What WinSight can and cannot protect against
In scope
- Visibility into persistence, outbound connections, DNS, camera/mic use, hijack surfaces and signatures.
- Blocking a chosen application's outbound traffic at the Windows Filtering Platform, once you arm it.
- Alerting on new startup items and on decoy-file ransomware activity.
- Acting only when you choose: blocking a new startup item into a restorable quarantine, or suspending or ending a process with --confirm. Each action is revalidated first and recorded in a journal.
- Reporting whether Windows' own protections are actually on, including Microsoft Defender Controlled Folder Access and the vendor-neutral antivirus inventory, read without elevation and never modified.
Out of scope
- It is not antivirus or EDR, and does not guarantee detection of kernel rootkits, memory-only implants or every persistence technique.
- Real-time persistence blocking and ransomware interception (would require a signed kernel driver, which is not shipped).
- Changing any Windows or Defender setting on your behalf. WinSight reports posture and links to the Windows control.
- It complements Windows Defender and backups; it does not replace them.
Whether Windows' ransomware blocker is genuinely enforcing is a check of its own: how WinSight reads that posture →
The full threat model with trust boundaries and explicit exclusions: THREAT_MODEL.md →
Two privacy policies, stated separately
The WinSight application
No telemetry, no analytics, no account. Scan results stay on your device. The only outbound connection is the optional, user-initiated VirusTotal hash lookup, disabled by default, requiring your own API key, sending a SHA-256 hash and never file contents. Updates are manual: you download a new release and verify it yourself.
This website
This marketing site uses Vercel Web Analytics (cookie-free, aggregate-only) to count page views and anonymous conversion events such as download clicks. No advertising pixels, no cross-site tracking, no fingerprinting, no session replay, and no attempt to identify you. The site never collects executable paths, process names or anything from the WinSight application. The two are entirely separate systems: analytics here says nothing about what any scan found on your machine.
Qualified with evidence, not claims
The product code of v0.14.0 was qualified on native-x64 Windows 11 VMs after the September 2026 security audit, with a separate isolated control VM. The harness that ran it checks its own provenance, and every result is bound to exact artifact hashes.
32
gates, 0 failures
Full x64 campaign, among them installer lifecycle and upgrade, Guardian, response verbs, Cloud Files, ETW lifecycle and cleanup
35
checks, 0 failures
WFP/SCM transitions, rollback, connectivity and per-app scoping
13
checks, 0 failures
Path trust, ACLs and hostile TOCTOU scenarios
7
checks, 0 failures
Local IPC with elevated and restricted tokens
7 + 3
checks, 0 failures
Remote Network Logon and independent observer
The qualified candidates were local unsigned builds of the v0.14.0 product code; the published v0.14.0 binaries are the CI build of that code and were not themselves run in the VM. Native Arm64 CI passes build, tests, packaging and installer checks, but privileged Arm64 runtime and x64-on-Arm64 still require suitable hardware qualification. Independent human review of the EN/FR/ES presentation remains open.
Sources: docs/validation/2026-09-26-x64-qualification-fe953fe.md · docs/PRODUCTION_READINESS.md · docs/AUDIT.md, checked 2026-09-26
Release verification and code signing
- Every release ships per-asset SHA-256 checksums, an SPDX SBOM and GitHub build provenance you can verify with gh attestation verify.
- Released binaries are not yet Authenticode-signed: the project holds no code-signing certificate, so Windows warns on first run. The release build has a signing stage, which has never run end to end: there is no certificate to sign with.
- The build script verifies both the official SHA-256 and the Authenticode signature of its pinned Inno Setup compiler before using it.
Reporting a vulnerability
Security issues go through GitHub private vulnerability reporting, never public issues.
Report privately →Read the full documents
Threat model, trust boundaries, what is explicitly out of scope, and every validation record.