Endpoint Enrollment

Governing shadow AI needs the endpoint agent on the device. This page is the operational half of shadow AI discovery: how devices are enrolled, attributed to a person, and kept working.

What gets installed?

A lightweight system service — AgentWatch Connect — shipped as signed installers for macOS, Windows and Linux. On the device it identifies traffic bound for known public AI services, stamps the corporate user identity, and forwards it to your gateway so the activity is attributed, audited and policy-checked.

It is designed to be unremarkable in operation: it runs as a managed service, survives reboots, and fails open — if the gateway is unreachable, the user’s traffic still works rather than the device losing AI access.

How does a device get enrolled?

Four routes, in decreasing order of user involvement:

Route	How it works
Zero-touch MDM	The installer reads a managed preferences profile pushed by your MDM and enrolls itself with no user interaction — either a direct API key or a per-organization enrollment token
Self-service portal	A tenant-branded enrollment page where an employee signs in, downloads the right installer, runs it and clicks Finish setup — no server address, email or key to type (Connect 1.0.152 or later; on 1.0.150 the setup window still asks for all three)
Enrollment token	A per-organization, rate-limited token that mints a real gateway key for the device on first contact
Manual	An administrator supplies the key directly, for lab and pilot devices

Enrollment is organization-scoped: a token can only ever enroll a device into the organization that issued it.

How is activity attributed to a person?

The agent stamps the corporate identity on every forwarded request, which is the same mechanism delegated identity uses on the API path. Where a device carries no identity — a DNS-steered deployment, or a shared kiosk — attribution falls back to the organization by egress IP, which is honest about being organization-level rather than inventing a user.

Consumer accounts are a real limitation worth stating plainly: activity from a personal address that does not exist in your directory cannot be mapped to an employee by email. It is still visible, still policy-checked, and still attributed to the device and organization.

Why does the agent install a certificate?

Because content inspection requires it. Public AI services are reached over TLS, so applying DLP to what an employee pastes into a chatbot means terminating that TLS on the device. The agent installs a local trust anchor to do so, distro-aware across the platforms it supports.

Without that trust step you still get discovery — which services are being used, by whom, how often — but not content inspection. Some organizations deliberately stop at discovery; both are supported, and the console is explicit about which one a device is providing.

Can traffic be steered without an agent?

Yes, two ways, with a trade-off:

• DNS steering — a DNS redirector resolves known AI domains to your gateway. No software on the device, but attribution is organization-level and content inspection still requires the certificate to be trusted on endpoints. Managed DoH profiles are supported for macOS and iOS.
• Existing proxy or CASB — AgentWatch accepts the identity headers that Zscaler, Forcepoint and Netskope already stamp, so an organization with a corporate proxy can route AI traffic through the gateway with no endpoint change at all.

How do I install the agent?

Linux (servers and VMs) — a one-liner that downloads the matching binary from your AgentWatch server, installs the machine-wide systemd service and configures credentials. It is idempotent, so re-running it upgrades in place. Supported: Ubuntu/Debian and RHEL/CentOS/Rocky/Alma/Fedora, x86_64 and aarch64. Needs AgentWatch 2.0.360 or later on the server.

Run it as a normal user with sudo rights (not in a root shell), so the service runs as that user:

export AGENTWATCH_SERVER_URL="https://<your-agentwatch-host>"
export AGENTWATCH_EMAIL="john.doe@acme.com"     # the employee this machine belongs to
export AGENTWATCH_API_KEY="ak_…"                # that employee's gateway key
curl -fsSL "$AGENTWATCH_SERVER_URL/agent/install.sh" | sudo -E sh

Keep the -E: it is what passes the three variables through sudo. If your sudo policy does not allow -E, pass them to sudo directly instead:

curl -fsSL "$AGENTWATCH_SERVER_URL/agent/install.sh" | \
  sudo AGENTWATCH_SERVER_URL="$AGENTWATCH_SERVER_URL" AGENTWATCH_EMAIL="$AGENTWATCH_EMAIL" \
       AGENTWATCH_API_KEY="$AGENTWATCH_API_KEY" sh

The installer ends with Installed. and the commands below. Confirm the service is running and the machine is intercepting:

systemctl is-active agentwatch-connect          # active
agentwatch-connect status                       # shows your server and email
getent hosts api.openai.com                     # 127.0.0.1 — routed through Connect

Within about 30 seconds the machine appears under Agent Fleet in the console with Proxy running, CA trusted and Hosts active. Send any request from the machine (for example with the OpenAI SDK) and it shows up in Usage Insights under that employee.

Symptom	Cause	Fix
Error: Node.js is required, or an agent.js that fails with an ELF / Exec format error	the server is older than 2.0.360 and serves a legacy installer	upgrade the AgentWatch server, then re-run the one-liner
AGENTWATCH_SERVER_URL, AGENTWATCH_EMAIL and AGENTWATCH_API_KEY must all be set	sudo without -E dropped the exported variables	keep sudo -E, or use the second form above
the download is not a Linux binary	AGENTWATCH_SERVER_URL points at something other than the AgentWatch server (a login page, a proxy)	use the console’s address, starting https://
service activating / journal shows no config found	Connect 1.0.145 or earlier, installed with sudo	upgrade the server (it serves the fixed client) and re-run the one-liner
a request returns 401 Authentication required from AgentWatch	server older than 2.0.360	upgrade the AgentWatch server
No systemd on this machine	a container or minimal image	start it in the foreground: sudo agentwatch-connect run
unable to get local issuer certificate, and the computer never appears in Agent Fleet (any OS)	a TLS-inspecting gateway (Cisco SWG, Zscaler, Netskope…) re-signs the connection with a root Connect did not trust	Connect 1.0.147 or later trusts the operating system’s roots automatically; or exempt your AgentWatch address from TLS inspection on the gateway

Windows notes. Administrator approval is needed once, when Setup runs: it installs the Connect certificate for the whole computer and registers a service that starts at boot. From Connect 1.0.147 Setup does this even before anyone has entered a server or key, so afterwards an employee without admin rights can configure Connect and switch interception on and off with no further prompt. On an install from before 1.0.147 the first Enable Interception still asks once; IT can do the same from an administrator PowerShell: & 'C:\Program Files\AgentWatch Connect\agentwatch-connect.exe' install — or push the installer and managed configuration through your MDM, which needs no prompt at all. If antivirus blocks the bundled browser-compatibility component, allow C:\Program Files\AgentWatch Connect\curl-impersonate\curl-impersonate.exe; the Connect log names the reason when it cannot start.

Managed computers. When Connect is configured by your MDM (any OS), the app hides the off switch and, from Connect 1.0.147, Connect itself refuses to turn interception off — a request from the app, a script or another program on the computer gets 403, managed by your organization. To stop interception, remove the managed configuration or uninstall Connect with administrator rights.

macOS and Windows — download the signed installer from the enrollment portal (below) or from your MDM distribution point and run it. Both register a managed system service that starts at boot.

Kubernetes and containers — the agent also runs as a sidecar or per-node DaemonSet, exposing explicit opt-in proxy endpoints rather than intercepting traffic. A DaemonSet manifest, a sidecar-injection example and a Helm chart ship with the agent.

How do I enroll a computer from the command line?

Most computers should never need this: deploy the installer and settings file through your MDM and Connect enrolls itself. The command line is for scripted and headless installs — build pipelines, lab machines, servers — and for IT repairing a single computer. The console shows the complete command, with your server and token already filled in, under Agent Fleet → Agent Connect Settings → Advanced: scripted / headless install.

enroll needs all three of these:

Flag	Value	Rule
--server	your AgentWatch address, e.g. https://agentwatch.acme.com	the bare origin — scheme and host (and port, if any). No path: https://agentwatch.acme.com/platform/settings is wrong
--token	the enrollment token from Agent Fleet → Agent Connect Settings	the organization’s token, not a personal ak_ key
--email	the employee’s work email	must be an employee in Employee Management (or created by SCIM / CSV) before enrolling

Write each flag and its value as two words (--server https://…), not --server=https://….

Windows — open PowerShell as Administrator (Start → type PowerShell → right-click → Run as administrator) and use the full path, because the install folder is not on PATH:

& "C:\Program Files\AgentWatch Connect\agentwatch-connect.exe" enroll --server https://agentwatch.acme.com --token aw-enroll-0b6f… --email jane.doe@acme.com

macOS and Linux:

agentwatch-connect enroll --server https://agentwatch.acme.com --token aw-enroll-0b6f… --email jane.doe@acme.com

A successful run prints Enrollment successful!, the user and the server. Within about 30 seconds the computer appears under Agent Fleet, attributed to that employee.

Symptom	Cause	Fix
Usage: agentwatch-connect enroll --server <url> --token <enrollment-token> [--email <user-email>]	--server (or --token) is missing — older consoles showed enroll --token <TOKEN> without it — or a flag was written as --flag=value / --server-url	give all three flags, each as --flag value, exactly as in the examples above
Invalid JSON response from server	--server has a path, or points at something other than AgentWatch (a login page, a proxy)	use the bare origin you open the console with, e.g. https://agentwatch.acme.com
getaddrinfo ENOTFOUND <host> / ECONNREFUSED / ETIMEDOUT	the computer cannot reach that address	check the address for typos, and that the computer is on the company network or VPN
Invalid enrollment token	the token is wrong or was regenerated	copy it again from Agent Fleet → Agent Connect Settings
This email is not provisioned, followed by a sign-in code	the email is not an employee in this organization	add the employee in Employee Management (or via SCIM / CSV) and re-run, or approve the code by signing in as the employee
This organization requires each device to be approved by signing in	Require sign-in to approve each computer is on	approve the code the command prints by signing in from any browser
an automatic enrollment failure printed before the command’s own output (Windows, MDM-managed PCs)	Connect first retries the MDM configuration on every command	harmless for the manual command; fix the MDM configuration if it keeps failing

How do I enroll a fleet without touching each device?

Zero-touch via MDM. Push a managed preferences profile containing either a direct API key or a per-organization enrollment token. The agent reads it on first start and enrolls itself with no user interaction. Because the profile is read by path rather than by merged domain, a DLP policy on the device cannot suppress it.

Deploying with an MDM. Step-by-step rollouts — silent install commands, the exact managed-configuration keys per OS, what employees see, verification, upgrades and pausing — are in Deploying Connect with JumpCloud (Windows, macOS and Linux) and Deploying Connect with Microsoft Intune (Windows and macOS).

Self-service portal. Turn on the tenant-branded enrollment portal (Settings → Enrollment Portal), then send employees the link — Agent Fleet → Agent Connect Settings shows it with a copy button. With Connect 1.0.152 or later the whole install is a double-click and one confirmation — see How does Finish setup work? below. With Connect 1.0.150 or earlier, the setup window still asks for the Portal Address (your AgentWatch address), the employee’s email and their API key; to enroll those versions with no typing, deploy through an MDM.

How does Finish setup work?

Requires Connect 1.0.152 or later on Windows, macOS and Linux desktop, and a portal whose identity check is the emailed code (Settings → Enrollment Portal → Identity & access → Identity mode → Email OTP) or SSO. The employee:

Step	What the employee does	Typing?
1	Opens the portal link and signs in (SSO, or the emailed six-digit code)	the code only, if not SSO
2	Clicks Install Connect — the signed installer for their OS downloads	no
3	Runs the installer and approves the administrator prompt (Windows UAC; on Linux the package install’s password prompt; the macOS .dmg is dragged to Applications)	admin password if the OS asks
4	Clicks Finish setup on the portal page; the browser asks to open AgentWatch Connect — allow it	no
5	AgentWatch Connect shows Connect this computer to agentwatch.acme.com? — they click Connect	no
6	Connect switches interception on (macOS asks for the Mac password once; Windows needs nothing more) and shows Connected as jane.doe@acme.com	admin password on macOS

What happens underneath: after step 1 the portal has verified who the employee is. At step 4 it mints a single-use setup code valid for 10 minutes (XXXX-XXXX-XXXX, stored hashed on the server) and offers the link agentwatch-connect://enroll?server=<your public address>&code=<code>. Connect does nothing with the link until the employee clicks Connect; it then redeems the code at POST /portal/api/redeem and receives that employee’s own gateway key — the same key the sign-in approval and enroll give them — and saves it the same way the setup form does. The server address comes from the same public-address setting the MDM files use (AW_PUBLIC_BASE_URL, then the proxy’s forwarded headers).

If nothing happens at step 4 (the browser blocked the link, or the OS has not registered Connect yet), the portal shows the setup link with a Copy button. Open AgentWatch Connect, choose Finish setup with a code, and paste it — or type the server and code shown under it. Codes are single use: use Get a new code on the portal page if one expired. An employee already signed in to the console can do the same from My Dashboard → Download AgentWatch Connect → Finish setup.

Who can get a code. Only an employee who exists in Employee Management (or was created by SCIM / CSV) and is not suspended; the code hands over their own key and never creates anyone. A portal set to Domain or Name only — where anyone can type any address — never issues one: the page says so and the setup window falls back to asking for the server, email and key.

Require sign-in to approve each computer. With that policy on, the portal sign-in is the approval when it is a sign-in: SSO (or the console sign-in) qualifies, the emailed code does not — it proves the mailbox, not a sign-in — and is refused with This organization requires each device to be approved by signing in. Employees then sign in to the portal with SSO.

What Connect refuses. A computer managed by your MDM ignores the link (the MDM owns its configuration). A computer already connected to a different AgentWatch server refuses it; the same server is accepted, so a shared computer can be moved to another employee. Only https server addresses are accepted. Every completed setup is in Settings → Audit Logs as agent.device_enrolled, method portal-code.

Symptom	Cause	Fix
portal: Finish setup needs a verified sign-in	the portal’s identity mode is Domain or Name only	set it to Email OTP, or configure SSO, under Settings → Enrollment Portal
portal: You are not set up as an employee in AgentWatch yet	the email is not in Employee Management	add the employee (or provision via SCIM / CSV) and click Get a new code
portal: This organization requires each device to be approved by signing in	Require sign-in to approve each computer is on and the employee used the emailed code	sign in to the portal with SSO
Connect: This setup code is not valid any more	the code was used, is older than 10 minutes, or the portal was switched off	click Get a new code on the portal page
Connect: This computer is already connected to a different AgentWatch server	the computer was set up for another server	disconnect it in Connect first, or ask IT
Connect: The server in that setup link is not a secure (https) address	the server’s public address resolves to http://	set AW_PUBLIC_BASE_URL to your https:// address
clicking Finish setup does nothing	the browser or OS has no handler for agentwatch-connect:// yet (Connect 1.0.150 or earlier, or the app was never opened on macOS)	copy the setup link and paste it into Finish setup with a code in Connect

Enrollment token. For scripted builds, issue a per-organization token and pass it to the installer; the device exchanges it for a real gateway key on first contact. The token is organization-scoped and rate-limited, so it can only ever enroll devices into the organization that issued it.

Where do employees get the enrollment portal link?

In the console, Agent Fleet → Agent Connect Settings shows your organization’s portal link with a Copy button:

https://<your-agentwatch-host>/portal?org=<your-organization-slug>

Send it to employees (email, intranet, onboarding checklist), or use it as your network’s captive-portal page. Since 2.0.366 the link uses your organization’s readable slug; older links with the organization id keep working. If the panel says the portal is off, switch it on under Settings → Enrollment Portal — and for Finish setup, choose Email OTP or SSO there, and configure an email sender under Settings → Email Notifications if you use Email OTP.

Testing the portal yourself? If you download an installer from the portal in the same browser where your admin console is open, the console slows down or seems not to load until the download finishes. That is the browser’s HTTP/2 connection being shared, not the server; open the console in a different browser. See Troubleshooting.

How do I make employees sign in to the portal with SSO?

The portal reuses the single sign-on provider your organization already uses for the console — Microsoft Entra ID over SAML or OIDC both work. Nothing changes in the identity provider: the portal returns through the same reply / redirect URL the console sign-in uses.

1. Make sure the provider is Active under Settings → Single Sign-On.
2. Under Settings → Enrollment Portal → Identity & access, choose it by name in SSO provider. The list shows only this organization’s enabled providers; No SSO (the default) turns the button off.
3. Tick Require SSO to hide the email box, so SSO is the only way in.
4. Leave SSO start URL (optional override) empty. It is ignored whenever a provider is selected, and is only for an external sign-in page that returns ?portal_email= itself. An identity provider’s own login URL (for example https://login.microsoftonline.com/<tenant>/saml2) does not work there — Entra needs a SAML request that only AgentWatch can create.
5. Save, open /portal?org=<your-slug> and click Sign in with SSO. You should sign in at the identity provider and come back to the portal’s install step — not to the admin console.

The enrollment token is bound to the email the identity provider verified. The same rules as console sign-in apply: the person must already be an employee of this organization (unless the provider auto-creates users), the account must be active, and both the provider’s Domain restriction and the portal’s Allowed email domains apply. If sign-in does not finish, the portal shows the reason:

Message on the portal	Cause	Fix
the configured SSO provider is not an enabled provider of this organization (or the dropdown shows Unavailable — …)	the saved provider was disabled, deleted, or belongs to another organization	pick an Active provider from the SSO provider list and save
sso_error=domain_not_allowed	the employee’s email domain is outside the provider’s Domain restriction or the portal’s Allowed email domains	widen the restriction, or sign in with an allowed address
sso_error=no_account_in_organization	the person signed in at the identity provider but has no employee account in this organization, and the provider does not auto-create users	add them (SCIM, invite or Add employee), or turn on Auto-create for the provider
sso_error=account_in_other_organization	that address belongs to an employee of a different organization	use the portal link of the organization they belong to
sso_error=account_disabled / pending_approval / sso_rejected	the employee’s account is disabled, or their SSO access is pending or rejected — the same rule console sign-in applies	re-enable or approve the employee in Employee Management
sso_error=provider_org_mismatch	the sign-in finished through a provider of a different organization	use this organization’s provider ID
{"error":"org query parameter required"}	a build earlier than the fix for this — the SSO button did not work on any protocol	upgrade

Do Windows computers need anything done when upgrading?

No. Run the new installer over the existing one, or let Connect update itself. Every install repairs the permissions on C:\ProgramData\AgentWatch and keeps the configuration, so a computer that was connected stays connected.

Connect 1.0.151 and earlier could leave the files in that folder with no usable permissions after a fresh install — the computer then showed Disconnected after setup and never appeared in Agent Fleet, and the certificate key could be read by any local user. Installing 1.0.152 fixes both automatically; no commands are needed. If a computer is still Disconnected after upgrading, open AgentWatch Connect and click Enable Interception: Windows asks for administrator approval once, and that run repairs the folder.

How does a computer know which employee it belongs to?

The enrollment token is shared by the whole organization, so it identifies the tenant, not the person. Connect resolves the person the same way on macOS, Windows and Linux, and always ends up holding that employee’s own gateway key:

Order	Source	Notes
1	Email in the managed config	only a real address — an unsubstituted $EMAIL / {{mail}} is ignored
2	the signed-in Windows user’s UPN	domain- or Entra-joined PCs only
3	<login name>@<EmailDomain>	only when you set EmailDomain; no domain is ever guessed
4	sign-in approval	the employee signs in once in the browser and approves the code shown on the computer

The managed config lives in the same place every MDM can write, and nowhere a user can:

OS	Location
macOS	managed preferences ai.iterate.agentwatch-connect
Windows	HKLM\SOFTWARE\Policies\AgentWatch\Connect
Linux	/etc/agentwatch/connect.json — must be owned by root and not group/world-writable, otherwise it is ignored

With Agent Fleet → Agent Connect Settings → Require sign-in to approve each computer turned on, steps 1–3 are no longer accepted on their own and every computer is approved by whoever signs in — the identity then never depends on what the computer reports. An approval opened from a different network than the computer must type the code rather than click a link. Every enrollment is in Settings → Audit Logs as agent.device_enrolled.

Per-OS JumpCloud recipes and a troubleshooting table are in the Endpoint Enrollment Guide.

How do I verify a device is actually being governed?

Enrollment alone is not inspection. On the device:

agentwatch-connect status        # service, enrollment, and interception state

Then open a public AI assistant in a browser on that device and send a harmless message. Within a few seconds it should appear in Usage Insights attributed to that employee. If the device shows as enrolled but nothing arrives:

Symptom	Cause	Fix
Enrolled, no traffic captured	Interception not enabled, or the certificate is not trusted	Re-run the installer; on Windows confirm the elevation prompt was accepted
Traffic captured, no user	The identity is empty or unknown to this organization	Set AGENTWATCH_EMAIL to a provisioned employee, or enable Auto Create Users
Browser shows a certificate warning	The local trust anchor was not installed	Re-run the installer as administrator / with sudo
Activity attributed to the organization, not a person	Device has no identity (DNS-steered or shared)	Install the agent, or map the LAN IP to a user

How do I uninstall Connect?

Uninstalling removes everything Connect put on the computer and restores direct access to the AI services: the service, the hosts-file redirection, the Connect certificate (system store, browser certificate databases, macOS keychains), the browser DNS-over-HTTPS policies it set, any DNS or proxy auto-config change, its helper scripts and the CA environment variables in shell profiles. It is non-interactive (an MDM can run it), and safe to run twice. It needs administrator rights.

Computer	Installed by a person	Installed by an MDM
Windows	Settings → Apps → Installed apps → AgentWatch Connect → Uninstall	Intune: assign the app as Uninstall (command "C:\Program Files\AgentWatch Connect\unins000.exe" /VERYSILENT /SUPPRESSMSGBOXES /NORESTART). JumpCloud: run the same command as a Windows Command
macOS	sudo "/Applications/AgentWatch Connect.app/Contents/Resources/uninstall.sh"	Run that path as a root script from the MDM (Jamf policy, JumpCloud Command, Intune shell script)
Linux (.deb)	sudo apt remove agentwatch-connect	the same, from the MDM’s command runner
Linux (.bin or one-liner)	sudo agentwatch-connect uninstall	the same, as root

Since Connect 1.0.150 the Windows uninstaller runs agentwatch-connect uninstall first. Before that it removed the service and the files but left the hosts-file entries and the certificate behind, so ChatGPT, Claude and other redirected sites stopped loading after Connect was removed. On a computer uninstalled with an older version, run this once from an Administrator PowerShell to clean up (or reinstall 1.0.150 and uninstall it):

# remove the AgentWatch block from the hosts file and the Connect certificate
$h = "$env:SystemRoot\System32\drivers\etc\hosts"
$t = Get-Content $h -Raw
$t = [regex]::Replace($t, '(?s)\r?\n?# >>> AgentWatch Connect - DO NOT EDIT BELOW.*?# <<< AgentWatch Connect - DO NOT EDIT ABOVE\r?\n?', "`r`n")
Set-Content -Path $h -Value $t.TrimEnd() -Encoding ASCII
certutil -delstore Root "AgentWatch Connect CA"
ipconfig /flushdns

What is left on purpose. The uninstall output lists these:

• MDM-owned settings — HKLM\SOFTWARE\Policies\AgentWatch\Connect (and the legacy HKLM\SOFTWARE\Policies\Iterate\AgentWatchConnect) on Windows, the configuration profile and /Library/Managed Preferences/ai.iterate.agentwatch-connect.plist on macOS, /etc/agentwatch/connect.json on Linux. The MDM put them there; remove them in the MDM (unassign the policy or profile). While they remain, a reinstall enrolls by itself again.
• Each person’s own settings — ~/.agentwatch-connect (Windows %USERPROFILE%\.agentwatch-connect) and the key stored in their keychain, so a reinstall keeps the server, email and key.

Removing personal settings too (--purge). Add --purge to remove them for every user on the computer:

sudo agentwatch-connect uninstall --purge                                             # Linux (.bin / one-liner)
sudo apt purge agentwatch-connect                                                     # Linux (.deb)
sudo "/Applications/AgentWatch Connect.app/Contents/Resources/uninstall.sh" --purge   # macOS

On Windows, run "C:\Program Files\AgentWatch Connect\agentwatch-connect.exe" uninstall --purge from an Administrator prompt, then uninstall from Settings (or unins000.exe).

Check it worked.

# macOS / Linux - nothing should print
grep -i "AgentWatch Connect" /etc/hosts
# Linux
ls /etc/ssl/certs | grep -i agentwatch; systemctl status agentwatch-connect   # "could not be found"
# macOS
security find-certificate -c "AgentWatch Connect CA" /Library/Keychains/System.keychain   # "could not be found"

# Windows - both should find nothing
Select-String -Path "$env:SystemRoot\System32\drivers\etc\hosts" -Pattern "AgentWatch Connect"
certutil -store Root "AgentWatch Connect CA"

Symptom after uninstalling	Cause	Fix
ChatGPT / Claude do not load on Windows	Uninstalled with Connect older than 1.0.150: the hosts entries were left	Run the PowerShell cleanup above
A browser still warns about the certificate, or still goes to 127.0.0.1	The browser cached the old DNS or certificate state	Quit and reopen the browser
Connect comes back after uninstalling	The MDM assignment is still Required	Unassign it, or assign Uninstall, in the MDM
apt remove left ~/.agentwatch-connect	Personal settings are kept on purpose	sudo apt purge agentwatch-connect

Enrollment can also be revoked centrally from the fleet view, which stops attribution immediately without touching the device — useful when a laptop is lost before it can be wiped.

What does the fleet view show?

Enrolled devices with their platform, agent version, last contact, enrollment method, and whether interception and certificate trust are active — so a device that is enrolled but not actually inspecting is distinguishable from one that is. Version drift across the fleet is visible, and the agent can be updated centrally.

Sources and references

• What the captured activity looks like: Shadow AI discovery.
• Identity on the API path: Delegated identity and Auto Create Users.
• Provisioning the people these devices belong to: Single sign-on and directory sync.
• Policy applied to captured content: Data protection and guardrails.