Install Scout for Endpoint
One sensor per machine. Install it, let it run, and the machine's AI usage appears under Systems and Events in your portal. Every path below does the same three things: puts one static program in place, trades your organization's enrollment key for a token locked to that machine, and registers a resident service that keeps the sensor running. The key is not kept on the device.
The enrollment key, and every download and command with the key already filled in, are on the portal's Sensors page (Settings › Sensors, owners). The step-by-step guides are in the portal under Help.
Which path
| You have | Use | Guide |
|---|---|---|
| A Windows PC | the installer built for your organization, with nothing to type | Install the Windows agent |
| Intune | the .msi as a line-of-business app, with the key in its command-line arguments | Deploy the Windows agent with Intune |
| Group Policy, SCCM, an RMM | one install command, run as the system account | Deploy the Windows agent with Group Policy, SCCM or an RMM |
| A Mac | the .pkg, then one command in Terminal | Install the macOS agent |
| Jamf, Kandji, Mosyle, Addigy | a configuration profile carrying the key, then the .pkg | Deploy the macOS agent with Jamf, Kandji, Mosyle or Addigy |
| Intune, for Macs | the profile, then a shell script | Deploy the macOS agent with Intune |
| Debian, Ubuntu, RHEL, Fedora | the .deb or .rpm, with a settings file for fleets | Install the Linux agent |
| Browsers on machines that get no agent | the Chrome Web Store extension, by policy or by hand | Add the browser sensor, Deploy the browser sensor by policy |
Downloads live under https://openwake.ai/dl/agent/latest/ with a SHA256SUMS file beside them that covers every package. Every download is checksum-verified, and every update after the first install is verified against Openwake's signed release manifest.
What it needs from the network
Outbound HTTPS only, to api.openwake.ai (reports, enrollment, the update manifest) and openwake.ai (downloads). No inbound ports. A proxy set for the service is honored. Reports are small, typically a few kilobytes, and go out within five minutes of a change or every thirty minutes as a heartbeat. What to safelist on each system, and how the agent finds a proxy: Network requirements and safelisting.
What it reads, and never does
The agent reads which AI tools and MCP servers are installed, which programs run and whom they connect to, and the names of model-key variables. It never reads what a person typed, anything inside an encrypted connection, or a file's contents. The browser sensor classifies what is submitted to a recognized AI site on the machine and sends labels, never the text, unless the organization has turned on evidence collection. How Openwake knows.
Tamper resistance
- Machine-wide installs are owned by root or SYSTEM. A user without admin rights cannot stop, edit or remove the sensor, and the configuration, device token included, is readable by root only.
- The device holds a token bound to its own device id, not the enrollment key. A stolen token reports as that one device and can be revoked from its system's page without touching anything else; revoking the enrollment key does not disturb enrolled devices.
- A sensor that goes quiet still shows on Systems with its last report time, so a stopped or removed sensor is visible rather than silent.
- Updates are signature-checked and staged; there is no path that fetches and runs anything unsigned.
- A local administrator can stop it, as with any endpoint software. The portal shows that it stopped.
Upgrading and removing
Sensors update themselves from the signed release manifest; nothing is pushed after the first install (How sensors update). Removal is one command, or the package's own uninstall, with an authorization an owner issues where the organization requires one (Remove a sensor).
Credentials, named
- Enrollment key (ow_install_…): enrolls sensors into the organization and nothing else. The service refuses it on every other route, it is rate-limited, and an owner revokes it without touching the sensors it enrolled. Managed under Settings › Credentials & API. A deployment key goes into an MDM or a fleet package and lasts until revoked; a manual key, for a person running an install, expires after 14 days unless you pick 7, 30 or never, and can carry a use cap.
- Pairing token (ow_pair_…): each machine's agent asks for its own and writes it into the browser's managed policy so the browser sensor can enroll itself. It is scoped to that one machine, lasts fourteen days, spends after five uses, and the agent rotates it. It is published to the machine's browser policy on purpose, because the browser reads that policy as the signed-in user.
- Device token (ow_dev_…): what enrollment returns, locked to one device. The sensor keeps it; the enrollment key is never stored on the machine.
- Openwake ID (OW-XXXX-XXXX-XXXX): the sensor's id, derived from the organization and the machine's own identity, so a reinstall, a token rotation or a redeploy lands on the same record and nothing is counted twice.
- Removal authorization (owua1.…): a short-lived signed string that lets a sensor leave cleanly, issued by an owner or an admin for one machine (15 minutes, one use) or for the organization (30 minutes, with an authenticator code, a reason and the organization's name). The agent verifies it before anything is removed; each issue, use and revocation is in the audit log.