Discovery

Discovery brings the AI agents on the machines your organization manages under OpenLatch without asking anyone to install anything. Your administrators deploy one discovery script through the fleet tool they already use. On each machine, a scan runs in every user’s own session. When it finds an agent OpenLatch knows, it installs the client for that user and enrolls it with your organization key. From then on, that user’s agents reach the decision point like the agents of any enrolled machine.

Discovery covers the machines your fleet tool reaches. Finding agents on machines your fleet tool does not manage is not available.

How it works

Figure 1. Deployed once with system privilege, discovery scans in each user's own session and enrolls the client for that user on a hit. Only the enrolled client sends anything.

Step	Where it runs	What happens
Deploy	Once per machine, with system privilege, through your fleet tool	The script copies itself to a folder only administrators can write, writes the key file, registers one schedule that runs in every user’s session, and starts it in the sessions already open. It never scans, never writes in a user’s home folder and never runs the client
Scan	In each user’s own session, as that user, every 24 hours unless you set another interval	The scan checks a short, fixed list of places where each agent leaves a trace. It never walks the disk, and it shows no window, console, tray icon or notification
Enroll	On a hit, in the same session	The scan installs the client for that user, the way the install script does, and runs one enrollment with the organization key. The user sees nothing and does nothing
Report	From the enrolled client	The client sends what the scan found on its existing event channel. The scan itself never calls OpenLatch

The schedule runs the local copy of the script. It never downloads and runs a script at scan time: a new version reaches a machine only when your fleet tool deploys it again.

What a scan looks for

The scan looks for the agents of OpenLatch’s catalog, through the same rules the client uses to find the agents it connects. It checks, in order:

Check	What it looks at
Configuration folders	Each agent’s own configuration folder in the user’s home
Relocated configuration	The variables an agent uses to move its configuration, as the scheduler’s environment provides them
Programs	A known program on the user’s path, a known install folder, a desktop application
Running processes	A running agent process. This counts as evidence that the agent is still there, never as a hit: it keeps an agent from being marked removed, and it never installs or enrolls anything

Only a missing file counts as absent. A probe the operating system refuses, or one that fails, is inconclusive and keeps the previous result.

An agent in the catalog that is not yet supported, such as Gemini CLI or OpenClaw, is still recorded. Its agent reads the control level Known with the note No enforcement adapter: OpenLatch sees it and cannot act on it. An agent the client connects keeps the control level the client gives it.

What discovery records and sends

The scan keeps its results on the machine, in a discovery folder in the user’s home that the client’s own uninstall never touches:

On the machine	Holds
The last scan	When it ran, with which privilege, which checks ran, and each catalog agent found with the check that found it, written as a path template, never as the expanded path
The transitions log	Each change since the last scan: an agent enrolled, enrolled again or removed, and a discovery change detected. It names the user by account number only
The enrollment marker	Whether this user had an enrolled client, its host identity and its organization
The discovery log	What each run did, size-capped

None of these files holds the key. A machine with no client installed, where the scan finds nothing, sends nothing. On a machine whose client is already enrolled, that client still reports what changed, such as an agent removed.

Once the client is enrolled, it sends the scan’s outcome on its existing event channel: what happened (detected, enrolled, enrolled again, removed, or a discovery change detected), how the agent was enrolled, when it was discovered, the scan privilege, the time of the last scan and the names of the catalog agents found for that user on that machine. It never sends a file path or an account number. Discovery reads no prompt, no file content and no browsing history, and it never blocks or removes an agent’s installation.

What the console shows

Where	What you see
The agent record	An Enrolled via discovery badge, a Removed badge once the agent is gone from its machine, and a De-enrolled badge when an admin de-enrolled its host
The agent’s Host tab	The machine the agent runs on, how it was enrolled, its last scan and scan privilege, the agents found, and every other agent on the same machine
Settings › Discovery	The command to deploy discovery, and every host of your organization, with the actions on each host. See Manage discovered hosts
Notifications	A notification when discovery enrolls an agent, enrolls it again after its client was removed, or finds it removed. No notification names an employee
The audit trail	One entry for each of those outcomes, and one when a scan finds the discovery schedule, script or key file changed

The owner of a discovered agent comes from your directory, exactly as for any other agent. When a connected directory finds no match, the agent is recorded as unattributed, at the root of your organization tree.

Removal and enrollment again

Removing the client does not remove discovery. When a user, or anyone, removes the client while the agent is still there, the next scan installs it again with the same host identity and records the enrollment again. Both the removal and the new enrollment stay in the record.

When every check finds an agent gone, the scan records it as removed. The agent’s history is kept, and the record clears the mark if the agent comes back.

An admin who wants a machine to stay out removes or de-enrolls it in Settings › Discovery. A de-enrolled machine is never enrolled again by a scan until an admin presses Re-enrol.

Limits to know

Situation	What happens
A user with no session the schedule can run in	No scan runs for that user. On Linux the user needs a running user manager (a login, or lingering enabled); on macOS a user who only connects over SSH is not scanned; on Windows the user needs an interactive logon. Agents used only outside such a session are not discovered
Configuration moved only in a shell profile	The scheduled scan does not read shell profiles, so it misses that location
A portable program in an unusual folder, with its configuration moved and the agent not running	Not detected
Discovery changed on a machine	Detecting that the schedule, the script or the key file changed is best effort, and only a scan on a machine with a client reports it. A disabled schedule, an uninstalled discovery and a user who never opens a session all look the same from the console
A machine never enrolled, where the scan finds nothing	The console does not list it. Your fleet tool’s own run reports show which machines ran the script. A machine enrolled earlier stays listed with its host

Discovery covers a misbehaving agent, not a malicious one. It is built to be visible: its schedule, script and log all carry the OpenLatch name, and it resists no one who wants to remove it.

Several users on one machine

Each user of a machine is scanned in their own session, and each gets a client of their own: on daemon and relay ports of its own and, on Windows, a client task named for that user. One user’s client never stops another’s. Each OS user’s agent is an agent of its own in the console.

On a shared machine, the local processes of every account can reach a user’s model relay listener. The relay holds no provider credential of its own, so a caller gains no provider access through it, but an agent session that was already running when its user’s relay moved can send a request to whatever holds the old port. The client reports such a move in its own output and in its doctor report.

Licensing

Situation	Counts as a licensed host?
A machine never enrolled, where the scan finds nothing	No
A machine enrolled earlier, where the scan now finds nothing	It counts while it stays active, like any enrolled host
A machine where the scan enrolls the client, including for an agent that is not yet supported	Yes
A container whose entrypoint enrolls the client	Yes, each start: every enrollment from a fresh container is a new host for as long as it stays active

Discovery can raise your active hosts above your contract. The host cap is soft: enrollment goes on, and licensing warns you. See Read licensing and usage.

Where to go next

• Deploy discovery, with the recipes for Intune, Configuration Manager and Jamf Pro.
• Manage discovered hosts in the console.
• The notice for your employees, for your works council and your data protection impact assessment.