Skip to content
DEFYNTA

Overseer

Documentation

How activation works, how to read a finding, what a rule actually covers, and how to undo it when Overseer gets in the way.

  • Windows dev build
  • Metadata only
  • No TLS interception
Development build - not for sale

There is no signed installer, no macOS or Linux client, and nothing that can hold a connection open while it asks you. Everything here describes what exists today, not what is planned.

Activating an installation

  1. In the app, open Account and choose Sign in with Defynta. It generates a key pair, keeps the private half locally, and registers the request.
  2. Your browser opens /overseer/activate. Sign in as usual - Overseer never sees your password and is never embedded in the app.
  3. Check the installation name, your plan, and how many of your five device slots are used. If all five are taken you can revoke one right there.
  4. Choose Authorize Overseer. We issue a one-time code valid for 60 seconds and your browser hands it back to the app.
  5. The app trades the code for a device credential, proving it holds the private key. Neither the key nor your password ever leaves the machine.

Nothing is emailed, no key is pasted, and no account identifier appears in a URL.

Reading a finding

Score and confidence are different

The score answers “how concerning is this?”. Confidence answers “how complete is the evidence?”. A high score with low confidence is an urgent unknown, not a proven threat.

Colour is never the only signal

Every finding has an icon, a label, a number and reason text. Yellow means suspicious, red means high risk, and both always name what produced them.

Reason codes are stable

DESTINATION_NEW_FOR_EXECUTABLE, EXECUTABLE_HASH_CHANGED and the rest keep their identifiers across releases, so an old rule still means what you thought it meant.

Rarity never blocks on its own

Newness, rarity, a missing signature, a country or an odd port cannot trigger an automatic block. That needs a current malicious verdict or several strong, independent signals.

What a rule actually covers

Before a permanent rule is written, Overseer shows you the sentence it becomes, for example: Always allow outbound TCP from the exact SHA-256 of Example App 4.2 to api.example.com on port 443, on any network.

  • An exact-hash rule stops matching when the app updates and moves to Needs review. It is never silently carried over to a new unsigned version.
  • “Allow” means Overseer will not block it. Windows Firewall, a VPN or an administrator policy still can. A block by Overseer stays a block.
  • Publisher and country scopes are broad, are labelled as broad, and are expert options.

If Overseer gets in the way

  • A program cannot reach the network. Open Diagnostics and use Remove all Overseer firewall rules. It only touches rules Overseer created.
  • The window will not open. Overseer lives in the tray and closing the window does not stop it. Use the tray icon, or relaunch - a second launch focuses the running instance.
  • It says Monitor only. That is the honest state of the Windows build: it watches and can add firewall rules, but it cannot hold a connection open while it asks you.
  • You want it gone. Uninstalling removes its firewall rules first, so removal can never leave a machine without network access.

Reference material

  • docs/overseer/platform-support.md - the honest support matrix
  • docs/overseer/privacy-data-map.md - field-by-field data map
  • docs/overseer/threat-model.md - assets, adversaries, mitigations, residual risk
  • docs/overseer/protocol-compatibility.md - activation and device API versioning
  • docs/overseer/dev-build-notes.md - what the development build does and does not do
  • docs/overseer/launch-blockers.md - what has to clear before this can be sold

Managing your installations: Overseer devices.

Copyright © 2024-2026

All rights reserved.