AI-tool discovery

Discovery finds the AI tools your people already use that nobody registered. The desktop app, installed on a machine, identifies the AI apps and command-line tools present there, drops everything non-AI on the device, and reports only the AI matches to your own server. They land in the Registry badged detected, not observed, feeding the same audit log as everything else.

There are two setup shapes: a simple install link each person opens once to self-enrol their machine, and an MDM managed mode for a silent fleet (IT ships the app plus a config profile; machines self-enrol on a timer). Both are detected-not-observed, and both are sovereign, findings go only to your own self-hosted server, never a vendor cloud. Operators set both up from Oversight → Registry → Connect → Endpoint discovery.

Ceiling: This is detected, not observed. The only thing transmitted is which AI provider, running or installed, and when, never a process list, browsing, file or prompt content, or what the tool did.

It is an inventory, not a usage metric. A tool is reported at most once per reporting window, so the record tells you a tool is in use here and cannot tell you how much it's used. Don't read the counts as volume.

Coverage is the enrolled, alive fleet only: a machine without the app isn't seen this way, and AI used inside a browser tab is covered separately by the extension below. A silenced or offline machine shows as stale, visible, never assumed clean.

What each tool can reach#

A tool being installed is the shallow half of the answer. The scan also reads each AI tool's own MCP configuration (the systems it has been wired to reach, such as a database, a ticket tracker or an internal API) and reports the server names only. That is what turns Claude Code is installed here into Claude Code is configured to reach production Postgres, which is usually the finding that matters.

Ceiling: This is declared, a step weaker still than detected. A configuration names a door; it never shows the door was opened. Someone can wire a tool to a system, never invoke it, and revoke the credential a week later, the declaration outlives all three. Only the server name is read: never an address, a credential, a command, or the file around it.

Each door appears as its own system in Registry → Systems, and on the tool's row in Registry → Workers.

Accepting a tool accepts it as configured. If that tool is later wired into something new, the new system is flagged on its own rather than absorbed by the earlier decision. On a fleet you have not reviewed yet, Baseline accepts everything as it stands today in one step.

Note: Accepting records a decision. It does not gate anything.

On your own machine#

The desktop app scans on its first launch, before you sign in or connect anything, and shows you what is there, including what each tool declares it can reach. Nothing leaves the machine at that point. That screen offers to keep the result in your workspace, which is on by default and which you can decline; take it and the tools are already in your Registry by the time you arrive.

Each tool on that screen says what it is (a coding agent, an assistant app, a local model runtime), so two tools with similar names on one machine are easy to tell apart. If it finds a coding agent the app can connect (Claude Code and the Codex CLI today), the same screen offers to govern it on this Mac, naming each tool. It's on by default, depends on keeping the result in your workspace, and connects only the tools it named: one installed afterwards is never wired by that choice. The hooks are installed once your workspace exists. This only happens for a workspace on your own machine; joining a company server uses that server's onboarding disclosure instead.

You can also do it later, or again: open the account menu → "My device & privacy" → "What I've reported" to see exactly what would be sent, then enrol and report, attributed to you. It's reachable from the tray at any time; quitting stops the sensor and the machine shows as stale.

The app runs on macOS (Apple Silicon), Linux (x86_64) and Windows (x64).

One coverage difference on Windows. There the scan finds a tool that is running, and finds one that declares MCP servers even while closed, but it does not yet read the installed-programs list the way it reads applications on a Mac. So a tool that is installed, not currently running, and declares nothing is missed on Windows and found on a Mac. Since the fleet sensor rescans every 30 minutes, anything a person actually uses is picked up the same day; what stays invisible is software installed and never opened.

Browser tabs#

The desktop app sees AI apps installed on a machine, but not AI used in a browser tab (the browser hides the site from the OS). A small Chrome extension closes that gap: it classifies AI web tools on-device by hostname only, drops everything else, and reports just the matches to your own server, same Registry, still detected, not observed.

It's on the Chrome Web Store as Damn, AI-tool discovery. One person can install it themselves in a click; for a fleet, push it through the Google Admin console or your MDM so it lands in every managed profile without anyone being asked.

Operators set the defaults (whether it reports, and whether it covers incognito) and can lock either so it's a company decision rather than a per-person one. A change reaches a browser within minutes.

What the person sees#

The extension is not silent about itself, and this is deliberate: a monitoring tool nobody can inspect is one people uninstall. Its toolbar popup shows the person, on their own machine, exactly what was reported and when, grouped by tool. A weak or ambiguous match reads as possible rather than a hard claim, so it doesn't assert more than it knows. There's a pause switch, unless your policy has locked it.

It holds permission for one destination: your server, granted when they connect and released when they disconnect. Not the sites they visit. And if that permission is later revoked from the browser's own settings, it says it has stopped rather than continuing to look like it's reporting.

Ceiling: The extension knows which AI tool is open in a tab, never the pages, the text you type, what the AI generates, your history, or your other tabs. It only reads a hostname, and it never blocks a page. Coverage is the browser profiles where it's installed.

Who uses what, attribution#

Enrollment ties each machine to a real person, so the Registry answers the question the feature exists for: which AI tools do our people use, so we can decide, allow, govern, or ask for removal. Expand a tool to see the machines and people it's on, or pivot to a By person view. Claim a detected tool to assign its owner, Allow one that's accepted but unowned, or Dismiss a false positive, so every real tool ends up in a decided state rather than flagged forever.

Where the tool is one damn.dev can govern, the same expanded view offers to connect it. On the machine that has it, that's one click. From anywhere else it's a link you send its owner, connecting writes a file on someone's computer, so it happens there, with their knowledge, never pushed from a console.

Ceiling: Attribution reports which AI tools are present on whose machine, existence, never what that person did, and never any content. It's governance visibility, gated to operators. Scheduled reporting of a person's tool usage is exactly the kind of thing your works-council / privacy process should sign off on; that disclosure is yours to make. The product's job is the on-device drop-at-source, the transparency panel every employee can see, and a sovereign destination.

From discovered to governed#

Discovery tells you a coding agent exists on a machine. Connecting it goes further: the agent reports each action into your audit trail, and your rules can gate it.

You decide when you create the onboarding link. Choose to govern their machine and the app sets both up in one step. The person sees a plain-language disclosure of exactly what is reported, on their own machine, before anything starts. Nothing is ever applied that they weren't shown. Leave it off and the machine stays discovery-only.

Note: Telling your people is still your job. In some jurisdictions it's a formal one, France's works-council consultation, for example. The app's disclosure is not a substitute for that process.

Ceiling: Connecting moves a tool from detected (it exists) to observed (it reports its actions) and best-effort gated (rules may deny an action). It never reads prompts, code, responses, or file contents, and it is not containment, the gate is best-effort and can be bypassed. It writes only the user's own config, with no elevated privileges, and disconnecting fully reverses it.

Set up a fleet#

Fleet tokens, the install link, the MDM config, and per-machine enrolment are all driven from Oversight → Registry → Connect → Endpoint discovery, which generates exactly what you hand to your MDM. For a managed fleet rollout across Jamf / Intune / Kandji, talk to us, we'll help scope the profile.

Note: No keystrokes, screens, files, clipboard, env vars, or browsing history ever leave a machine, everything non-AI is filtered on the device before anything is sent. Reports go only to your own self-hosted server, never a vendor cloud.

Next#

• Governing AI you don't run, connectors and honesty labels.
• Oversight & the Registry, where detected tools appear.