Skip to main content

Detections

Concepts

AIControls surfaces two categories of security signals: session anomalies (behavioral thresholds exceeded by a running session) and baseline alerts (notifications generated by policy violations, budget crossings, and HITL events). Both appear in Security → Detections.

Session anomalies

Anomaly detection runs inline on every request — no background job, no batch window. Each check evaluates the current session's recent activity against the configured threshold. When a check fires:

  1. An anomaly event is recorded in the audit log with the triggering metric and observed value.
  2. A baseline alert is created and delivered to configured channels (Slack, email, in-app).
  3. If auto-pause is enabled and the cumulative anomaly count for the session exceeds the pause threshold, the session is paused and the developer receives a clear message with a contact-admin prompt.

Anomalies do not block requests by themselves — only auto-pause does. Run detection in observation mode and tune thresholds before committing to enforcement.

The Session Anomalies tab shows all detected anomaly events ordered by recency. Filter by identity, threshold type, and time range. Each entry links to the full session and shows the exact metric value that triggered the anomaly.

Anomaly events also feed into each identity's risk score — repeated anomalies from the same developer or agent raise their score on the Security Posture page.

Detection thresholds

AIControls evaluates every session against three independent behavioral thresholds — call rate, token spike, and repeated-prompt count. Each threshold targets a different failure mode:

  • Max calls per minute guards against runaway call volume — a session issuing far more MCP tool calls or LLM requests than normal in a short window.
  • Token spike threshold guards against unexpectedly large context payloads, such as a read_file on a multi-megabyte binary piped into a prompt.
  • Max repeated prompts guards against prompt-loop behavior — an agent stuck retrying the same request, or runaway retry logic.

The thresholds are independent: any one of them can fire an anomaly event without the others being crossed. Because default values are calibrated for interactive developer use rather than automated or multi-agent workloads, thresholds usually need tuning before enforcement (auto-pause) is turned on — see Configure Detection Thresholds for the concrete settings and steps.

Auto-pause

By default, anomalies create alerts but never block developers. With auto-pause enabled, a session is paused once its cumulative anomaly count crosses a configurable threshold — the count requirement guards against pausing on a single transient spike. For the concrete settings and steps, see Configure Detection Thresholds.

When a session is paused, the developer's next request returns a session_paused error with instructions to contact their admin. Admins can resume the session from Identity → Sessions or from the alert detail in Security → Detections.

warning

Enable auto-pause only after observing anomaly patterns in the feed for at least a week. Premature enablement with default thresholds can pause legitimate agentic workloads during normal operation.

Tuning for agentic workloads

Default thresholds are calibrated for interactive developer use, not for automated agents. Agentic workloads — particularly Claude Code running in multi-agent mode, bulk file indexing, or iterative code-generation loops — routinely produce call rates, context sizes, and retry patterns that would look anomalous for a human developer but are normal for the workload. Without adjustment, these patterns trip the default thresholds and generate noisy alerts or, if auto-pause is enabled, pause sessions that are behaving correctly.

The fix is to raise the relevant threshold(s) to match the workload's real behavior rather than to disable detection outright — see Configure Detection Thresholds for recommended adjustments per workload pattern.

Baseline alerts

The Baseline Alerts tab is the security alert inbox for your workspace. Alerts are generated by four sources:

SourceExample
Anomaly detectionA session exceeded the max calls-per-minute threshold
Policy violationsA deny-mode policy blocked a high-risk tool call
Budget crossingsA developer reached 90% of their monthly token budget
HITL eventsAn approval request timed out without a decision

Each alert shows the triggering identity, event type, severity, and a link to the relevant audit entry. Alerts are ordered by recency and the full history is always available regardless of delivery channel configuration.

note

The Baseline Alerts tab in Security → Detections always shows the complete alert history. Channel delivery is best-effort and does not affect what appears in the product.

See also