Runtime anomaly detection for RPA only works if the runtime emits the right per-step row.

The thing every page about this skips

Most writing on anomaly detection in supply chain operations is about the data, not the runtime. Benford's Law on invoice amounts. Isolation forests over supplier delivery times. LSTMs predicting demand. All of that is useful and none of it tells you whether the bot that just posted a purchase order to your ERP did something it has never done before. The model is at the wrong altitude. The question a security team actually needs to answer is: for this run, on this workflow, did any tool call touch a window or an element outside the set this workflow has ever touched in production.

The other category of writing is about runtime protection for credentials and screens (Stealth Mode, Input Lock, Time Limit on a UiPath robot). Those are real controls and they prevent a class of exfiltration. They do not detect anomalies. They prevent specific attacks under specific configurations.

The unspoken precondition for any anomaly detection program that targets the bot itself is a per-step audit shape with stable column names. Once that exists, the model layer is downstream and easy. Until it exists, the model layer is fitting noise.

What the runtime actually has to emit

Three artifacts, each emitted by the executor without any per-workflow configuration. The shape is fixed, the column names are public, the retention is in your control.

// crates/executor/src/models/execution.rs:75
pub struct StepResult {
    pub step_id: String,
    pub tool_name: String,
    pub status: StepStatus,        // Pending | Running | Success | Failed | Skipped | Retrying
    pub result: Option<Value>,
    pub error: Option<String>,
    pub duration_ms: Option<u64>,
    pub retry_count: Option<u32>,
}

-- supabase/migrations/20261115000000_create_user_step_pool.sql
CREATE TABLE user_step_pool (
    id UUID PRIMARY KEY,
    user_id TEXT NOT NULL,
    session_id TEXT NOT NULL,
    client_id TEXT,
    tool_name TEXT NOT NULL,
    arguments JSONB,
    result JSONB,
    error JSONB,
    duration_ms INTEGER,
    succeeded BOOLEAN,
    workflow_id INTEGER,
    workflow_name TEXT,
    step_id TEXT,
    step_name TEXT,
    app_name TEXT,
    window_title TEXT,
    element_path TEXT,
    created_at TIMESTAMPTZ,
    -- ... pool ordering, tags, retention columns
);

The anomaly classes that map to a WHERE clause

Six anomaly classes that come up over and over again in production supply chain RPA. Each one collapses to a query against the per-step row plus the trace, or a query that joins the row against a frozen baseline emitted on the day the workflow was promoted. None of these require an ML model to be useful as a continuous control. An ML layer on top is reasonable, but only after the schema underneath is fixed.

GROUP BY tool_name; HAVING COUNT(DISTINCT app_name) > baseline.app_count OR COUNT(DISTINCT window_title) > baseline.window_count

WHERE duration_ms > stats.median * 2 AND argument_hash = previous.argument_hash

WHERE element_path = $p AND status = 'failed' AND created_at > now() - interval '4 hours' GROUP BY trace_id

WHERE client_id = $bot AND app_name NOT IN (SELECT app_name FROM allowlist WHERE workflow_id = $w)

HAVING COUNT(DISTINCT (tool_name, app_name)) > workflow.frozen_tool_app_count

JOIN otel_spans USING (trace_id) WHERE http.host NOT IN (SELECT host FROM outbound_allowlist WHERE workflow_id = $w)

The trace, end to end

One execution, one trace_id, two persistence layers. The per-step rows live in Postgres for SQL anomaly queries. The full distributed trace lives in ClickHouse for cross-tool joins and outbound HTTP inspection. Both are reachable from the same trace_id.

The trace layer is where the outbound network anomaly class lives. A compromised activity pack that decides to POST clipboard contents to a publisher endpoint shows up as an HTTP span on the same trace_id as the workflow execution. The query is a JOIN on trace_id, with a WHERE on http.host. No regex over log files.

What other RPA runtimes emit instead

A short tour of the three platforms most enterprise RPA estates run on today, framed around the single question that matters here: is there a stable per-tool-call event schema that a security team can query for anomalies, or is per-step telemetry whatever the activity pack's developer chose to write into the log line.

None of these are wrong choices for an RPA platform. They are optimized for execution and visual debugging, not for a continuous security control on per-step behavior. The point of this page is that the gap is upstream of any ML model you might want to deploy.

The counterargument: can you ML over what you already have

The reasonable objection is that you can stream Orchestrator logs into Splunk, run an isolation forest on duration and success rate, and catch gross outliers without changing your runtime. That is true, and worth doing as a first cut. The limits are real.

First, the model has no canonical input for the most important features: which app the tool opened, which window it touched, which element it interacted with. Those exist as substrings of log lines, parseable per-pack but not uniformly. The model trains on whatever your team can extract, not on the underlying signal.

Second, the most interesting anomalies look successful. A marketplace component that adds an extra outbound HTTP call and still returns success under the duration threshold is invisible to duration-and-status models. The trace layer would catch this; the flat log layer cannot.

Third, the false-positive rate of an unsupervised model on free-form logs is high enough that security teams stop reading the alerts. The fix is not a better model; the fix is a tighter schema. Fix-the-schema, then ML on top, is a much shorter path than ML over noise.

What this actually buys an operations team

Three concrete uses, all of which our customers have run in production for at least one supply chain workflow.

Pre-deployment scope freeze. On the day a workflow is promoted, freeze the distinct set of (tool_name, app_name, window_title) triples it emits across its golden test suite. Every future run that emits a triple outside the frozen set pages a human. For an SAP B1 receipts workflow at a customer running on a Jack Henry plus SAP loop, this caught a vendor-driven Jack Henry UI patch inside 30 minutes of the patch rolling, hours before the AP team noticed wrong values landing in SAP.

Continuous duration baseline per tool. Rolling 30-day median plus 2-sigma band per tool_name, evaluated on every run. A medical claims intake workflow at a mid-market carrier surfaced a slow drift on the claims-portal-login tool one week before the upstream portal switched to a CAPTCHA flow; the duration trend was visible and the workflow was rerouted to a manual-fallback step before the portal cut the bot off entirely.

Outbound HTTP allowlist per workflow. Declare the set of hosts a workflow is allowed to reach. Any OTel span on the workflow's trace_id that targets a host outside the list fires a security alert. This is the runtime backstop for the supply chain risk of a marketplace component republishing with new outbound behavior; the install-time review is the front door, the trace-time allowlist is the lock.