Skip to main content
This is how a company rolls Blindsight DLP out “like AD”: one silent push from the MDM, the directory auto-provisions every employee, and every device binds to a real identity. There are two independent axes; you almost always want both.
  1. Fleet software push. IT deploys the agent to every machine with no per-user clicks. Windows: .msi via Intune, GPO, or SCCM. macOS: a .dmg plus a managed-preferences profile. One workspace‑wide enrollment token is baked into the package; the agent self‑enrolls on first run.
  2. Directory sync + SSO. Your IdP (Entra, Okta, Google) provisions every employee into the workspace (SCIM) and binds each device to the matching directory user on first sign‑in (OIDC).
These are decoupled on purpose. The silent installer runs as SYSTEM / root and cannot know the human user, so identity is bound after enrollment via the SSO device‑code flow, opened automatically by the agent. The employee signs in once. See Identity binding for the directory and SSO side, and Installing the agent for what an install changes on a single machine. This page is the IT‑side rollout.

​
1. Create the fleet enrollment token

1

Open DLP → Endpoints

DLP → Endpoints → create token. The copy-paste install command with the token already baked in is on DLP → Configurations → Install.
2

Copy the token

Shown exactly once. Store it in your MDM secret vault. One token covers the entire company fleet across both OSes.
3

(Optional) Restrict the token

Token settings let you cap the number of activations, set an expiry, and limit it to a specific directory group.

​
2a. Windows push

Windows is the primary platform. The agent runs as a SYSTEM service named BlindsightDLP.
CLOUD_BASE and ENROLL_TOKEN are the only two properties the package takes. Both are 64‑bit, per‑machine, x64 only. Deploy via:
  • Intune as a line‑of‑business app.
  • GPO software installation.
  • SCCM package deployment.
The MSI writes HKLM\SOFTWARE\Blindsight (CloudBaseURL, EnrollmentToken, SSOLoginBase), generates a per-machine inspection root CA and adds it to the machine trust store (there is no shared fleet key), and installs the SYSTEM service. The service self‑enrolls and runs the SSO identity‑binding flow. An interactive install opens the dashboard once; /qn stays silent.
Passing a property on the command line always wins. If you omit both, the installer keeps whatever the machine already has in HKLM\SOFTWARE\Blindsight, and only a genuinely fresh install falls back to the build’s default. This is what makes an upgrade safe: a self-update runs msiexec with no properties and must not retarget a device that IT pointed somewhere specific.
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. Pass ENROLL_TOKEN for a fleet push.
The per‑user .exe installer (Inno Setup) has been withdrawn and should not be used for new installs, fleet or otherwise. It installs into the user profile, which leaves the device token and the local policy owned by the person the agent is protecting, so the tamper resistance the MSI gets from LocalSystem does not apply. It is also a separate product identity, so msiexec cannot upgrade it in place.
On Windows 11 the stock vulnerable-driver blocklist refuses the bundled capture driver and the agent falls back to its explicit-proxy engine, which covers less. This is expected and needs no action from you, but it does change coverage. See Windows 11 and the network driver for what is and is not covered, and how the device reports it.

​
2b. macOS push

macOS ships as a .dmg: drag Blindsight Mac.app into Applications. macOS 11.0 is the minimum. There is no .pkg. Managed configuration is delivered as a configuration profile in the dev.blindsight preferences domain, carrying the same three keys the Windows registry does: A per-user profile is read before the device-wide one. Push it with Jamf, Kandji, or Intune, then distribute the .dmg. The agent reads the managed config, self-enrolls, and prompts each employee once for SSO identity binding. Interception on macOS uses a pf anchor plus a local inspection proxy, with the org root CA in the login keychain and a root guardian daemon.
The macOS app currently ships unsigned. A user must right-click the app and choose Open, then Open again, the first time, to get past Gatekeeper. System notifications are delivered through osascript as a result, so they appear to come from Script Editor rather than Blindsight. Ask your account manager for a signed and notarized build before a wide macOS rollout.
A macOS build older than 1.0.29 reports its bundle version as 0.1.0 to Finder and to inventory tools, whatever the agent actually is. Read the version from DLP → Endpoints instead, which is reported by the agent itself.
The macOS System Extension (Network Extension transparent proxy) described in earlier versions of this page is not shipping. It is a scaffold that needs Xcode, an Apple Developer account with the Network Extension entitlement, Developer ID signing, notarization, and an MDM before it can be used. Do not plan a rollout around it. macOS coverage today is the pf-based path above.
Linux is not supported.

​
2c. Keeping the fleet up to date

The agent self-updates by default: it 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, the local event spool, sign-in and settings).
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.
Never delete %ProgramData%\Blindsight\pseudonym_vault.db or vault.key. They hold the only mapping from a surrogate back to what the person actually wrote, and losing them is permanent and visible to the user. A genuine uninstall wipes them; an upgrade does not. See Uninstalling the agent.

​
3. Verify rollout

Open DLP → Endpoints in the dashboard. Each machine appears with an Identity column. Tamper attempts (uninstall blocked by guardian, modified binary, disabled proxy) surface as high‑severity audit events under POST /agent/tamper-events.

​
Out-of-repo signing

Certain steps cannot be done inside Blindsight’s source tree. They require external certificates and Apple / Microsoft developer relationships. Windows installers and binaries are signed in the shipped builds. Talk to your account manager for the signed bundles tailored to your organisation.

​
SAML

SAML is schema‑ready in the backend but not enabled in this build. OIDC covers Entra, Okta, Google, and Ping. Open a ticket if you have a SAML‑only IdP.

​
Common workflows

  1. Create a token in DLP → Endpoints restricted to one directory group (engineering-pilot).
  2. Push the agent to that group via your MDM’s smart‑group scoping.
  3. Watch verdicts and tamper events for a week.
  4. Once you’re happy, mint a new token without the group restriction and promote to the whole fleet.
  1. Mint a new token in DLP → Endpoints.
  2. Update the MDM payload to embed the new token. Existing devices are unaffected; rotation only matters for new enrollments.
  3. Revoke the previous token once your MDM has rolled the new payload to every staging point.
  1. Revoke the device row in DLP → Endpoints.
  2. Ship the replacement with the same MDM policy as the rest of the fleet. The new device self‑enrolls and binds to the same directory user.
See Uninstalling the agent, which covers the silent uninstall command, what it reverts, and what it destroys.

​
See also

Installing the agent

Single-machine install, what it changes, and how to verify it.

Uninstalling the agent

Silent removal, the macOS teardown, and retiring the device row.