How Do I Configure User Management for the Stealth Application

Configure user management for the We360.ai stealth application — automatic user creation, identity rules, deployment, renaming, deactivation, and OS-specific caveats.

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.

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.

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 We360.ai 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:

<identifier>@<your-organization-id>.we360.local

The <identifier> 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.

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.

1

Choose how identities are built — Email Prefix Base

This dropdown decides what the <identifier> 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.

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.

2

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 @<your-organization-id>.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.

3

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.

4

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.

5

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.

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."

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.

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.

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.

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.

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

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.

macOS

Linux

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 We360.ai 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.