feature
Aug 27, 2026Organization admins can review unusual proxy-operation volume and first-seen operations with linked session evidence.
Organization admins can now review two new anomaly types for enterprise gateway traffic: unusual daily request volume for an existing proxy operation and the appearance of a previously unseen operation. Each finding identifies the operation, explains why it matched, and links to the captured proxy sessions available for investigation.
The findings appear in the existing organization Signals page under Anomaly reports. Admins can filter them by detector, severity, status, and date, then acknowledge, resolve, or dismiss each result.
The proxy volume detector, AD-005, groups requests by their canonical operation title and compares the latest completed UTC day with that operation’s recent active-day history.
A finding requires all three conditions:
The baseline uses the operation’s previous 14 active days and requires at least seven active days before scoring. This prevents a single request from looking statistically extreme simply because an operation has little or no history.
The new-operation detector, AD-006, reports an operation title that appears in the latest completed day but was not present during the preceding 90 days. It requires at least ten labeled historical proxy sessions before it can fire, so a newly connected organization does not immediately receive novelty findings for its first gateway traffic.
Both detectors are organization-scoped. A title that appears across multiple users or teams is evaluated as one proxy operation for that organization.
Proxy requests already receive canonical operation titles based on their system or assistant prompt. Related prompt versions can be merged onto the same title when they represent the same product intent.
The anomaly detectors use that canonical title as the operation identity instead of treating every prompt hash as a separate operation. This distinction matters when a prompt is edited without changing what the integration does. A revised “Invoice Classifier” prompt remains part of the Invoice Classifier baseline rather than becoming a false new-operation alert.
Findings preserve a deterministic internal identity while showing the readable operation title to administrators. Evidence contains request counts, baseline statistics where applicable, and a bounded list of session IDs. It does not copy prompts, request bodies, credentials, or unrestricted captured content into the finding.
When a finding appears, an organization admin can:
A volume spike indicates unusual activity, not malicious behavior. A first-seen operation similarly means the operation is new to recent organization history, not that it violates a policy.
Detection runs over the previous completed UTC day. It does not evaluate a rolling local-time window and does not block requests in real time. Completed windows make results deterministic and allow the same window to be safely replayed without creating duplicate findings.
Proxy operation labels are produced asynchronously. If any eligible request in the evaluated history is still unlabeled, or if the bounded history query is incomplete, the detectors record insufficient data instead of producing a finding from partial counts. The window can be evaluated again after labeling catches up.
This conservative behavior can delay a result during a labeling backlog, but it avoids treating missing activity as zero or reporting a request as new when its historical operation has not yet been labeled.
Current thresholds are fixed backend defaults intended for initial calibration. Organization-specific thresholds, hourly detection, timezone-aware windows, and real-time alerting are not included yet.
If these detectors miss legitimate operation boundaries, merge unrelated prompts, or flag expected traffic patterns, we want that feedback. Those examples will determine whether canonical-title grouping and the initial thresholds need adjustment.