> ## Documentation Index > Fetch the complete documentation index at: https://docs.blindsight.io/llms.txt > Use this file to discover all available pages before exploring further. # Installing the agent > Install the Blindsight Endpoint agent on a single machine or across a fleet, and know exactly what it changes on the device. 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](https://docs.blindsight.io/endpoint/uninstall.md). For the MDM-driven rollout across a whole company, see [Fleet rollout](https://docs.blindsight.io/endpoint/fleet-rollout.md). ## What ships today | Platform | Package | How you get it | | - | - | - | | **Windows** | `Blindsight-.msi`, x64 | The **Downloads** page in the console, or your MDM. | | **macOS** | `Blindsight Mac.app` in a `.dmg`, one per processor | The **Downloads** page in the console, or your MDM. | 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: | Platform | How a device joins the workspace | | - | - | | Windows | The MSI carries a fleet **enrollment token** and enrols the machine on its own. The person then signs in to bind their identity. | | macOS | The disk image carries no token. The device enrols when the person **signs in** inside the app, and that same sign-in binds their identity. | > [!NOTE] > > 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: ```powershell theme={null} Get-FileHash .\Blindsight-.msi -Algorithm SHA256 ``` **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](https://docs.blindsight.io/endpoint/identity.md). ## 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. ```text theme={null} msiexec /i Blindsight-.msi CLOUD_BASE="https://api.blindsight.example.com" ENROLL_TOKEN="antde_xxxxxxxxxxxxxxxxxxxx" /qn /norestart ``` 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. > [!WARNING] > > 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](https://docs.blindsight.io/compliance/audit-trail.md). > [!NOTE] > > 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. > [!WARNING] > > A bare `msiexec /i Blindsight-.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. | Build | For | | - | - | | `Blindsight-Mac--arm64.dmg` | Apple silicon, M1 and later | | `Blindsight-Mac--x86_64.dmg` | Intel Macs | **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: ```bash theme={null} shasum -a 256 Blindsight-Mac--arm64.dmg ``` **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](https://docs.blindsight.io/endpoint/identity.md). **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. > [!NOTE] > > **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: | Key | Value | | - | - | | `CloudBaseURL` | Your platform's API host | | `SSOLoginBase` | `/api/auth/sso` | 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](https://docs.blindsight.io/endpoint/uninstall.md) reverses. ### Windows | Change | Where | | - | - | | Program files | `%ProgramFiles%\Blindsight` | | Machine configuration | `HKLM\SOFTWARE\Blindsight` (`CloudBaseURL`, `EnrollmentToken`, `SSOLoginBase`) | | Background service | `BlindsightDLP`, running as LocalSystem | | Machine state | `%ProgramData%\Blindsight` (device enrollment, CA material, event spool, pseudonymization vault) | | Per-user state | `%USERPROFILE%\.blindsight` (sign-in, settings, logs, local event store) | | Trust store | A **per-machine** inspection root CA added to the machine Root store. No shared fleet key exists. | | System configuration | System proxy, WinHTTP proxy, proxy environment variables, browser policies, and firewall rules that block QUIC so traffic falls back to inspectable TCP. The pre-existing configuration is snapshotted first. | | Scheduled tasks | `\Blindsight\ServiceGuard` and `\Blindsight\ConnectivityGuard`, which restart the service and repair the proxy configuration if either is disturbed. | ### macOS | Change | Where | | - | - | | Application | `/Applications/Blindsight Mac.app` | | Machine state | `/Library/Application Support/Blindsight` | | Per-user state | `~/.blindsight` | | Root guardian | LaunchDaemon `dev.blindsight.guardian` | | Login item | LaunchAgent `dev.blindsight.mac` | | Interception | An automatic proxy configuration (PAC) on every enabled network service, served on loopback by the agent, plus a local inspection proxy. Each service's previous automatic proxy is recorded first in `/Library/Application Support/Blindsight/network_proxy.backup.tsv`. | | Firefox | A `policies.json` inside the Firefox app bundle, because Firefox reads neither the system PAC nor the proxy variables. An existing company policy file is kept beside it and restored on uninstall. | | Trust store | The inspection root CA in the login keychain, and in any JDK trust store on the machine | 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. > [!WARNING] > > 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: | Engine | Covers | | - | - | | Capture driver | Every process, whether or not it honours system proxy settings. | | Explicit proxy | Browsers, and any app that reads the system proxy settings (WinINET, WinHTTP, environment variables, PAC, Firefox). Proxy-unaware apps are **not** covered. | 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. > [!NOTE] > > 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. | Channel | What it is | | - | - | | `auto` | The default. Follows whatever platform the device is enrolled against. | | `stable` | Promoted production builds. | | `staging` | Internal and pre-release builds. `beta` is an alias for this. | > [!WARNING] > > 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. | Identity status | What it means | | - | - | | `bound` | The employee completed SSO. Traffic is attributed to a directory user. | | `auto` | OS username matched a directory user via SCIM. Useful for non-user devices. | | `pending` | Agent enrolled, identity binding not yet completed. | 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](https://docs.blindsight.io/endpoint/uninstall.md)** > > Remove it cleanly, and what gets wiped when you do. > **[Fleet rollout](https://docs.blindsight.io/endpoint/fleet-rollout.md)** > > Enrollment tokens, MDM push, and pilot-then-promote. > **[Identity binding](https://docs.blindsight.io/endpoint/identity.md)** > > SCIM provisioning and the SSO device-code flow. > **[Devices](https://docs.blindsight.io/endpoint/devices.md)** > > The fleet view, health, and tamper events. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.