> 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/administration/settings-center/compliance-and-security/tracking-anomaly-detection.md).

# Tracking Anomaly Detection

How We360.ai detects and handles tracking-bypass attempts — auto-clickers, mouse jigglers, "keep awake" scripts, and system-clock tampering — on the desktop agent, and how to configure anomaly rules.

Tracking Anomaly Detection lets the We360.ai desktop agent spot attempts to **fake presence or defeat activity tracking** — tools such as auto-clickers, mouse jigglers, "keep awake" / "keep presence" scripts, and system-clock tampering — and, optionally, shut the offending process down automatically.

It is available on both the **Standard** (visible) and **Stealth** (silent) desktop agents.

{% hint style="info" %}
This feature is configured in **Settings > Compliance & Security > Compliance**. Compliance settings require **Super Admin** access, apply organization-wide, and can take up to an hour to reach every device.
{% endhint %}

## Detection and handling flow

This flow separates the organization-level availability of anomaly detection from the portal's **Handle Tracking Anomalies** setting, which affects only a process that matches a configured rule.

```mermaid
flowchart TD
    tenantEnabled{"Anomaly detection enabled for the tenant?"}
    contactTeam["Contact your We360.ai account team"]
    detectionType{"What detects the anomaly?"}
    builtIn["Built-in mouse-jiggler or clock-drift detector"]
    processMatch["Configured process rule matches a tracked user's process"]
    handlingEnabled{"Handle Tracking Anomalies enabled?"}
    auditOnly["Record a security event; leave the matched process running"]
    terminateProcess["Record a security event and terminate the matched process"]
    recordEvent["Record a security event"]
    repeatedDetection{"Repeated detection of the same type?"}
    rateLimited["Rate-limit repeated event volume"]
    uploadEvent["Upload the event with normal activity data"]

    tenantEnabled -- No --> contactTeam
    tenantEnabled -- Yes --> detectionType
    detectionType --> builtIn
    detectionType --> processMatch
    builtIn --> recordEvent
    processMatch --> handlingEnabled
    handlingEnabled -- No --> auditOnly
    handlingEnabled -- Yes --> terminateProcess
    recordEvent --> repeatedDetection
    auditOnly --> repeatedDetection
    terminateProcess --> repeatedDetection
    repeatedDetection -- Yes --> rateLimited
    repeatedDetection -- No --> uploadEvent
    rateLimited --> uploadEvent
```

In summary, enabled tenant detection records security events from built-in detectors or configured process rules, handling can terminate only a matched process, and repeated detections are rate-limited to avoid event floods.

## What it detects

The agent runs three independent detectors that all feed one security-event stream:

| Detector                         | What triggers it                                                                                                                                                                                                     |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Process / command-line match** | A running process owned by the tracked user whose command line matches one of your configured **anomaly rules** (for example, a known presence-faking utility). This is the part you configure.                      |
| **Mouse jiggler**                | Continuous mouse movement confined to a very small area over a sustained window — the signature of a physical or software mouse jiggler used to appear active. This detector is built in and needs no configuration. |
| **Clock drift**                  | The device's system clock differing significantly from We360.ai's server time, which can indicate an attempt to manipulate tracked timestamps. Also built in.                                                        |

## How process matching works

Each **anomaly rule** is a named entry mapping a label to a list of match values:

```
KEEP_PRESENCE  →  [ keep-presence, python ]
```

* On a regular interval the agent inspects the list of processes **owned by the currently tracked user**.
* For each rule, a process is a match only when **every** value in the rule's list appears as a substring of that process's command line (case-insensitive). In the example above, a process matches `KEEP_PRESENCE` only if its command line contains **both** `keep-presence` **and** `python`.
* Requiring all values to match lets you target a specific tool precisely and avoid false positives on common process names.

`KEEP_PRESENCE → [keep-presence, python]` ships as the **default rule** so presence-faking scripts of that common form are caught out of the box.

## Detect vs. handle

There are two levels of response:

* **Detect** — the agent records the anomaly as a security event but leaves the process running.
* **Handle** — in addition to recording it, the agent **terminates the matched process**.

The **Handle Tracking Anomalies** switch in the portal controls this behavior. When it is on, the **Configure Anomalies** editor becomes available so you can define your rules; when it is off, the configuration is hidden.

{% hint style="warning" %}
With handling enabled, the agent force-terminates any process that matches a rule. Test new rules against a small group first, and keep match values specific, so you don't accidentally kill a legitimate application that happens to share a substring.
{% endhint %}

## Configuring anomaly rules

1. Go to **Settings > Compliance & Security > Compliance**.
2. Turn on **Handle Tracking Anomalies**.
3. Select **Configure Anomalies**.
4. Add or edit rules. For each rule, give it a **name** and one or more **match values** (all of which must be present in a process command line for it to match).
5. Save.

**Limits:** up to **20 anomaly rules**, each with up to **10 match values**.

Changes are distributed with the rest of your compliance settings and can take up to an hour to reach every device.

## What happens when an anomaly is detected

* The detection is recorded as a **security event** by the agent and uploaded with the agent's normal activity data.
* If handling is enabled, the matched process is terminated on the device.
* Repeated detections of the same type are **rate-limited** on the device so a single ongoing offender does not generate a flood of events.

{% hint style="info" %}
To be **notified** when anomalies are detected — rather than only having them acted on — contact your We360.ai account team to set up anomaly alerting for your organization. Anomaly alert recipients are configured by our team, not from the self-service Alerts screen.
{% endhint %}

## Enabling the feature

Tracking Anomaly Detection is governed by an organization-level switch managed by We360.ai. If the **Handle Tracking Anomalies** setting or the **Configure Anomalies** editor is not visible or has no effect for your organization, contact your We360.ai account team to have anomaly detection enabled for your tenant.

## Notes and limitations

* The **mouse-jiggler** and **clock-drift** detectors run whenever anomaly detection is enabled for your tenant, independent of the process rules you configure.
* Process matching only considers processes owned by the **tracked user's own account**, not other users or system/service accounts on the same machine.
* Detections are surfaced through alerting (see above); there is not currently a self-service in-portal list of individual anomaly events.

## Related

* [Compliance & Security](/administration/settings-center/compliance-and-security.md) — where this setting lives, alongside screenshots, screen recording, USB detection, and location restrictions.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.we360.ai/administration/settings-center/compliance-and-security/tracking-anomaly-detection.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.