§ DOCUMENTATION

Drift Signal

Behavioral drift detection that watches a running agent for unexpected tool usage, denial-rate shifts, and new data-class access — and automatically downgrades its autonomy when a high-severity signal fires.

§ 01

What behavioral drift is & why downgrade autonomy

An agent is granted an autonomy tier — autonomous, act_with_approval, supervised — based on an assessment of its behavior at onboarding. That assessment goes stale. Agents drift: new code paths get added, upstream tools expand their surface, or a model update changes what the agent chooses to call. When an agent's runtime behavior diverges from its established baseline, the original autonomy grant is no longer justified.

Drift Signal addresses this by continuously watching a running agent and comparing its live behavior against its baseline. When a significant deviation is detected, autonomy is automatically downgraded so that subsequent actions face stricter enforcement until a human reviews the signal. This is distinct from permission-drift detection, which compares granted permissions against a baseline — Drift Signal is behavioral and acts directly on the autonomy tier.

§ 02

The three trigger types

Drift Signal recognises three signal_type values. Each maps to a distinct behavioral dimension:

signal_type	What it detects
new_tool_usage	The agent calls a tool it has never invoked before — i.e., a tool absent from its historical baseline.
denial_rate_shift	The rate at which the agent’s requests are denied by policy shifts significantly upward from baseline — indicating it is attempting actions it previously did not attempt.
new_data_class	The agent begins accessing a class of data — for example PII or PHI — that it had not touched before. Detected from trace context and data-class annotations.

§ 03

Severity → action

Each detected signal carries a severity. Severity determines the action_taken field on the signal record and what Execlave does to the agent in real time:

Severity	Autonomy tier at detection	action_taken
low	any	none (signal recorded only)
medium	any	approval_required
high	autonomous or act_with_approval	autonomy_downgraded
high	supervised or lower	approval_required

A downgrade is reversible. After reviewing the signal, an admin can restore the agent's prior autonomy level from the dashboard or via the agents API. The signal record and the autonomy change are both preserved in the audit log.

§ 04

Reviewing drift signals

All signals for an agent are available at GET /api/v1/agents/:id/drift-signals. Each record includes the signalType, severity, actionTaken, detectedAt, and a detail object with signal-specific context (e.g. the tool name for a new_tool_usage signal). Signals are stored in agent_drift_signals and scoped by RLS to the requesting organisation.

curl https://api.execlave.com/api/v1/agents/agt_01j.../drift-signals \  -H "Authorization: Bearer $EXECLAVE_API_KEY" # Response{  "data": [    {      "id": "ds_01j...",      "agentId": "agt_01j...",      "signalType": "new_tool_usage",      "severity": "high",      "actionTaken": "autonomy_downgraded",      "detectedAt": "2026-06-02T11:30:00Z",      "detail": {        "tool": "delete_database"      }    }  ]}

§ 05

Enabling Drift Signal (FF_DRIFT_SIGNAL)

Drift Signal is controlled by the feature flag FF_DRIFT_SIGNAL, which is off by default. When the flag is off, no signals are evaluated, the GET /api/v1/agents/:id/drift-signals endpoint returns an empty data array, and autonomy is never auto-downgraded. Prior behavior is fully preserved.

To enable Drift Signal, set FF_DRIFT_SIGNAL=true in your backend environment and restart the worker process. The background worker will begin evaluating drift on its next scheduled run. Disabling the flag mid-run stops future evaluations immediately; existing signal records are retained in the database.

§ 06

Frequently asked questions

Does Drift Signal replace permission-drift detection?

No — they are complementary features. Drift Signal is behavioral: it watches what tools an agent calls, how often its requests are denied, and what data classes it touches, then acts on autonomy when a high-severity shift is detected. Permission-drift detection (documented at /docs/governance) is a separate baseline-vs-current comparison of the permissions an agent holds. Both can be active simultaneously.

What exactly happens to the agent when autonomy is downgraded?

The agent's autonomy tier is reduced one step — for example, from autonomous to act_with_approval, or from act_with_approval to supervised. The downgrade is recorded on the agent record and is visible on the dashboard. Subsequent actions are then subject to the stricter enforcement mode that corresponds to the new tier. The downgrade is reversible: an admin can manually restore the prior autonomy level after investigating the signal.

Can I tune which signal types or severities trigger an autonomy downgrade?

In the current release, the downgrade logic is fixed: a HIGH-severity signal on an agent at autonomous or act_with_approval triggers autonomy_downgraded. Lower-severity signals produce approval_required or are recorded with no action taken. Configurable severity thresholds are on the roadmap. For now, the feature flag FF_DRIFT_SIGNAL lets you enable or disable the feature globally.

How often does the background worker evaluate drift signals?

Signal evaluation runs on a scheduled interval in the background worker. The exact cadence depends on your deployment configuration. When FF_DRIFT_SIGNAL is off, the worker skips evaluation entirely — no signals are written and autonomy is never auto-downgraded, preserving prior behavior exactly.