Intent Anomaly Detection identifies automated and abusive behavior by analyzing the sequence of API calls associated with a protected endpoint. Unlike volumetric detection, which evaluates request volume, Intent Anomaly Detection evaluates the relationships between API calls within a session.
The detection identifies sessions that:
Omit APIs that commonly occur as part of a legitimate user journey.
Follow sequences that differ significantly from established legitimate behavior.
Form behavioral patterns that are uncommon in historical traffic.
Remain below traditional volumetric detection thresholds.
Intent Anomaly Detection is part of Bot & Abuse Protection and complements Distributed Attack Detection, Credential Stuffing Detection, and Landspeed Violation.
What will you learn from this topic
By the end of this topic, you will be able to:
Understand how Intent Anomaly Detection identifies abnormal API sequences and session behavior.
Understand how Traceable establishes behavioral baselines for protected endpoints.
Understand how Traceable correlates API requests into sessions using multiple signals.
Understand the three detection layers and how each layer identifies different types of anomalous behavior.
Review and investigate Intent Anomaly Detection findings across Bot & Abuse Protection views.
Understand how detection parameters are tuned and how monitored and blocking modes work.
Before you begin
Before using Intent Anomaly Detection, make a note of the following:
Make sure Bot & Abuse Protection is enabled for your account.
Make sure you have access to the Bot Protection Dashboard, Bot Actors, Bot Accounts, Bot Activities, and Bot Events pages.
Note
Traceable establishes and tunes the detection based on application traffic.
Detection workflow
Intent Anomaly Detection uses a three-stage workflow:
Establish the baseline → Correlate requests into sessions → Detect anomalous behavior
Applications can have multiple legitimate user journeys for the same endpoint. These journeys may vary by client type, geography, account state, or other traffic characteristics.
To account for these variations, Traceable establishes segmented baselines and evaluates sessions against the appropriate historical behavior.
1. Establish the baseline
For each protected endpoint, Traceable analyzes historical traffic to identify APIs that commonly occur before and after the endpoint.
Protected endpoints can include APIs associated with registration, login, payment, or sensitive data access.
For example, a lending workflow may typically follow:
Load profile → Check eligibility → Upload documents → Apply
Traceable uses these API relationships to establish the baseline for /apply.
The default lookback period is seven days. The correlation window, which determines the period in which Traceable evaluates APIs before and after the protected endpoint, is typically ±10 minutes.
Baseline segmentation
A single baseline may not accurately represent all legitimate traffic.
For example, mobile and desktop clients may use different API sequences. Traffic may also vary by geography or other application characteristics.
Traceable can establish separate baselines for relevant traffic segments, allowing legitimate differences between these groups to be accounted for during anomaly detection.
2. Correlate requests into sessions
Traceable correlates API requests to determine which requests belong to the same session.
Correlation uses multiple signals in parallel:
Correlation signal | Description |
|---|---|
IP address + User-Agent | Connects requests using the source IP and User-Agent combination, including cases where cookies or tokens change during a session. |
Request headers or cookies | Uses values such as visitor IDs or authentication tokens to connect requests when the source IP changes. |
Derived entities | Uses values extracted from request bodies or query parameters, such as account numbers or email addresses, to connect related activity. |
Using multiple correlation signals reduces dependence on any single identifier. IP addresses may be shared across legitimate users, cookies may be cleared, and tokens may be rotated. When one signal changes or is unavailable, other signals can provide session context.
Detection layers
After establishing the baseline and correlating requests into sessions, Traceable evaluates session behavior through three detection layers. Each layer identifies a different type of deviation, progressing from a completely missing user journey to broader behavioral differences across groups of sessions.
Layer 1: Missing every correlated API
Layer 1 identifies sessions that call the protected endpoint but do not call any APIs typically associated with it.
For example, a legitimate lending workflow may follow:
Load profile → Check eligibility → Upload documents → Apply.
An anomalous session may call only:
Apply — This pattern indicates direct access to a sensitive endpoint without the API activity normally associated with a legitimate user journey.
Layer 2: Missing specific correlated APIs
Layer 2 identifies sessions that follow part of an expected workflow but consistently omit one or more specific APIs.
For example, a legitimate registration workflow may follow:
Create account → Verify email → Set up profile
An anomalous session may follow:
Create account → Set up profile
Traceable evaluates whether the missing API is a meaningful part of the expected journey based on two thresholds:
Minimum historical occurrence rate: The minimum frequency at which an API must occur in historical sessions for Traceable to consider it part of the expected user journey.
Minimum affected sessions: The minimum number of sessions that must exhibit the same missing API before Traceable treats the behavior as a pattern.
Layer 2 is particularly useful for identifying automation that reproduces most of a legitimate workflow while bypassing a verification, validation, or other control step.
Layer 3: Behavioral clustering
Layer 3 evaluates the overall behavior of sessions rather than looking for a specific missing API.
Traceable represents each session as a behavioral fingerprint using signals such as:
API call durations.
APIs present in the sequence.
The number of uncommon APIs in the sequence.
Sessions with similar behavioral fingerprints are grouped into clusters. Traceable compares these clusters with historical traffic to identify groups that exhibit significantly different behavior or grow unusually quickly.
Layer 3 can identify anomalous behavior even when no single API is consistently missing. This includes sophisticated automation and low-and-slow activity that remains below traditional volumetric detection thresholds.
Detection layer comparison
The following table summarizes how each detection layer identifies anomalous session behavior.
Layer | Detection focus | Example |
|---|---|---|
Layer 1 | The entire expected API journey is missing. |
|
Layer 2 | One or more expected APIs are consistently missing. | Account creation occurs without email verification. |
Layer 3 | Overall session behavior differs from historical traffic. | A group of sessions follows an unusual sequence and forms a new behavioral cluster. |
Sample Scenarios
Example — Automated lending applications
Consider a lending platform where legitimate users typically follow:
Load profile → Check eligibility → Upload documents → Apply
An automated client begins calling /apply directly and distributes the activity across several days to remain below volumetric thresholds. The individual requests may appear valid. The sequence differs from the established journey. Layer 2 can identify the missing eligibility and document-upload APIs when they fall below their expected occurrence rate across affected sessions. Layer 3 can independently identify the sessions as a behavioral cluster when their sequence fingerprints differ from historical applicant traffic. The combination provides coverage even when the request volume does not exceed a traditional volumetric threshold.
Example 2 — Partial account registration abuse
Consider a registration workflow:
Create account → Verify email → Set up profile
An automated campaign follows:
Create account → Set up profile
The activity is distributed over time and does not produce a significant spike in request volume. Because email verification typically occurs as part of the legitimate journey, the repeated absence of the verification API serves as a sequence-based signal. Layer 2 can identify the pattern once enough sessions exhibit the same missing step.
Investigate findings
Intent Anomaly Detection runs continuously after an endpoint has been onboarded. No separate detection rule or day-to-day configuration is required.
Findings are available through the existing Bot & Abuse Protection views.
Page | What you can review |
|---|---|
Bot Protection Dashboard | View Intent Anomaly Detection in the threat-type breakdown, monitor trends over time, and compare monitored and blocked traffic. |
Bot Actors | Investigate sources associated with flagged sessions, including targeted APIs, severity, and affected accounts. |
Bot Accounts | Review accounts associated with flagged sessions and the actors and events connected to those accounts. |
Bot Activities | Review detected patterns as incidents, including the affected endpoint, activity duration, and AI-generated summary of the detection. |
Bot Events | Investigate individual flagged sessions, including the associated Policy Group and Rule Name. Open the Request Viewer to inspect request headers, body, and cookies. |
These views provide visibility from the detected pattern through to the individual API requests associated with the finding.
Detection tuning
Intent Anomaly Detection is tuned to the traffic characteristics of each protected environment. The following parameters are configured during endpoint onboarding and are not exposed as customer-facing settings.
Parameter | Description | Typical default |
|---|---|---|
Protected endpoint | The API around which Traceable builds the user-journey baseline. | Registration, login, or payment |
Correlation window | Time window for capturing APIs before and after the protected endpoint. | ±10 minutes |
Lookback window | Historical traffic used to establish the baseline. | 7 days |
Minimum historical occurrence rate | Occurrence rate above which a correlated API is considered part of the expected user journey. | 50% |
Minimum affected sessions | Number of sessions showing the same missing API before it is treated as a pattern. | 10 |
Client type exclusions | Client types are excluded from the detection. | None |
Header, cookie, or derived entity keys | Request values used for session correlation in addition to IP + User-Agent. | Tenant default |
Monitored and blocking modes
When a new endpoint is onboarded, Traceable establishes and validates the detection against normal application traffic. The detection can first be evaluated in monitored mode to validate the baseline and detection behavior. Once the behavior has been validated, the endpoint can move to blocking.
Note
For information about endpoint onboarding or detection tuning, contact Traceable Support.
Intent anomaly detection within Bot & Abuse Protection
Intent Anomaly Detection complements other Bot & Abuse Protection detections by focusing on API sequences and session behavior. The following table highlights how it differs from other detection types:
Detection | Primary signal |
|---|---|
Intent Anomaly Detection | API sequences and session behavior |
Distributed Attack Detection | Coordinated activity distributed across sources |
Credential Stuffing Detection | Automated credential-based account compromise attempts |
Landspeed Violation | Suspicious geographic movement between requests |
When you detect a new endpoint, Traceable helps establish and tune the detection against your normal traffic. This lets you validate the behavior in monitored mode before moving to blocking. For more information, contact Traceable support.