Signals Tab: Investigate Workflow Waste and Deterministic Anomalies

The Signals tab (/enterprise/orgs/{org_id}/signals) helps organization administrators find recurring AI-work patterns and investigate deterministic anomaly findings with the sessions behind them. Every org member can also open Configure Email Alerts & Cadence to manage personal alert preferences.

Date range

The page opens to the last 30 days. Set From and To dates or select Last 30 days to reset the range. The range applies slightly differently to each section:

• The Signals matrix includes signal periods written during the selected window.
• Anomaly reports include findings whose latest occurrence falls inside the selected window.
• The selected To day is included; the frontend sends the following day as the API’s exclusive upper bound.

Signals matrix

Signals group recurring patterns by team and project so you can see where enablement, policy, or durable project context will have the most leverage. Each populated cell shows:

• Projected tokens per week when the signal has an estimate.
• Open signal count when projected-token coverage is unavailable.
• A stronger color for a larger projected opportunity or open count within that matrix.
• Linked evidence sessions when the cell is clickable.

The page provides three views:

• P4 · Users with waiting sessions — sessions, qualifying wait events, maximum and total wait, the worst session, and a direct evidence-session link.
• Teams × patterns — concentration across a team, best used for shared conventions, policy, and enablement rather than individual performance review.
• Projects × patterns — concentration by codebase. Projects with the same configured display name are merged into one row.

For P4 project cells, the value is the number of affected sessions. Elapsed wait time is not converted into token savings.

How to investigate a Signal

1. Find concentration — start with the darkest or largest populated cells.
2. Choose the owner — team rows usually point to a policy or enablement owner; project rows point to a codebase owner; P4 user rows identify exact sessions to review.
3. Open evidence — inspect linked sessions before deciding whether the pattern needs a change.
4. Read the pattern details — select a code in What the pattern codes mean for examples, recommended admin actions, and interpretation guardrails.

Pattern catalog

Monthly CSV report

Select Export YYYY-MM CSV to download the current month’s organization-, team-, and project-scoped Signals. The report includes the period, scope, pattern, status, evidence count, idle minutes, measured opportunity tokens, and projected tokens. Member identities are not included.

Anomaly reports

Anomaly reports are nightly deterministic checks over completed session data. They are not AI-generated classifications. The header shows the number of open findings and the number currently marked high or critical. Filter the list by:

• Status: open, new, acknowledged, resolved, dismissed, or all.
• Severity: warning, high, critical, or all.
• Detector.
• The page-level date range.

Each finding shows its detector code, severity, status, subject, latest occurrence, occurrence count, evidence summary, and linked sessions when available.

Detectors

AD-001 — Usage baseline deviation

Daily session or token activity is materially above that member’s own rolling history. The detector compares each person with themselves over the previous 14 completed days using a guarded exponentially weighted baseline. A finding requires three conditions to align: a strong statistical deviation, a meaningful ratio above the member’s own baseline, and an absolute increase floor. Missing or inconsistent provider-reported coverage blocks the finding rather than producing a misleading result. Typical next steps: Confirm whether the increase matches planned work or an expected shift in role. Open the linked sessions to determine whether the volume is legitimate before deciding on any action.

AD-002 — New technology fingerprint

A session contains a first-seen combination of dependencies, imports, manifests, tools, or project activity relative to that member’s prior 90-day history. A single new extension or provider is not enough; the detector requires a meaningful combination, such as a new package ecosystem together with a first-seen dependency, or a new project root with a new command family. Typical next steps: Check whether the technology belongs to a legitimate new project or role change. First-seen activity is not evidence of a policy violation.

AD-003 — Runaway or looping session

A session shows repeated failures, identical retries, or activity far above the member’s normal session behavior. Deterministic sub-signals include: consecutive identical-input errors on the same tool, repeated failing operations on the same file, build or test failures without an intervening edit, abnormal tool-call volume, and abnormal duration. Severity escalates when two independent sub-signals fire together. Typical next steps: Open the evidence session and determine whether an agent configuration, failing command, or workflow needs intervention. The finding indicates operational waste or a stuck workflow, not malicious behavior.

AD-004 — Sensitive file access

Sessions where an AI agent read, wrote, or referenced .env, .env.*, *.env, .envrc, certificate, or private-key files. Detection covers three surfaces:

• Direct tool access — native Read and Write tool calls where primary_file_path or file_paths[] match a sensitive-file pattern.
• Shell command access — paths extracted from cat, head, tail, sed, and rg commands, covering the most common real-world leak path.
• Code and script mentions — text in agent-written files or tool outputs that references sensitive files: load_dotenv(".env.production"), open(".env", "r"), source .env && ..., or similar constructs. This surface catches the case where the model writes a temporary Python or Bash script that reads or modifies an env file — a vector that never passes through a tool-call hook boundary and is therefore outside the standard hook DLP guarantee.

Evidence records the access type (read, write, shell_read, code_mention) and whether hook DLP was active per tool call — never the actual file content or secret values. Severity tiers:

• Warning — one or more sessions with a sensitive file read or code_mention.
• High — at least one session wrote to a sensitive file path or the code mention involves a write operation.
• Critical — multiple sessions have env-file activity and at least one had no DLP coverage, indicating a gap where secrets or a script referencing them may have reached an external model provider.

Typical next steps: Check the access type in evidence. For code_mention, open the linked session and determine whether the script was executed and whether that execution had DLP coverage. For direct or shell reads with was_redacted: false, determine whether secrets were transmitted to an external provider.

AD-005 — Proxy operation volume spike

A canonical proxy operation’s daily session volume is materially above the organization’s own recent daily history for that operation. The detector requires sufficient active-day history before it can fire, and compares the operation with its own baseline rather than with a global threshold. Evidence contains the operation title, bounded statistics, and a limited number of session identifiers — not request bodies, prompts, or provider credentials. Typical next steps: Confirm whether the operation’s increase is expected, then inspect the linked sessions for unexpected callers or inputs.

AD-006 — New proxy operation

A canonical proxy operation title appears for the first time in the organization’s recent history, compared against the preceding 90 days of labeled activity. A sufficient baseline of prior labeled sessions is required before a title is treated as genuinely new. Typical next steps: Verify that the new operation belongs to an approved integration or workflow. First-seen title novelty is an invitation to verify, not evidence of a policy violation.

AD-010…AD-013 — Coverage and tamper

These detectors report when ReclaimLLM protection is missing, turned off, or bypassed. AD-010, AD-011, and AD-013b appear on the next device check-in. AD-012, AD-013a, and AD-013c wait for the nightly anomaly job, so a same-day test stays empty until that run. Filter Anomaly reports by the detector code. The row title is the meaning (Hooks tampered or missing, DLP disabled, and so on). The code AD-010 is the stable id above that title. Coverage lists open AD-010, AD-011, AD-012, and AD-013b on the device row. AD-013a is a member finding and AD-013c is an org finding, so they show here and not on that device cell. Calculation detail is in Anomalies and Coverage Alerts.

AD-010 — Hooks tampered or missing

Fires when a client that was already installed later checks in as missing, partial, disabled, or modified, when the client sends an uninstall, or when the policy signature is invalid. The first check-in for a client is a baseline and does not fire. An rclm version change holds installed → missing or partial for 30 minutes. Severity is high when that user has hook sessions in the last 14 days, otherwise warning. The Signals title is Hooks missing: Cursor (client and new status), or Hooks tampered or missing when the client is not named.

AD-011 — DLP disabled

Fires on a check-in where DLP is off and there is no active DLP exception. Warning when Require DLP is off. High when Require DLP is on. Turning DLP back on resolves the disabled finding. Sending --no-dlp while Require DLP is on creates a separate warning titled DLP opt-out attempted, even when the effective DLP flag stays on.

AD-012 — Device silent

Nightly. The device must be a normal machine (not ephemeral, not retired), with check-ins or hook sessions on at least 3 weekdays in the last 10 business days, then quiet past the silence setting (default 2 business days). After the nightly job, the title is Device silent or Device silent (corroborated). Corroborated means that user still has gateway proxy traffic, or another of their devices checked in, during the quiet period. A laptop that is simply off, with no other activity, is the uncorroborated variant.

AD-013a — Gateway without hooks

Nightly. The org needs at least one proxy session that day. One user needs at least 3 proxy sessions and zero hook sessions (record_type = session) in the same day. The finding is on the member, so it appears in Anomaly reports and not in the Coverage device column. One hook session for that user in the same day keeps it quiet.

AD-013b — Direct provider routing

Fires on the next check-in when routing for a gateway required provider is direct. unknown does not fire. With no required providers configured, this detector does not fire. The Signals title is Direct routing: plus the provider name.

AD-013c — Provider usage unreconciled

Stays off until the org is Enterprise, Enable provider usage reconciliation is on, and a gateway key exists. The nightly job compares the previous day’s provider usage with gateway tokens. It fires high when provider usage is on a key that is not a gateway key, or when provider tokens are more than 1.1 times the gateway tokens for that key. A day with no provider usage row does not fire.

AD-015 — External network egress

Fires when a session initiates an outbound network connection to a non-local destination across any model or coding client. The detector inspects four surfaces:

• Shell HTTP (curl, wget, http/https, xh, aria2c, Invoke-WebRequest / Invoke-RestMethod)
• Shell transfer & sockets (scp, sftp, rsync, nc / ncat / netcat, socat, telnet, ftp, /dev/tcp/<host>/<port>)
• Programmatic script egress (python -c, node -e, ruby -e, perl -e, php -r, or agent-written files combining requests, urllib, httpx, aiohttp, socket, paramiko, fetch, axios, or http.request with an external URL or IP)
• Native web fetch (WebFetch, web_fetch, fetch_url, http_request)

Localhost and loopback addresses (localhost, 127.0.0.0/8, ::1, 0.0.0.0, host.docker.internal) are automatically ignored. Read-only native WebFetch calls fire as Warning; shell/script/transfer egress or raw IP literals fire as High; and outbound uploads (POST/PUT/PATCH/--data*/-F/-T/remote scp), cloud metadata SSRF probes (169.254.169.254), curl | sh execution chains, or egress in the same session as sensitive file access (.env, .ssh, keys) or /etc/resolv.conf recon fire as Critical. Safe-listing trusted destinations: Admins can configure Allowed Egress URLs, Domains & IPs (AD-015 Safe List) in Configure Email Alerts & Cadence → Organization (accepting URLs, domains/subdomains, IPv4/IPv6 addresses, and CIDR ranges), or click Mark destination safe directly on an AD-015 finding card to allowlist its destination hosts/IPs and dismiss the finding. Cloud metadata SSRF endpoints can never be allowlisted. Typical next steps: Review the sanitized destination_hosts, destination_ips, egress_methods, and model badges on the finding card, inspect the linked session, and either mark trusted corporate destinations safe or escalate unexpected external transfers.

AD-016 — PII content exposure

Fires when a session’s content — a gateway proxy request/response body or a hook/agent tool-call input/result — contains a validated email address, phone number, SSN, or credit card number. Matching is deterministic (regex plus a Luhn checksum for cards and SSA range rules for SSNs), not a model call. Severity differs by where the match was found: proxy traffic starts at High (the data already reached the model provider) and escalates to Critical on repeat sessions for the same member; hook/agent sessions start at Warning, rise to High with multiple categories or sessions, and only reach Critical when the same session also has an AD-015 external egress finding. Typical next steps: Check whether the match is a proxy or hook/agent finding, and check chained_with_egress for hook/agent findings — a chained finding means the data was both touched and sent externally in one session. Open the linked session; matching tool calls and messages are automatically expanded and highlighted. See Anomalies → AD-016 for the full calculation and evidence detail.

AD-017 — Proxy failure rate

Fires when the share of failing gateway calls (error responses plus streams that broke after starting) is well above the organization’s own recent rate. It is scored for the whole organization, for calls not yet labeled with an operation, and for each operation, every hour and every day. Hourly findings need two abnormal hours in a row. The organization-wide finding is High at a 50% failure rate or 5× the usual rate, and sends an immediate P0 email; everything else is a Warning in the digest. Typical next steps: Check whether the rise is organization-wide (often a provider outage, expired credential, or exhausted credits) or limited to one operation, then open the linked failing sessions and compare status codes.

AD-018 — Proxy latency regression

Fires once a day when a model’s p95 and median latency on successful, non-streaming gateway calls are both well above that model’s own recent baseline. A single slow call cannot fire it, because the median must rise too. Typical next steps: Open the linked slowest sessions and compare input and output size with earlier days; if the work is unchanged, check provider status or a region or deployment change. See Anomalies → AD-017 and AD-018 for the full calculation, evidence, and the thresholds you can tune.

Finding status workflow

• Acknowledge a new finding when it is under review.
• Resolve it when the relevant work or remediation is complete.
• Dismiss it when the finding is expected behavior or a false positive.
• Mark destination safe (on AD-015 findings with external hosts/IPs) adds the finding’s destination_hosts and destination_ips to the organization’s AD-015 safe list and dismisses the finding.
• Accept risk (when Compliance is enabled) creates a time-boxed accepted_finding exception with a rationale and expiry (≤12 months), then dismisses the finding. Exceptions appear under Compliance → Exceptions.
• Resolved and dismissed findings are closed and cannot transition to another status.

Email alerts & notification cadence

RCLM sends tiered email for workflow signals and deterministic anomalies: immediate P0 security notices, a daily digest, and a Monday weekly executive summary. Digests fire at 08:00 in the recipient’s local timezone (personal preference → organization timezone → America/Toronto). Click Configure Email Alerts & Cadence in the Signals header. The modal has two tabs:

• Organization — admin-only routing and cadence policy (also available under Organization Settings → Email Alerts & Cadence)
• My alerts — personal preferences for every org member

Deep links in emails open /enterprise/orgs/{org_id}/signals?alerts=1 so the modal opens directly.

Delivery cadences

Organization configuration (admins)

• Security inbox — always receives AD-004 Critical and AD-015 Critical (unless all destinations on the AD-015 finding are covered by the org’s allowed egress safe list), even when security cadence is Off or the project is excluded.
• Recipient inboxes — comma-separated addresses for org-wide alerts. If blank, notifications default to organization administrators.
• Organization timezone — fallback when a member has not set a personal timezone.
• Minimum severity — All, High & Critical only, or Critical only. Findings below the threshold stay on the dashboard but are omitted from email.
• Included anomaly detectors — toggle AD-001 through AD-006 and AD-015 through AD-018 (coverage keys such as AD-010…AD-013 appear when that product surface is enabled).
• Included workflow signals — toggle P1 through P10 for digests.
• Excluded projects / sandboxes — case-insensitive project-name filters. Names are used only for filtering; they are never rendered in email bodies.
• Allowed Egress URLs, Domains & IPs (AD-015 Safe List) — comma- or newline-separated URLs, domains (matching the domain and its subdomains), wildcards (*.internal.corp), IP addresses, or CIDR ranges (10.0.0.0/8). Egress targets matching this list are excluded from AD-015 findings and alerts. Cloud metadata SSRF endpoints (169.254.169.254, metadata.google.internal) cannot be allowlisted.
• Proxy Thresholds (AD-017/018) — a separate button in the Signals header, next to Egress Policy (AD-015). Adjust the minimum calls, failure and latency rise multiples, and the history needed before a model or window is scored. Blank fields use the defaults; see Anomalies → Tuning AD-017 and AD-018.
• Recent deliveries — last 50 delivery attempts with masked recipient addresses, tier, detector, severity, and status.

My alerts (every member)

• Enable or stop email alerts for yourself
• Set your own severity floor and toggles for immediate / daily / weekly
• Disable individual detectors or signal patterns
• Exclude projects and choose a personal timezone
• Developers and team leads receive alerts only about their own sessions; admins and explicit org recipients see org-wide findings

Zero-exfiltration payload

Alert email travels over ordinary mailboxes, so the body is deliberately thin. Emails may include: detector key and fixed title, severity, session counts, categorical file-pattern labels (for example .env, *.pem), surface labels (Direct Tool Read, Shell Read, Script Mention, Shell HTTP Egress, Shell File Transfer / Socket, Script Network Egress, Native WebFetch), PII category labels (email, phone, ssn, credit_card), DLP gap counts, and authenticated deep links. Emails never include: session titles, project names, file paths, destination URLs/hosts, shell commands, prompts, secrets, or free-text evidence fields.

Testing email delivery

Who sees it

• Organization matrix, anomaly findings, status actions, and CSV export — administrators only. The backend enforces the same boundary.
• Configure Email Alerts & Cadence / My alerts — every org member. Non-admins see personal preferences; they do not see the org matrix or finding actions.

For the surrounding operating model, see Enterprise Observability and the Anomalies detector reference. Use Sessions to continue a broader investigation and Tokens for organization-wide consumption and measured context reduction.