> For the complete documentation index, see [llms.txt](https://docs.we360.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.we360.ai/how-to-and-best-practices/visibility-accountability-and-evidence/stealth-user-management.md).
# How Do I Configure User Management for the Stealth Application
The stealth application works differently from the standard app: employees never sign in. Instead, the agent registers each person automatically the first time it runs on their machine, using identity rules you configure in the portal. Getting these rules right **before** you deploy is the single most important step — changing them later can create duplicate users.
{% hint style="warning" %}
Stealth deployment is restricted to **organization owners**. Before deploying, confirm that silent monitoring is legally permitted in your jurisdiction and that you have authorization to install the software on the target machines.
{% endhint %}
## How stealth users are created
When the stealth app starts on a machine for the first time, it:
1. Identifies the signed-in operating-system account (the OS username), the machine name, and a unique machine identifier.
2. Contacts your space.vars.company\_name account and checks whether a matching user already exists.
3. If not, it **creates a new user automatically** — no invite, no email verification, no password entry on the device.
Each stealth user gets a system-generated email ID in the form:
```
@.we360.local
```
The `` part is controlled by your **Email Prefix Base** setting (see below). By default it is an anonymized code derived from the OS username and the machine, the user's **first name** is taken from the OS account name, and the **last name** is the machine's hostname — so a brand-new rollout typically shows users like *"john DESKTOP-7G2K1"*.
Key consequences of this model:
* **One stealth user is created per OS account, per machine** (with the default settings). A shared PC with three Windows profiles produces three users; one person using two laptops produces two users.
* New users are placed in your **default team** unless your account is configured otherwise, and are counted against your **licensed seats**. Once your active user count exceeds your licensed seats by roughly 10%, new stealth users stop being created until seats are freed or added.
* The same license pool covers standard and stealth deployments — there is no separate stealth license.
## Step 1 — Configure identity rules before deploying
Navigate to **Settings → Compliance & Security → Stealth App Config**. Only the organization owner can see this section.
{% hint style="info" %}
The portal shows this disclaimer for a reason: *"Any changes here may impact existing devices and may lead to new user creation due to updated settings (takes up to 1 hour to reflect)."* Settings are picked up by agents within about an hour.
{% endhint %}
{% stepper %}
{% step %}
### Choose how identities are built — Email Prefix Base
This dropdown decides what the `` in the generated email is based on. Choose once, before rollout:
* **MACHINE ID** *(default for new accounts)* — an anonymized code derived from the OS username and the machine's internal ID. Stable across hostname renames. A user is unique per person, per machine.
* **OS USERNAME** — uses the actual OS username (e.g. `john.smith`). Human-readable and lets the same person keep one identity across machines **if** usernames are consistent across your fleet. Caution: two different people using the same OS username on different machines will be merged into **one** user.
* **MACHINE HOSTNAME** — uses the machine name. Device-centric: everyone who logs in to the same machine reports into the same user. Suitable only for one-person-per-device environments.
* **MAC ADDRESS** — an anonymized code derived from the OS username and the network adapter. Survives hostname renames, but changes if the primary network adapter changes (e.g. docking stations or adapter replacement).
* **LEGACY** — an anonymized code derived from the OS username, hostname, and machine ID. Renaming a machine creates a new user. Kept for older deployments; not recommended for new rollouts.
{% hint style="danger" %}
Changing the **Email Prefix Base**, **Email Final Prefix**, or **Email Full Suffix** after deployment changes how identities are calculated. Devices will then register **new** user accounts under the new rules, and the old accounts must be deactivated (manually, via link suggestions where shown, or by **Auto manage users**). Plan these values up front.
{% endhint %}
{% endstep %}
{% step %}
### Optionally customize the generated email
* **Email Final Prefix** — a fixed text added to the front of every generated identifier. Letters, numbers, dots, and dashes only.
* **Email Full Suffix** — replaces the default `@.we360.local` ending. A custom suffix must start with `@`, include your organization ID token (the portal inserts it for you), and end with `.local`. If you have special requirements, contact support.
Most organizations can leave both at their defaults.
{% endstep %}
{% step %}
### Decide which OS accounts should NOT become users
* **Skip user creation for these usernames** — click **Update usernames** and list OS accounts that should never be tracked: service accounts, IT/admin profiles, kiosk logins, shared maintenance accounts. **Usernames are case-sensitive.**
* **Skip system root user** — when enabled (recommended), no user is created when the agent runs under the system root account. This applies to macOS and Linux; on Windows, use the username skip list instead.
{% endstep %}
{% step %}
### Set the user-detail conventions
* **Use hostname as last name** — when enabled (default), the machine name becomes the user's last name, which makes machines easy to spot in user lists. Disable it if you plan to maintain real names manually.
* **Use email prefix as employee id** — when enabled, the generated identifier is also stored as the user's Employee ID, useful for matching exports against your asset or HR inventory.
{% endstep %}
{% step %}
### Choose the onboarding posture for new users
* **Mark new stealth users as non-tracking** — when enabled, newly created stealth users do **not** start tracking until you approve them: go to **Settings → User Management**, modify the user, and unmark non-tracking. Use this if you want an explicit review step before data collection starts.
* **Auto manage users** — when enabled, the system deactivates and reactivates stealth users automatically based on the data and activity received. Recommended for large fleets where machines are frequently reimaged or retired; leave it off if you want full manual control over who is active.
{% endstep %}
{% endstepper %}
## Step 2 — Deploy the stealth app
Go to the **Download** page in the portal and open the **Stealth Apps** tab (visible to organization owners only). Before the download unlocks, you must acknowledge three statements:
* *"I understand this app runs silently."*
* *"I have authorization to install this software."*
* *"I accept responsibility for its use."*
{% hint style="danger" %}
Stealth installers are **confidential and specific to your organization** — the file embeds your organization's enrollment key. Never share an installer outside your organization, and always download a fresh copy (or a fresh link) from the portal. Shareable download links are valid for 7 days.
{% endhint %}
Installation itself requires administrator privileges on every platform. For step-by-step install walkthroughs, mass deployment (GPO, Intune, MDM), and network allowlisting, see the **Agent Deployment Hub** in the IT Ops documentation at [docs.we360.ai](https://docs.we360.ai/deployment-and-it-ops/agent-deployment-hub/download-links).
## Step 3 — What happens after installation
Within a few minutes of the first run (allow up to an hour for a fresh configuration), the new user appears in **Settings → User Management** with their system-generated email. From there, treat them like any other user:
* **Rename them.** Generated names like *"john DESKTOP-7G2K1"* are functional but unfriendly. Edit the first/last name and Employee ID so reports read well — your edits persist; the agent does not overwrite manual renames during normal operation.
* **Organize them.** Assign each user to the right team and shift. Productivity mapping, screenshots, and reporting policies then apply through normal team settings.
* **Verify the count.** If you installed on 50 machines, you should see roughly 50 new users (minus skipped usernames). A shortfall usually means a skip rule matched, the seat limit was reached, or a machine hasn't come online yet.
{% hint style="info" %}
Searching for stealth users by email is impractical since the address is system-generated. Search by the name you assigned, or filter by team — and use **Use hostname as last name** so the device name is always searchable.
{% endhint %}
## Ongoing user management
* **Deactivating a stealth user** stops tracking on that machine: the agent detects the deactivation and shuts itself down. If you later reactivate the user, the agent picks tracking back up the next time it checks in (it rechecks periodically, so allow up to \~30 minutes).
* **Transfer data** — from the user's action menu in **User Management**, move a stealth identity's recorded data to another user. Use this after a duplicate was created (e.g. hostname change) or when consolidating a person's multiple machine identities.
* **Uninstall agent** — available in the action menu for **deactivated** stealth users; remotely removes the agent from that user's machine.
* **Auto-delete Deactivated Stealth Users** *(Settings → Compliance & Security → Compliance, currently in alpha)* — when enabled, stealth identities that were manually deactivated by an admin are permanently deleted 7 days after deactivation, with a backup record stored first. Raw activity data already collected is not affected.
## OS-specific caveats
{% tabs %}
{% tab title="Windows" %}
* **Administrator privileges are required** for stealth installation.
* **Every Windows profile gets its own user.** On shared or multi-user machines, the agent creates a separate stealth user for each profile that signs in — including local admin or IT accounts. Add those accounts to **Skip user creation for these usernames** before deploying to shared machines.
* **Skip system root user has no effect on Windows.** Use the username skip list to exclude administrative accounts.
* **Prefer the EXE installer.** An MSI is available for tools that require it, but MSI deployments do not reliably auto-update — plan to push MSI updates through your own deployment tooling. An **unbranded EXE** is also available; it installs the same payload without product branding in the installer surface.
* Domain environments: the identity is based on the Windows profile username, so keep usernames consistent if you use the **OS USERNAME** prefix base.
{% endtab %}
{% tab title="macOS" %}
* The stealth app ships as a **PKG** installer and requires an administrator account to install.
* **Permissions matter.** Capture features need the system permissions granted under **Privacy & Security** (Accessibility and Screen Recording). If permissions are missing, the user is still created but screenshots and some activity data will be incomplete. For unattended rollouts, pre-grant these permissions through your MDM profile — see the macOS MDM deployment guide in the IT Ops documentation.
* **Skip system root user** works on macOS and prevents user creation for processes running as root.
* Renaming a Mac (its hostname) can create a new user under the **LEGACY** prefix base — prefer **MACHINE ID** for Mac fleets where machine names change.
{% endtab %}
{% tab title="Linux" %}
* Linux is supported in **stealth mode only**, installed via a script from the Download page; run it with root privileges.
* **Skip system root user** applies — with it enabled (default), running the agent as root does not create a user, so tracking covers the regular desktop accounts.
* As on Windows, each Linux account on a shared machine becomes its own stealth user unless excluded via the username skip list.
{% endtab %}
{% endtabs %}
## Troubleshooting quick reference
A user is not appearing in the portal after installation
Check, in order:
1. **Skip rules** — is the OS username on the skip list (remember: case-sensitive), or is it the root user with **Skip system root user** enabled?
2. **Seat limit** — has your active user count reached your licensed seats? New stealth users are not created past the limit.
3. **Installer freshness** — was the installer downloaded recently from your own portal? Old or shared installer files may carry an invalid key. Always re-download from the portal.
4. **Time and connectivity** — allow up to an hour after a configuration change, restart the machine once, and verify the machine can reach the space.vars.company\_name servers (see the network allowlist guide in the IT Ops documentation).
Duplicate users appeared for the same person
Duplicates happen when the identity input changed: a renamed machine (LEGACY base), a renamed OS account, a changed network adapter (MAC ADDRESS base), or a change to the stealth identity settings themselves. Fix it by deactivating the obsolete user and using **Transfer data** to move its history to the surviving identity. Enabling **Auto manage users** keeps inactive duplicates cleaned up automatically.
A user shows absent even though the machine is in use
If the user was previously **deactivated**, the agent on that machine stopped itself and only rechecks periodically — reactivate the user and allow up to \~30 minutes. Also confirm the machine's OS account isn't on the skip list and that, on macOS, the required system permissions are granted.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.we360.ai/how-to-and-best-practices/visibility-accountability-and-evidence/stealth-user-management.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.