Skip to main content
The endpoint agent is a desktop application plus a background service that inspects AI traffic leaving the device. This page covers installing it. To remove it, see Uninstalling the agent. For the MDM-driven rollout across a whole company, see Fleet rollout.

​
What ships today

Both platforms are published on the console’s Downloads page, with the current version, the release channel and a SHA-256 checksum for each installer. Linux is not supported. The two platforms enrol differently:
The standalone per-user Windows .exe (Inno Setup) has been withdrawn. It installed into the user profile, which left the device token and the local policy owned by the person the agent is meant to protect, and it is a separate product identity that msiexec cannot upgrade in place. Existing .exe installs keep updating, but every new install should use the MSI.

​
Before you start

1

Check you have a license for Endpoint

The agent enrols against a workspace whose license includes the endpoint capability. Without it, enrollment is refused.
2

Windows: have the two values ready

A Windows install needs a cloud base URL (your workspace’s API host) and an enrollment token. Both come from Endpoint → Configurations → Install in the console. A Mac needs neither: the person’s work account is what enrols it.
3

Allowlist the agent in your AV / EDR

The agent runs a local TLS-inspecting proxy, which some endpoint products treat as suspicious. Do this before a wide rollout, not after the first ticket.

​
Install on Windows (single machine)

1

Download the MSI

Open Downloads in the console. The page shows the current version, the release channel, and a SHA-256 checksum for the installer. Verify the checksum before you run it:
2

Run it as an administrator

A double-click install walks through the normal MSI wizard and opens the dashboard once when it finishes.
3

Approve protection

On first run the agent asks to install its local inspection certificate and turn on the secure proxy. Until this is approved, nothing is inspected.
4

Sign in

Sign in with your work account. The device binds to your directory identity, and traffic from then on is attributed to you rather than to a bare hostname. See Identity binding.

​
Install on Windows (silent / fleet)

The MSI takes exactly two properties. Both are optional on the command line and both are per-machine, x64 only.
The console generates this exact line for your workspace, with a freshly minted token baked in, under Endpoint → Configurations → Install. The same screen streams a .zip containing install.bat and install.ps1 if you would rather push a script.
The downloaded install kit contains a live enrollment token. Treat the archive as a secret and store it in your MDM’s secret vault. The mint and the download are both written to the audit trail.
A property passed on the command line always wins. If you omit both, the installer keeps whatever the machine already has under HKLM\SOFTWARE\Blindsight, and only a genuinely fresh install falls back to the build’s compiled-in default. That is what makes an upgrade safe: a self-update runs msiexec with no properties and must not retarget a device IT pointed somewhere specific.
A bare msiexec /i Blindsight-<version>.msi /qn does not enrol a device unless the build was created with a token baked in, or the machine already carries one. Always pass ENROLL_TOKEN for a fleet push.

​
Install on macOS

macOS ships as a .dmg: drag Blindsight Mac.app into /Applications. macOS 11.0 is the minimum. There is no .pkg. There are two macOS builds, one per processor, and they are not interchangeable: neither will launch on the other’s chip. Apple menu → About This Mac says which processor a Mac has. A universal binary is not available to this product, because onnxruntime and cryptography no longer publish Intel macOS wheels, so each architecture is built and signed natively. The console’s Downloads page detects the Mac you are on and marks the matching build, but offers both, so an administrator collecting installers for a mixed fleet gets both from one screen.
1

Open the disk image

Download the build for the Mac’s processor and open it. Verify the checksum shown on the Downloads page first:
2

Drag the app to Applications, then open it

The disk image holds Blindsight Mac.app, a shortcut to Applications, and Uninstall Blindsight.command.
3

Sign in to enrol

Sign in with the work account inside the app. That sign-in enrols the device into your workspace and binds it to the person’s identity. There is no code or token to enter. See Identity binding.
4

Approve protection

When macOS asks, approve the inspection certificate and the protection service. Each asks for the person’s login password once. Until both are approved, nothing is inspected.
The macOS app is signed and notarized by Blindsight Technologies AG. It opens the way any other application does: no right-click, no Gatekeeper detour. Notifications are delivered through UNUserNotificationCenter and carry the app’s own icon and name, once the person has allowed alerts. The agent asks for that permission once, during first-run setup, and explains what it is for.

​
The macOS install kit

Endpoint → Configurations → Install also offers a macOS install kit: a .zip holding a README with the download links for both disk images on your release channel, their SHA-256 checksums and sizes, and the install and uninstall steps above. The kit and the disk images carry no enrollment token and no secret, so they can be handed to employees directly or published on an internal software portal.

​
Macs on a dedicated or self-hosted platform

A Mac talks to the Blindsight cloud by default. To point it at a single-tenant or self-hosted platform instead, push a configuration profile in the dev.blindsight preferences domain before the app is first opened: A per-user profile is read before the device-wide one. Enrolment still happens through the person’s sign-in.

​
What the install actually changes

Knowing this up front makes the security review shorter, and it is the same list uninstall reverses.

​
Windows

​
macOS

The PAC sends only AI service hosts to the local proxy and everything else direct. It also answers direct for the AI hosts whenever the local proxy is not listening, so a stopped agent never takes the machine offline. The coverage matches the Windows explicit-proxy engine below: browsers and every app that honours the system proxy settings are inspected, and an app that ignores them is not.
Never delete pseudonym_vault.db or vault.key from the machine state directory. They hold the only mapping from a surrogate back to what the person actually wrote. Losing them is permanent and visible to the user: every past conversation is left showing a realistic stand-in that can never be resolved again. An upgrade preserves them; a genuine uninstall wipes them on purpose.

​
Windows 11 and the network driver

Windows 11 turns Microsoft’s vulnerable-driver blocklist on by default and refuses the bundled capture driver. This is the stock configuration, not an exotic one. There is nothing for you or the user to do. The agent falls back to its explicit-proxy engine, which needs no driver, and first-run setup finishes as degraded rather than failing. The window opens and protection runs. What differs is coverage: The device reports protection_state = "degraded" with the blocklist named as the reason and sends a health event immediately, so you find affected machines from the fleet view rather than discovering them later.
Do not turn the blocklist off to get the driver loaded. The fallback is the supported path on Windows 11.

​
Upgrades

The agent checks a release manifest 60 seconds after start and then every 6 hours, verifies the download’s SHA-256 and size before installing it, and preserves device state across the upgrade: enrollment, the CA, the pseudonymization vault, and the local event spool all survive. Sign-in and settings survive too.
On a managed fleet, set auto_update = false (under [update] in the agent’s config, or BLINDSIGHT_AUTO_UPDATE=0) and push builds through your MDM instead, so version rollout stays on your change calendar.

​
Verify the install

Open Endpoint → Devices in the console. A healthy device shows up within a minute or two with a version, a protection state, and an identity. If the device never appears, the enrollment token is the usual cause: expired, revoked, at its activation cap, or never passed to msiexec at all.

​
See also

Uninstalling the agent

Remove it cleanly, and what gets wiped when you do.

Fleet rollout

Enrollment tokens, MDM push, and pilot-then-promote.

Identity binding

SCIM provisioning and the SSO device-code flow.

Devices

The fleet view, health, and tamper events.