An API anomaly is a sequence, not a suspicious request
An access-behaviour study points to a better security question: when does an ordinary session stop behaving like itself?
The pattern lives between calls
An API security project studies access behaviour using session and sequence features, then compares AdaBoost, Gradient Boosting and XGBoost. That framing matters: a request can look ordinary on its own while the pace, order or reach of calls makes the session unusual.
A detector that treats every deviation as an incident will overwhelm the people who have to review it. A detector that only flags extreme events can miss slow, low-noise changes. The system has to describe why a sequence moved out of its usual range, not just attach a red label.
Tune for the response team
Model selection is one part of the design. Thresholds should reflect the cost of a missed intrusion, the cost of an unnecessary escalation and the time available for investigation. Keep a baseline, test on held-out periods, and examine false positives by API, user type and session length.
The alert should carry its evidence: which behaviours changed, which data was used, and what the analyst can inspect next. A score without that trail is difficult to trust and even harder to improve.
Keep a person in the control loop
An anomaly score can prioritize attention; it should not quietly become an access decision. Give analysts a reversible next step, log what they decided, and feed reviewed outcomes back into evaluation. The product is the full loop from unusual activity to a defensible response.
Explore the project repository · Cyber-Security-Data-Research ↗