Context-Aware ML/NLP Pipeline for Real-Time Anomaly Detection and Risk Assessment in Cloud API Traffic

Abstract

We present a combined ML/NLP (Machine Learning, Natural Language Processing) pipeline for protecting cloud-based APIs (Application Programming Interfaces), which works both at the level of individual HTTP (Hypertext Transfer Protocol) requests and at the access log file reading mode, linking explicitly technical anomalies with business risks. The system processes each event/access log through parallel numerical and textual branches: a set of anomaly detectors trained on traffic engineering characteristics and a hybrid NLP stack that combines rules, TF-IDF (Term Frequency-Inverse Document Frequency), and character-level models trained on enriched security datasets. Their results are integrated using a risk-aware policy that takes into account endpoint type, data sensitivity, exposure, and authentication status, and creates a discrete risk level with human-readable explanations and recommended SOC (Security Operations Center) actions. We implement this design as a containerized microservice pipeline (input, preprocessing, ML, NLP, merging, alerting, and retraining services), orchestrated using Docker Compose and instrumented using OpenSearch Dashboards. Experiments with OWASP-like (Open Worldwide Application Security Project) attack scenarios show a high detection rate for injections, SSRF (Server-Side Request Forgery), Data Exposure, and Business Logic Abuse, while the processing time for each request remains within real-time limits even in sequential testing mode. Thus, the pipeline bridges the gap between ML/NLP research for security and practical API protection channels that can evolve over time through feedback and retraining.

1. Introduction

Cloud platforms have rapidly emerged as the predominant environment for hosting a wide array of business processes. It has been observed that certain companies elect to transfer solely auxiliary services to the location in question, whilst others construct their infrastructure with a strong focus on managed cloud services and multi-cloud schemes [1]. In such environments, APIs (application programming interfaces) assume the role of the central element of interaction, encompassing internal microservice calls, external partner APIs, and mobile clients. In the contemporary business landscape, the typical request has evolved from a simple notification to a more complex POST/api/v1/payments/{id} request, accompanied by a set of headers and a JSON (JavaScript Object Notation) body.

This has shifted the attack surface from traditional web pages to API gateways and cross-service interactions. A review of cloud security measures reveals that attackers are actively exploiting injections into request parameters, access token stuffing, business logic abuse, and attacks on managed secrets. As asserted by the author of [2], the higher the automation level of the infrastructure, the greater its dependence on the correct behavior of the API, and the more detrimental the impact of traffic anomalies.

The traditional approaches to cybersecurity, such as those based on WAF (Web Application Firewall), IDS (Intrusion Detection System), and static rule sets, have been playing their part for a long time. However, their effectiveness is noticeably declining. In practice, even the most advanced signature-based solutions are falling behind the pace of service updates, because APIs are being versioned, new paths are being added, and authorization schemes are changing. It means that the exact same SQL-like (Structured Query Language) text snippet in a URL (Uniform Resource Locator) can be a trivial testing query in a sandbox environment and a critical injection in real payment systems.

As a result of these limitations, researchers are increasingly turning to machine learning. Mamidi [3] comprehensively outlines a plethora of machine learning (ML) and deep learning (DL) methodologies employed for the analysis of network traffic and security events occurring within the cloud computing environment. The review conducted by Belal and Sundaram [4] substantiates the utilization of an extensive spectrum of models in practical scenarios, ranging from conventional support vector machines (SVMs) and isolation forests to autoencoders and neural network ensembles.

Machine learning algorithms, such as anomaly detection models, forest ensembles, and neural networks, have demonstrated notable efficiency in detecting atypical activity, even in scenarios where manual rule-based approaches are no longer feasible. The challenge resides in another domain entirely. Business environments are subject to rapid traffic fluctuations and shifting feature distributions. This makes it impractical to update models every few months, as is the case in traditional research [5]. Therefore, a proportion of the work either remains at the level of laboratory experiments or does not provide clear instructions (operational runbooks, configuration guidelines) on how to maintain such a system in an environment with limited resources (computing and storage budget, security engineering time, and operational tooling). In practice, ML/NLP defenses often remain research prototypes because they lack monitoring for drift and false positives, clear retraining triggers, and runbooks that connect detections to concrete incident-response steps.

At the same time, experience in applying NLP to cybersecurity is accumulating. Ref. [6] describes the construction of a scalable pipeline for extracting events from text logs in real time. Ref. [7] shows how manual NLP pipelines and FastAPI microservices simplify working with medical data. In Georgescu’s work [8], language models are used to analyze descriptions of threats and vulnerabilities.

Put simply, the ability to adequately read URIs (Uniform Resource Identifiers), headers, and log text has already become a separate skill in cloud security. There are also works at the intersection of ML and NLP. Ref. [9] demonstrated that the combination of these methods strengthens cybersecurity in smart energy networks. Chanthati [10] describes scenarios for preventing financial fraud and spoofing attacks, where text signals complement purely numerical features. In this case, text attributes serve as additional risk indicators alongside numerical transaction characteristics. All these cases share a similar idea that ML works well with metrics, counters, and time series, whereas NLP adds an understanding of what exactly is written in a query or log entry.

Looking at these works from the perspective of an engineer who is actually responsible for the API gateway, several gaps become noticeable. Primarily, most solutions are focused either on log files and documents or on network flow data. A full-fledged stream processing of HTTP(S) (Hypertext Transfer Protocol (Secure)) requests to business APIs with a delay of tens of milliseconds is rarely mentioned there.

The challenge of integration with risk management is frequently reduced to a solitary threshold for model evaluation, with little to no consideration for the request’s intended destination, such as/api/v1/admin/users within a business environment, as opposed to a test health check. The issues of explainability and feedback are often postponed. Recent surveys on ML/DL for cloud security explicitly identify explainability as an open challenge and emphasize the need for continuous monitoring and feedback loops, rather than relying on black-box decisions alone [3,5,7]. The question arises of how a SOC (Security Operations Center) analyst is to comprehend the rationale behind the model’s identification of an SQL injection and how to proceed. To address this gap, our pipeline provides analyst-oriented explanations and recommended actions, and proposes an on-demand or periodic feedback-driven retraining workflow, with future work focused on automating this loop.

In addition, it is noteworthy to mention works that are more closely related to our context. A consideration of the articles by Martseniuk and co-authors [11,12,13] reveals that they address issues of security in the cloud environment, as well as the management of incidents in cloud infrastructure. While these works provide a solid foundation, they do not detail the API protection pipeline with an explicit risk policy and real-time retraining mechanism. In our setting, an explicit risk policy goes beyond a single anomaly threshold and incorporates contextual factors, such as environment, entry-point class, exposure, authentication status, and data criticality, so that similar anomaly evidence can produce different risk levels depending on business impact (see Section 3.5 and Section 4.5). Moreover, in our design, “real-time” refers to streaming detection and risk level assignment in the data plane, whereas model updates are handled via a control-plane retraining job executed periodically or on demand (see Section 4.6).

In the present study, the next step is taken, with a context-aware ML/NLP pipeline proposed for the detection of anomalies and the assessment of risk in cloud API traffic. Essentially, the pipeline can be considered a set of microservices that operate in sequence, as outlined below. First, HTTP events are converted into numerical and textual features. Second, the anomaly should be evaluated based on both behavioral metrics and the content of the request body. Third, the technical assessment should be combined with the business context (service type, data sensitivity, exposure) to create a risk level. Fourth and finally, explainable alerts that are suitable for daily SOC operations should be returned. The subsequent sections elucidate this process in a gradual, sequential manner, commencing with a formal model of events and risk, followed by a discussion of pipeline architecture, conveyor implementation, and culminating with an exposition of experimental results.

2. Related Work

In this section, we group the related works into four clusters:

(1)

Classic rule-based and signature-based approaches to protect web and cloud services;

(2)

Using ML/AI to detect anomalies in cloud traffic and logs;

(3)

Applying NLP to security tasks;

(4)

Integrated ML/NLP pipelines and cloud analytics platforms.

We are not very interested in a complete catalog of approaches, but rather in answering three practical questions:

• Which existing solutions can be directly incorporated into a streaming API request analysis pipeline?
• What gaps remain?
• Where does our approach stand in the field of already published works?

2.1. Rule-Based and Signature-Based Approaches to Cloud Service Protection

Originally, the front line of defense for web applications consisted of manual rules and signature-based mechanisms such as firewalls, IDS/IPS (Intrusion Prevention System), and WAF, with ready-made template sets.

These work well when the attack structure is relatively stable with a known malicious fragment in the request body, a specific parameter in the URI, or a characteristic sequence of requests. In cloud environments, these mechanisms are still present, but they are increasingly being wrapped in layers of automation and analytics.

A detailed review [14] describes classic static and signature controls as a basic level of protection, on top of which ML/DL components, event correlation systems, and automated incident response are built. ACLs (Access Control Lists), firewalls, and hard-coded policies remain necessary but insufficient when it comes to dynamic microservice systems.

The experience of designing cloud platforms confirms this from an architectural point of view. Khoma and co-authors demonstrate a multi-level multi-cloud architecture with dozens of services, accounts, and access zones, where security as code policies are distributed across WAF, IAM (Identity and Access Management), network ACLs, monitoring services, and logging tools [15].

An author of the AWS (Amazon Web Services) guide to implementing Zero Trust emphasizes that in such an environment, you cannot only rely on once-and-for-all agreed access patterns: each request should be checked against the current context, not just against static signatures [16].

Vashishth and colleagues summarize the role of AI (Artificial Intelligence)/ML in cloud cybersecurity. They demonstrate that anomaly detection models, decision trees, and hybrid ensembles can detect attacks where manual policies simply cannot keep up with updates [17].

From an operational perspective, this means the following. Simple rules still have a role to play, whether it is blocking known malicious URIs, enforcing encryption, or correcting CORS (Cross-Origin Resource Sharing) policies. However, in a system with dozens of microservices and several cloud providers, the number of “if … then block/allow” conditions quickly exceeds the limits of what can be maintained manually. This problem is partially mitigated through formal threat modeling [18]. But even a high-quality threat model cannot replace the daily analysis of real API traffic, where decisions must be made within tens of milliseconds.

To summarize, the rule layer remains necessary, but it tends to set the policy framework. Detailed traffic analysis is increasingly being transferred to ML and NLP components.

2.2. Machine Learning for Detecting Anomalies in Cloud Traffic and Logs

A large group of studies is devoted to the use of ML and DL for detecting anomalies in cloud environments. Rakgoale and co-authors analyze the application of ANN (Artificial Neural Network), CNN (Convolutional Neural Network), autoencoder, and hybrid ensemble models in network security, cloud services, and critical infrastructure tasks [19]. Their overview clearly demonstrates the breadth of domains, from medicine and finance to telecommunications and energy. For convenience, we have summarized examples from their work in

Table 1. AI/ML applications in different industries [19].

Industry	AI/ML Applications
Healthcare	Medical imaging analysis, personalized treatment plans, drug discovery, virtual nursing assistants, predictive analytics for patient outcomes.
Finance	Fraud detection, algorithmic trading, credit scoring, risk assessment, personalized banking experiences, customer service chatbots.
Retail	Recommendation engines, demand forecasting, inventory management, customer segmentation, personalized marketing campaigns, chatbots for customer support.
Automotive	Autonomous vehicles, predictive maintenance, driver behavior analysis, traffic management, vehicle diagnostics.
Manufacturing	Production process optimization, predictive maintenance, quality control, supply chain management, robot-assisted manufacturing.
Telecommunications	Network optimization, predictive maintenance, customer churn prediction, personalized marketing, network security.
Energy	Energy demand forecasting, predictive maintenance of equipment, grid optimization, renewable energy integration, energy trading.

.

Some researchers go beyond the classical cloud infrastructure. Manoharan and Sarker described AI as the basis for the next generation of threat detection systems. They use models that work on top of logs, network flows, and telemetry, and the results are integrated with SOC processes [20]. The authors of [21] focus on how machine learning algorithms enhance traditional tools through behavioral analytics of users and services.

Such works conclusively demonstrate that ML models are effective at detecting atypical activity when sufficient historical data is available. Nevertheless, several limitations are important for business API protection scenarios:

• The majority of experiments are performed on static rules, where analysis delay is not critical. Streaming HTTP requests to business APIs with a budget of tens of milliseconds is considered much less frequently.
• The models often work with aggregated network features (IP addresses, ports, traffic volume, session duration), while the actual content of HTTP requests is either oversimplified to a few simple features or ignored altogether.
• The models’ lifecycle (feedback collection, retraining, data drift control) is described more conceptually. The researchers indicate that the model can be updated, but they seldom explain how to implement this in a real event pipeline.

In this paper, we rely on these findings but shift the focus to a streaming analysis of HTTP(S) events with explicit, well-defined ML features and a retraining mechanism within the pipeline.

2.3. Using NLP in Security and Cloud Services

Avornicului, with collaborators, proposes a scalable platform for extracting events in real time from text streams—news, social media, logs, and open sources [22]. Their framework includes modules for data collection, language processing (TF-IDF filtering, LSI (Latent Semantic Filtering) clustering, NER (Named Entity Recognition)), structured documents, and a query interface. The platform was designed from the beginning to be distributed and cloud-ready.

The individual services are responsible for text normalization, anonymization, classification, and storage of results, effectively implementing the NLP-as-a-service model in a cloud-native environment. This work is important to us because it shows how NLP modules can be organized into a separate service layer.

Silvestri and colleagues analyze cyber threats and vulnerabilities in the healthcare sector using text descriptions of CVE (Common Vulnerabilities and Exposures) records [23]. They convert the descriptions into TF-IDF space and train ML models (logistic regression and XGBoost) to predict CVSS (Common Vulnerability Scoring System) exploitability and impact metrics.

In the work [24], topic modeling is used to analyze cloud logs, where topics related to security and resource utilization allow for the detection of atypical patterns in system behavior. NLP helps to understand what the log array is talking about, rather than just classifying individual records.

More practical scenarios are being developed in the meantime. Rangappa and colleagues combine NLP with blockchain and smart contracts for secure management of sensitive data in the cloud [25]. The authors of [26] apply NLP to analyze privacy and security standards and certifications to assess how requirements are reflected in provisions for cloud providers. Ref. [27] reviews approaches to publishing language models as REST services that can be reused in different domains.

For our task, we are particularly interested in works where NLP is used directly for network or application protocols. Pham and Do propose the DL-WAD (Deep Learning solution for Web Attack Detection) approach, in which HTTP requests go through normalization, tokenization, and word embedding stages, after which a deep learning model classifies the request as malicious or valid [28]. Similar ideas are also used in SMS spam tasks, where text messages are classified using n-grams, TF-IDF, and neural models.

The common ground for most NLP works is that language models work with text around an event (logs, incident descriptions, regulatory documents, user messages) [29,30]. The direct analysis of HTTP(S) requests to business APIs is rare and mostly boils down to a separate request body classifier without integration with the service context, risks, and other signal sources.

2.4. Integrated ML/NLP Approaches to Protect Cloud Systems

The last group of works attempts to combine ML and NLP into single workflows or analytical platforms.

In [31], smart grid scenarios are analyzed, where text descriptions of events (reports, logs, operator messages) and telemetry from equipment are considered together to detect complex cyber threats. Haq and co-authors, continuing their research on internal threats, consider word embedding (Word2Vec/GloVe representation) as an additional layer of features for ML classifiers [32].

In more recent works by Hussain [33] and Wang [34], AI/ML are integrated into broader cloud analytics platforms for medicine and ERP systems. While language models, classical ML, and business analytics work together, the main focus is on data analysis and decision support rather than specialized API gateway monitoring. Okare et coauthors are building compliance intelligence models for financial platforms, where ML helps identify suspicious transactions and potential regulatory violations [35]. In this case, APIs act as a transport layer for events, but are not the subject of detailed analysis at the level of the individual HTTP requests.

In our previous work [36], we proposed an architecture for an integrated NLP/ML cloud infrastructure protection system focused on analyzing logs, configurations, and security events in multi-cloud environments. The architecture provides separate modules for log processing, the UEBA (User and Entity Behavior Analytics), vulnerability classification, and risk management. Meanwhile, our previous implementation is conceptual in nature and does not cover a full-fledged API protection pipeline with clearly defined ML features, risk policy, and hysteresis mechanisms, as well as a containerized implementation.

To summarize the overview, we can highlight several key gaps that became the starting point for our work:

• Most ML solutions work with network flow data or aggregated logs, rather than with real HTTP(S) calls to business APIs at the level of individual events;
• NLP is primarily applied to texts around events (logs, incident descriptions, regulatory documents), while URIs, headers, and request bodies are analyzed much less frequently and usually separately from other signal sources;
• Integration with risk management is often reduced to a single model evaluation threshold without any explicit consideration of service type, data class, environment, and exposure;
• The full lifecycle for cloud APIs is either described at a high level or left out of the implementation altogether.

In the next sections, we propose a pipeline that addresses these gaps. It combines numerical ML scores, text-based query analysis, a formalized risk policy, and a unified system that works with HTTP(S)/API traffic in near real time and generates understandable notifications, which are suitable for the daily work of SOC teams.

3. Methodology

This section presents the pipeline’s mathematical model and its microservice implementation through a single running example. We follow one sanitized HTTP(S) request end-to-end and explicitly track (i) the core data objects, (ii) the derived representations used by ML and NLP, (iii) the decision and risk policy outputs, and (iv) the feedback and retraining loop.

3.1. Formal Representation of an API Event and End-to-End Pipeline Overview

Throughout Section 3, the same request (

Table 2. Incoming event example.

Parameter	Value
Method	POST
URI	/api/auth/login
Headers	Content-Type = application/json
Body	<payload>
Client	source_ip = 198.51.100.10; user_id = u_12345
Runtime	status_code = 401; latency_ms = 240

) is referenced to illustrate how the formal definitions (Equations (1)–(12)) map to concrete fields and the artifacts produced and consumed by the pipeline modules.

The basic object in the system is a separate event that corresponds to a single HTTP(S) request to the API. We present it as a tuple:

$$\mathrm{e}=\left(\mathrm{t},\mathrm{u},\mathrm{m},\mathrm{h},\mathrm{p},{\mathrm{s}}_{\mathrm{i}\mathrm{p}},{\mathrm{u}}_{\mathrm{i}\mathrm{d}}\right),$$

where $\mathrm{t}$—time of request reception; $\mathrm{u}$—endpoint (URI path together with the query string); $\mathrm{m}$—HTTP method; $\mathrm{h}$—header dictionary; $\mathrm{p}$—payload (request body); ${\mathrm{s}}_{\mathrm{i}\mathrm{p}}$—source IP address; ${\mathrm{u}}_{\mathrm{i}\mathrm{d}}$—user identifier, if provided by the authentication system.

In our implementation, the same request is represented by the ApiEvent object and additionally carries runtime attributes that support monitoring and performance evaluation, namely $\mathrm{s}\mathrm{t}\mathrm{a}\mathrm{t}\mathrm{u}{\mathrm{s}}_{\mathrm{c}\mathrm{o}\mathrm{d}\mathrm{e}}$, $\mathrm{l}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}{\mathrm{y}}_{\mathrm{m}\mathrm{s}}$. For the running example request introduced above, these fields are populated directly from the sanitized HTTP request and the observed runtime attributes.

To reliably correlate the same request across pipeline modules, we compute a deterministic correlation/deduplication key $\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$ for each event:

$$\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}=\mathrm{H}\left(\mathrm{u},\mathrm{m},{\mathrm{s}}_{\mathrm{i}\mathrm{p}},{\mathrm{u}}_{\mathrm{i}\mathrm{d}},\mathrm{p}\left[1:\mathrm{K}\right],{\left|\mathrm{t}\right|}_{∆\mathrm{t}}\right), ∆\mathrm{t}=1 s$$

(1)

where $\mathrm{H}\left(·\right)$ is the cryptographic hash function, $\mathrm{p}\left[1:\mathrm{K}\right]$ is the prefix of the payload of a fixed length in bytes, and ${\left|\mathrm{t}\right|}_{∆\mathrm{t}}$ denotes time bucketing to resolution $\mathsf{\Delta }\mathrm{t}$ (the default is 1 s). This design intentionally maps repeated deliveries of the same request within a short time window to the same $\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$, enabling correlation and hysteresis keyed by a stable identifier while avoiding the propagation of raw sensitive content.

Figure 1 provides a high-level map of the proposed ML/NLP pipeline for processing a single ApiEvent and producing risk-evaluated outputs.

Collision handling

Although ${\left|\mathrm{t}\right|}_{∆\mathrm{t}}$ is bucketed to 1 s, collisions between different requests are mitigated because the hash input also includes event-specific fields (m, ${\mathrm{u}}_{\mathrm{i}\mathrm{d}}$, ${\mathrm{s}}_{\mathrm{i}\mathrm{p}}$, $\mathrm{p}\left[1:\mathrm{K}\right]$), and the key is used as a bounded-time correlation/deduplication identifier via Redis NX/EX with a finite TTL. For high-throughput bursts, collision risk can be further reduced by using finer time resolution ($\mathsf{\Delta }\mathrm{t}<1 \mathrm{s}$) or adding a per-event nonce/trace identifier in future work, while keeping ${\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}_{\mathrm{i}\mathrm{d}}$ as the correlation key.

At this stage, we use the figure only as a structural guide for the running example: the request is ingested, normalized into an ApiEvent with a stable $\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$, processed by feature/context extraction, evaluated by two analysis branches (numerical ML and textual NLP), and finally mapped by the decision policy into a discrete risk level with an explanation and recommended actions. The formal definitions of all intermediate representations and signals used in this flow (including their concrete fields) are introduced step-by-step in the following subsections, each time referring back to the same running example request.

3.2. Feature Vector and Text Representation: Preprocessing and Feature Construction

For the running example introduced in Section 3.1, the preprocessing stage is responsible for converting a raw HTTP request (and its runtime attributes) into a stable, service-independent representation that can be consumed consistently by the downstream ML and NLP branches. Concretely, this stage produces two complementary views of the same request, numerical features, and textual fields, together with auxiliary context objects that are later used by the policy logic.

To combine the numerical and textual perspectives, we define the request representation as follows:

$$\mathrm{x}=\left({\mathrm{x}}_{\mathrm{n}\mathrm{u}\mathrm{m}},{\mathrm{x}}_{\mathrm{t}\mathrm{e}\mathrm{x}\mathrm{t}}\right),$$

(2)

where ${\mathrm{x}}_{\mathrm{n}\mathrm{u}\mathrm{m}}$ is a fixed-schema numeric feature vector (used by ML branch), and ${\mathrm{x}}_{\mathrm{t}\mathrm{e}\mathrm{x}\mathrm{t}}$ is a normalized textual representation (prepared for NLP analysis). In the implementation, this corresponds to a preprocess service that validates the input, normalizes selected fields, and emits a structured output that downstream services treat as a contract. Figure 2 summarizes the preprocessing stage and the resulting artifacts passed downstream, including the context object that is formally defined in Section 3.3.

Numerical features (${\mathbf{x}}_{\mathbf{n}\mathbf{u}\mathbf{m}}$)

The preprocessing module derives a deterministic set of numeric features from the request metadata and runtime attributes. The feature schema is fixed to ensure that model bundles can be hot-reloaded without ambiguity in feature order. In particular, the numeric feature set includes the following:

• Endpoint structure and size: $\mathrm{l}\mathrm{e}\mathrm{n}\left(\mathrm{u}\right)$ as the length of the endpoint path, $\mathrm{p}\mathrm{a}\mathrm{t}{\mathrm{h}}_{\mathrm{d}\mathrm{e}\mathrm{p}\mathrm{t}\mathrm{h}\left(\mathrm{u}\right)}$ as the depth of the path, ${\mathrm{q}}_{\mathrm{c}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{t}\left(\mathrm{u}\right)}$ as the number of request parameters;
• $\left|\mathrm{h}\right|$ as the number of headers and the entropy of their values;
• $\left|\mathrm{p}\right|$ as the size of the request body and a binary indicator “request body is similar to JSON”;
• URI/body surface signals: suspicious_char_ratio;
• The numerical encoding of the HTTP method and an assessment of the correctness of the method for this path: http_method_code, http_method_accuracy;
• An assessment of the speed of requests from the same IP address or for the same user in a sliding window;
• ${\mathrm{I}}_{\mathrm{p}\mathrm{r}\mathrm{i}\mathrm{v}\left({\mathrm{s}}_{\mathrm{i}\mathrm{p}}\right)}$ as a private IP address indicator;
• Operational runtime attribute ($\mathrm{l}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}{\mathrm{y}}_{\mathrm{m}\mathrm{s}}$).

This design keeps the ML branch independent of raw log formats while preserving enough structure to detect deviations in traffic behavior.

Text fields (${\mathbf{x}}_{\mathbf{t}\mathbf{e}\mathbf{x}\mathbf{t}}$)

In parallel, the preprocess stage assembles a compact textual document that the NLP branch can analyze using rules, token models, and vector representations. The output text structure is formed from the following:

• Endpoint (normalized URI, including query string if present);
• Method;
• Headers in the key-value form;
• Payload (represented as <payload> in manuscript examples);
• Optional supporting fields such as error_text, user_id, source_ip, and log_kind.

The normalization includes URL decoding, HTML entity decoding, case unification, removal of control characters, and excess spaces. As a result, ${\mathrm{x}}_{\mathrm{t}\mathrm{e}\mathrm{x}\mathrm{t}}$ is treated by the NLP module as a document suitable for n-gram and vector representations.

3.3. Risk Context and Attack Categories

The same technical anomaly may have different weights in a test environment and in a financial system. To capture this, we introduce a separate risk context and a set of attack topics.

Risk context

The context describes where and what we are protecting:

$$\mathrm{c}=\left({\mathrm{c}}_{\mathrm{e}\mathrm{n}\mathrm{v}},{\mathrm{c}}_{\mathrm{e}\mathrm{n}\mathrm{d}\mathrm{p}\mathrm{o}\mathrm{i}\mathrm{n}\mathrm{t}},{\mathrm{c}}_{\mathrm{d}\mathrm{a}\mathrm{t}\mathrm{a}},{\mathrm{c}}_{\mathrm{a}\mathrm{u}\mathrm{t}\mathrm{h}},{\mathrm{c}}_{\mathrm{e}\mathrm{x}\mathrm{p}\mathrm{o}\mathrm{s}\mathrm{u}\mathrm{r}\mathrm{e}},{\mathrm{c}}_{\mathrm{b}\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{t}}\right),$$

(3)

where

• ${\mathrm{c}}_{\mathrm{e}\mathrm{n}\mathrm{v}}$—environment type (prod, stage, dev);

• ${\mathrm{c}}_{\mathrm{e}\mathrm{n}\mathrm{d}\mathrm{p}\mathrm{o}\mathrm{i}\mathrm{n}\mathrm{t}}$—endpoint class (authentication, payments, administration, public API, and similar categories);

• ${\mathrm{c}}_{\mathrm{d}\mathrm{a}\mathrm{t}\mathrm{a}}$—data type (regular, PII, financial data, credentials);

• ${\mathrm{c}}_{\mathrm{a}\mathrm{u}\mathrm{t}\mathrm{h}}$—authentication status (anonymous, authenticated user, privileged user);

• ${\mathrm{c}}_{\mathrm{e}\mathrm{x}\mathrm{p}\mathrm{o}\mathrm{s}\mathrm{u}\mathrm{r}\mathrm{e}}$—service exposure (internal, partner, public);

• ${\mathrm{c}}_{\mathrm{b}\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{t}}$—approximated as a traffic amplification indicator derived from the recent request rate.

These components are derived from service configuration, endpoint naming conventions, data labeling, and operational knowledge about the protected system. A minimal illustration for the running example is as follows:

“risk_context”: {

“env”: “prod”,

“endpoint_class”: “auth”,

“data_class”: “secrets”,

“auth_state”: “user”,

“exposure”: “public”,

“blast”: “medium”

}

This context is consumed later by the impact and policy logic (Section 3.5) to convert anomaly evidence into a risk-aware decision.

Set of attack topics

We interpret the result of NLP analysis as a set of possible attack topics:

$$\mathrm{T}=\left\{\left({\mathrm{t}}_{\mathrm{i}},\mathrm{p}{\mathrm{i}}_{\mathrm{i}}\right)\right\},\hspace{1em}\hspace{1em}\hspace{1em}\mathrm{i}=1\dots \mathrm{K},$$

(4)

where ${\mathrm{t}}_{\mathrm{i}}$ is the name of the topic (attack category), and $\mathrm{p}{\mathrm{i}}_{\mathrm{i}}\in \left[0,1\right]$ is the confidence or probability that the event belongs to this topic.

In our implementation, the attack topic inventory is a fixed, reproducible dictionary of canonical identifiers mapped to analyst-facing labels, and it is returned by the NLP branch as a ranked list of topic objects with the schema (topics[i].topic, topics[i].score). Concretely, the supported topic set covers SQL Injection, NoSQL Injection, LDAP (Lightweight Directory Access Protocol) Injection, Command Injection, SSRF (Server-Side Request Forgery), Cloud Metadata SSRF (Instance Metadata Service (IMDS)), XSS (Cross-Site Scripting), Authentication Brute-Force, Credential Stuffing, DoS (Denial-Of-Service)-like patterns, IDOR (Insecure Direct Object References), Security Misconfiguration, Sensitive Data Exposure, WebSocket Abuse, API Key Exposure, and Business Logic Abuse. Together, these categories provide a practical coverage of common API/Web abuse patterns used in monitoring, while preserving a stable topic ID space for downstream policy logic and explanation generation.

The value of $\mathrm{p}{\mathrm{i}}_{\mathrm{i}}$ is generated based on a joint signal from rules, TF-IDF classifiers, and character n-gram models.

In the implementation, topics are represented as a list of objects with an explicit schema:

• topic—category label;
• score—confidence in [0, 1]

Example of a topic list:

“topics”: [

{“topic”: “sqli”, “score”: 0.83},

{“topic”: “bruteforce”, “score”: 0.41}

]

Role separation between ML and NLP: In the current design, topic assignment is produced by the NLP branch because it operates on the normalized textual representation of the request and can map patterns into analyst-aligned categories. The ML branch does not emit attack topics; instead, it produces an anomaly score over numeric features and diagnostic evidence (per-model contributions). This evidence is later combined with topics and context to build explanations and to support policy decisions (Section 3.4 and Section 3.5).

Detailed mechanisms for computing topic scores and textual suspiciousness are described in Section 3.4. The use of $\mathrm{c}$ and $\mathrm{T}$ in impact and policy mapping is presented in Section 3.5.

3.4. Anomaly Evaluation Based on Numerical and Textual Features

For each request representation $\mathrm{x}$ produced by preprocessing (Section 3.2) and interpreted in the context $\mathrm{c}$ and topic inventory $\mathrm{T}$ (Section 3.3), the pipeline computes two complementary anomaly signals: a numerical score from structured features and a textual score from request content. Formally, the two branches implement

$$\mathrm{m}{\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}={\mathrm{f}}_{\mathrm{m}\mathrm{l}\left({\mathrm{x}}_{\mathrm{n}\mathrm{u}\mathrm{m}}\right)}\in \left[0,1\right],$$

(5)

$$\mathrm{n}\mathrm{l}{\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}={\mathrm{f}}_{\mathrm{n}\mathrm{l}\mathrm{p}\left({\mathrm{x}}_{\mathrm{t}\mathrm{e}\mathrm{x}\mathrm{t}}\right)}\in \left[0,1\right],$$

(6)

where the ML branch operates on fixed-schema numerical features ${\mathrm{x}}_{\mathrm{n}\mathrm{u}\mathrm{m}}$, while the NLP branch operates on the normalized text representation ${\mathrm{x}}_{\mathrm{t}\mathrm{e}\mathrm{x}\mathrm{t}}$ and additionally returns the attack topic set $\mathrm{T}$ defined in Equation (4).

3.4.1. ML Branch: Numerical Anomaly Scoring

The ML branch evaluates deviations in traffic structure and runtime behavior using the numerical feature view ${\mathrm{x}}_{\mathrm{n}\mathrm{u}\mathrm{m}}$ (derived from numeric_feats). In the implementation, the service first applies feature standardization using metadata shipped with the model bundle (feature order and scaling parameters), ensuring that hot-reloaded artifacts remain consistent across deployments. The standardized vector is then scored by an ensemble of detectors and auxiliary classifiers (e.g., Isolation Forest, One-Class SVM, and autoencoder-style reconstruction models), each producing a partial anomaly estimate. These partial outputs are aggregated into a single ${\mathrm{m}\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}\in \left[0,1\right]$.

Concretely, the ML output contract includes $\mathrm{m}{\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$ and per_model score map, together with operational decision hints such as threshold_hit and the list used_models, indicating which models contributed to the final score. Figure 3 summarizes this sequence from input features to the final ML score and diagnostics.

3.4.2. NLP Branch: Textual Anomaly Scoring and Topic Inference

The NLP branch evaluates the request content using the textual view ${\mathrm{x}}_{\mathrm{t}\mathrm{e}\mathrm{x}\mathrm{t}}$ (assembled from text_fields). After text normalization (canonicalization and decoding), the system combines three families of detectors: (i) rule-based pattern matching (regex/dictionaries), (ii) general-purpose vector models (TF-IDF logistic regression and character n-gram classifiers), and (iii) specialized classifiers for high-impact patterns (e.g., SSRF-sensitive targets). Each detector contributes a partial score captured in per_model = [{kind, score}]. The final ${\mathrm{n}\mathrm{l}\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}\in \left[\mathrm{0,1}\right]$ is computed as an aggregate over these signals.

In addition to the scalar score, the NLP branch returns a ranked topic set, topics = [{topic, score}], corresponding to Equation (4). Figure 4 summarizes the detector families and the resulting outputs (${\mathrm{n}\mathrm{l}\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, $\mathrm{T}$).

3.5. Impact Policy and Integrated Risk Assessment, and Hysteresis for Stable Risk Decisions

A raw anomaly score alone is not a sufficient proxy for operational risk: the same deviation may be acceptable in a development environment but unacceptable for authentication, payment, or administrative endpoints in production. Therefore, the pipeline separates (i) anomaly evidence produced by the ML and NLP branches from (ii) business-aware impact, and then applies a stability mechanism to prevent oscillating decisions in a streaming setting (see the fusion/policy node in Figure 1).

Fusion of ML and NLP signals

The ML and NLP branches independently produce normalized anomaly scores $\mathrm{m}{\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$ and $\mathrm{n}\mathrm{l}{\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$ (Section 3.4). These are combined into an intermediate integrated score:

$$\mathrm{s}=\mathsf{\alpha }\times \mathrm{m}{\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}+\mathsf{\beta }\times \mathrm{n}\mathrm{l}{\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}},\mathsf{\alpha },\mathsf{\beta }\in \left[\mathrm{0,1}\right],\mathsf{\alpha }+\mathsf{\beta }=1,$$

(7)

The weights $\mathsf{\alpha }$ and $\mathsf{\beta }$ are set by the policy. In a basic case, they are fixed, but the policy also has an adaptive mode where the weights depend on, say, the completeness of text fields or the class of the entry point.

Impact assessment driven by context and topics

To translate anomaly evidence into business risk, the pipeline computes a separate impact score:

$$\iota =\mathrm{I}\mathrm{m}\mathrm{p}\mathrm{a}\mathrm{c}\mathrm{t}\left(\mathrm{c},\mathrm{T};\mathrm{P}\right),$$

(8)

where $\mathrm{c}$ is the structured risk context (Section 3.3), $\mathrm{T}$ is the topic set returned by the NLP branch (Section 3.3), and $\mathrm{P}$ denotes a policy parameterization (represented as a configuration). Conceptually, $\mathrm{I}\mathrm{m}\mathrm{p}\mathrm{a}\mathrm{c}\mathrm{t}\left(\cdot \right)$ assigns base weights to context components (environment, endpoint class, data class, authentication state, exposure, blast descriptor) and then applies topic-dependent adjustments for critical combinations. For example, SSRF-like topics in a production-facing service can be assigned a higher impact than the same topic in a non-production environment. The purpose of this separation is interpretability and maintainability: engineers can tune impact behavior via policy parameters without modifying ML/NLP models or pipeline code.

Mapping ($\mathbf{s},\mathsf{\iota }$) to a discrete risk level

The integrated anomaly score $s$ and impact score $\iota$ are mapped to a discrete operational decision:

$$\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}=\mathrm{P}\mathrm{o}\mathrm{l}\mathrm{i}\mathrm{c}\mathrm{y}\left(\mathrm{s},\mathsf{\iota };\mathsf{\theta }\right),$$

(9)

where $\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}\in \left\{\mathrm{N}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{a}\mathrm{l},\mathrm{L}\mathrm{o}\mathrm{w},\mathrm{M}\mathrm{e}\mathrm{d}\mathrm{i}\mathrm{u}\mathrm{m},\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h},\mathrm{C}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l}\right\}$, and $\mathsf{\theta }$ sets the threshold ranges for score, impact, and the transition matrix. Thus, the same technical anomaly can result in different risk levels depending on the context and attack topics.

In this paper, we consider the specific choice of policy parameters P as an expert approximation of common risk management practices for cloud APIs. The construction logic corresponds to the classic risk matrix, in which events in the business environment carry more weight than those in the development environment. Operations involving payments, authentication, administration, sessions, and files are considered more critical than public read-only APIs. Working with credentials, tokens, payment information, and secrets is rated higher than access to general or non-financial data. The weights for context components c are selected to reflect these correlations while keeping the values $\mathsf{\iota }$ within the range [0, 1]. Within the scope of this work, this policy is a representative profile for cloud APIs, which can be adapted to a specific domain or refined based on incident history.

Hysteresis for decision stability over time

In streaming pipelines, small fluctuations in $s$ and $\iota$ can cause risk levels to bounce between adjacent states. To avoid noisy oscillations, the decision stage maintains a previous state ${\mathrm{l}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{v}}$ (keyed by $\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$ or an aggregation key such as user/IP) and applies hysteresis thresholds around each boundary:

$${\mathsf{\Theta }}_{\uparrow }\left({\mathrm{l}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{v}}\right)=\mathrm{b}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{d}\mathrm{a}\mathrm{r}\mathrm{y}\left({\mathrm{l}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{v}}\right)+{\mathsf{\delta }}_{\uparrow },$$

(10)

$${\mathsf{\Theta }}_{\downarrow }\left({\mathrm{l}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{v}}\right)=\mathrm{b}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{d}\mathrm{a}\mathrm{r}\mathrm{y}\left({\mathrm{l}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{v}}\right)-{\mathsf{\delta }}_{\downarrow },$$

(11)

where ${\mathsf{\delta }}_{\uparrow }$ and ${\mathsf{\delta }}_{\downarrow }$ are hysteresis margins, and $\mathrm{b}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{d}\mathrm{a}\mathrm{r}\mathrm{y}\left({\mathrm{l}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{v}}\right)$ is the nominal transition threshold. When the new value exceeds ${\mathsf{\theta }}_{\uparrow }$, the risk level increases; when it falls below ${\mathsf{\theta }}_{\downarrow }$, the level decreases; otherwise, $\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$ remains unchanged. The ${\mathrm{l}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{v}}$ state is stored in a Redis state store with a limited TTL to avoid infinite key accumulation.

For the running example (Section 3.1), the ML and NLP branches provide normalized anomaly evidence, ${\mathrm{m}\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$ and ${\mathrm{n}\mathrm{l}\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$ (Section 3.4), which is fused into an intermediate score s via Equation (7). Next, the pipeline computes a business-aware impact estimate ι from the structured risk_context c and the detected topic set $\mathrm{T}$ using Equation (8), and maps the pair (s, ι) to a discrete operational decision ${\mathrm{r}\mathrm{i}\mathrm{s}\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$ using Equation (9). In a streaming setting, near-duplicate or temporally adjacent events can exhibit small fluctuations in s and ι; therefore, the decision stage applies hysteresis margins around level boundaries (Equations (10) and (11)) using the previous state keyed by $\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$ (or an equivalent aggregation key) so that $\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$ changes only when evidence crosses stable thresholds rather than oscillating on minor score noise.

Table 3. Algorithm: Risk decision for a single API event.

Step	Module/Function	Input	Output	Explanation
1	Preprocess(e)	ApiEvent e	$\mathrm{fv} = \{\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$, numeric_feats, text_fields, risk_context}	Normalizes requests, builds numeric/text views and structured context.
2	ML_Service()	fv.numeric_feats, $\mathrm{fv}.\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}\_\mathrm{i}\mathrm{d}$	$\mathrm{ml} = \{\mathrm{m}{\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, threshold, threshold_hit}	Numeric anomaly score + decision hints.
3	NLP_Service()	fv.text_fields, $\mathrm{fv}.\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}\_\mathrm{i}\mathrm{d}$	$\mathrm{nlp} = \{\mathrm{n}\mathrm{l}{\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, topics = [{topic, score}]}	Text anomaly score + ranked attack topics.
4	Fusion (Equation (7))	$\mathrm{ml}.{\mathrm{m}\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, $\mathrm{nlp}. {\mathrm{n}\mathrm{l}\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, α,β	s	$\mathrm{s} = \mathsf{\alpha }·{\mathrm{m}\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$$+ \mathsf{\beta }·{\mathrm{n}\mathrm{l}\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, α + β = 1.
5	Impact (Equation (8))	fv.risk_context, nlp.topics; P	ι	Context/topic-based impact via policy parameters P.
6	Policy (Equation (9))	s, ι; θ	raw_level	Discrete level in {Normal, Low, Medium, High, Critical}.
7	State + hysteresis (Equations (10) and (11))	$\text{raw\_level}, \mathrm{StateStore}.\mathrm{get} (\mathrm{has} \mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}\_\mathrm{i}\mathrm{d}$); δ↑,δ↓	$\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$	$\mathrm{Stabilizes} \mathrm{decision} \mathrm{using} \mathrm{previous} \mathrm{level} \mathrm{for} \mathrm{the} \mathrm{same} \mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$.
8	Output materialization	${\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{h}}_{\mathrm{i}\mathrm{d}}$$, {\mathrm{r}\mathrm{i}\mathrm{s}\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$, s, ι, ml, nlp, risk_context	$\mathrm{alert} = \{\mathrm{R}$, actions}	$\mathrm{Builds} \mathrm{explanation} \mathrm{R}$ and recommended actions, then outputs the alert object.

summarizes the resulting single-event decision procedure implied by Equations (7)–(11), including preprocessing, ML/NLP scoring, fusion into s, impact computation ι, policy mapping to $\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$, and hysteresis stabilization over the correlation key.

3.6. Alerts, Incidents, and Explanation Objects

After the fusion, impact policy, and hysteresis mapping (Section 3.5), the pipeline materializes the decision into analyst-facing output objects: alerts and incidents, each accompanied by a structured explanation and recommended actions (Figure 1).

The overall decision process for a single request-level event can be summarized as a function:

$$\mathrm{F}:\mathrm{e}\to \left(\mathrm{s},\mathsf{\iota },\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}},\mathrm{T},\mathrm{R}\right),$$

(12)

where:

• $\mathrm{e}$—API input event;

• $\mathrm{s}$—fused anomaly indicator;

• $\mathsf{\iota }$—impact estimate;

• $\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$—stabilized decision (with hysteresis);

• $\mathrm{T}$—of detected attack topics with confidence scores;

• $\mathrm{R}$—structured explanation object intended for human consumption and downstream response automation.

For the running example (Section 3.1), the same tuple $\left(\mathrm{s},\mathsf{\iota },\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}},\mathrm{T},\mathrm{R}\right)$ is emitted once the ML and NLP branch outputs are fused and mapped by the policy stage.

Explanation object (R)

The explanation is designed to make the decision auditable and actionable. Concretely, it aggregates:

• ML evidence: the strongest contributing numerical features and score-based decisions that drove the $\mathrm{m}{\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$ (feature outliers, per-model partial scores from the ensemble, and calibration/normalization signals).
• NLP evidence: triggered rule hits and/or model signals that drove $\mathrm{n}\mathrm{l}{\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, including the leading topic(s) in $\mathrm{T}$ and their via provenance (rules, tfidf, char_ngram, specialized).
• Context highlights: key elements from risk_context that affected impact/policy mapping (env, endpoint_class, data_class, auth_state, exposure, blast).
• Recommended actions: a policy-selected action set aligned with SOC workflows (block_source_ip, rate limit, require re-authentication, open_incident_ticket, request_manual_review).

Alert and incident objects

The pipeline emits two complementary types of decision objects. An alert is a request-scoped entity that carries the evaluated $\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$, a concise view of $\mathrm{R}$, and metadata sufficient for dashboards and triage ($\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}},$ timestamp, endpoint, method, and top topics). An incident is an aggregated, investigation-oriented record that groups related alerts (by $\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$, source_ip, or user_id) and preserves the full explanation $\mathrm{R}$ along with historical evidence, correlation timeline, and analyst feedback fields. Incidents serve as both investigation records and labeled examples for model retraining.

In both cases, the system is designed to minimize sensitive data propagation: manuscript examples redact request bodies as <payload>, and operational deployments can store raw payloads only in controlled sinks (or omit them entirely) while keeping correlation and explainability via $\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$, feature summaries, and topic evidence.

To maintain data protection, payloads in examples and alerts are always redacted as <payload>. Operational deployments can either log raw payloads only to restricted forensic stores or omit them entirely, relying instead on feature summaries, $\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$, and topic-level evidence for traceability.

This final layer closes the processing loop: from a normalized API event, through scoring and contextual risk mapping, to an analyst-ready output enriched with structured evidence, explanations, and recommendations that support triage, investigation, and continuous model refinement.

3.7. Feedback Loop and Model Retraining

The final component of the pipeline is the feedback loop, which enables iterative refinement of the decision function $\mathrm{F}$ based on analyst review outcomes (Figure 5). Each emitted alert/incident can be assigned an outcome label by the SOC workflow.

We use the standard four-way taxonomy: TP (true positive—the pipeline raised an alert and the event is confirmed as malicious); FP (false positive—the pipeline raised an alert but the event is confirmed as benign or allowed); FN (false negative—a malicious event occurred but was not raised by the pipeline and is later discovered by investigation or external signals); TN (true negative—a benign event occurred and no alert was raised). Together with the label, the feedback record retains the corresponding event identifier $\mathrm{h}\mathrm{a}\mathrm{s}{\mathrm{h}}_{\mathrm{i}\mathrm{d}}$, the predicted $\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$, and the supporting evidence fields ($\mathrm{m}{\mathrm{l}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, $\mathrm{n}\mathrm{l}{\mathrm{p}}_{\mathrm{s}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{e}}$, and detected topics $\mathrm{T}$), which makes subsequent error analysis and data curation reproducible.

The intended use of these labels is to continuously improve both training corpora and model artifacts. In particular, TP and FN samples expand the attack portion of the numerical and textual datasets, while FP samples are used to harden models and rules against benign-but-unusual traffic (tests, edge-case clients, or atypical but permitted operations). The dataset builder aggregates labeled events into updated numerical training tables for the ML branch and updated text corpora for the NLP branch, and it can also refine rule-driven “silver” annotations used for weak supervision and explainability. A retraining job then rebuilds the ML/NLP model bundles together with their accompanying metadata (feature schema/order, calibration parameters, and evaluation summaries) so that inference services can hot-load versioned artifacts safely. In the current prototype, the labeling interface and persistence of feedback are supported, while fully automated dataset refresh, retraining triggers, and the safe deployment of new model versions are treated as future work (Section 6). Figure 5 summarizes the conceptual feedback-to-retraining flow and the artifacts that are updated.

4. Experimental Setting

In the previous paragraphs, we described the formal model of API events, the pipeline architecture, and individual ML/NLP modules. The next step is to see how this model behaves in practice with real HTTP scenarios, with a full load, and with a complete path from request to alert and incident creation. In this section, we focus on three aspects: (i) the quality of models on training samples; (ii) the behavior of the pipeline on OWASP-like attacks; (iii) the latency and throughput of the pipeline during a series of requests. In this work, latency denotes the end-to-end processing time for a single request, whereas throughput denotes the number of requests the pipeline can process per second under the same settings.

4.1. Experimental Environment

The experimental environment is built around the containerized pipeline described in Section 3. All services are executed locally using Docker Compose, enabling a reproducible setup that emulates a typical cloud microservice deployment without coupling to a specific provider or Kubernetes cluster. The experiments are conducted on a MacBook Pro (2023) equipped with an Apple M3 Pro CPU and 18 GB of RAM.

HTTP traffic is processed in two modes. In online mode, requests are submitted directly to the orchestrator endpoint/process (optionally with detailed output enabled). In log-replay mode, access-log lines are submitted to/replay_access_log, parsed, and replayed through the same processing path.

For each processed event, the pipeline exports structured results into CSV/XLSX reports (scores, risk level, topics, routing decision, and context fields). In parallel, the alerting component writes alerts and incidents into OpenSearch indices (alerting-*, incidents-*) for dashboard inspection.

4.2. Datasets and Scenario Generation

This section describes the datasets used to train and validate the ML and NLP components, as well as the scenario generation used for end-to-end evaluation. The goal is to ensure that evaluated requests reflect realistic HTTP payload structures and operational traffic characteristics, while enabling reproducible measurement of detection outcomes under fixed operating points.

4.2.1. Training Datasets

Model training relies on public datasets and semi-automatically labeled samples to cover benign behavior and multiple web-attack families.

Numerical ML branch.

The numerical anomaly models operate on numeric features extracted from HTTP access logs and request metadata and are designed to detect a broad spectrum of web-attack families, including SQL Injection, NoSQL Injection, LDAP Injection, Command Injection, XSS, SSRF, Cloud Metadata SSRF (IMDS), API Key Exposure, Credential Stuffing, WebSocket Abuse, and Business Logic Abuse. For supervised evaluation (validation/test), labeled attack samples are sourced from CSIC 2010 [37] and Attack Simulation Lab [38].

Textual NLP branch.

The NLP models are trained on payload-centric datasets containing HTTP request parameter values and request bodies, using HttpParamsDataset [39] (19,304 benign items, 11,763 anomalous items) and the Web Application Payloads dataset [40] (300 attack payload samples). These corpora are used to fit supervised text classifiers (TF-IDF + Logistic Regression and character TF-IDF + linear SGD) that predict a general “attack/anomalous vs. benign” label from textual HTTP fields. For reporting and to reduce optimistic bias, we apply a stratified 70/15/15 train/validation/test split over the combined NLP corpora, with payload-string de-duplication to reduce near-duplicate leakage across splits.

Fixed internal ruleset for silver-label generation.

To derive auxiliary “silver” labels (per-attack topic labels used for analysis and per-attack NLP training), we apply a fixed, versioned internal JSON ruleset (base_rules.json). The ruleset defines per-attack signature groups via (i) high-precision strong regular expressions and (ii) recall-oriented partial indicator token lists, together with normalization parameters (min_hits, partial_norm_divisor) and optional field scoping/rule-hit gating (match_fields, requires_rule_hit). The ruleset is held constant and is applied only to training/validation corpora.

Train/validation/test split and leakage prevention.

To prevent data leakage, we strictly separate (i) model fitting, (ii) operating-point (threshold) selection, and (iii) final testing, and we keep the synthetic OWASP stream outside the train/val/test protocol. The numerical ML anomaly models are fitted on a benign-only training split from the Web Server Access Logs-Labeled dataset [41] (entries 0–499,999). Operating-point calibration and threshold selection are performed exclusively on a disjoint labeled validation set composed of (a) Web Server Access Logs-Labeled entries 500,000–999,999 (benign), (b) Attack Simulation Lab subset A (250 k attack events; label = 1), and (c) a CSIC 2010 attack-only subset (10 k; label = 1). Final performance reporting uses a disjoint labeled test set that is not used for any thresholding or calibration decisions, consisting of Attack Simulation Lab subset B (10 k attack events; label = 1; disjoint from subset A) and a CSIC 2010 benign-only subset (15 k; label = 0), ensuring no sample reuse across splits. Any supervised calibration steps (e.g., mapping anomaly statistics to attack probability) and the recommended decision thresholds are derived from the validation set and then frozen before test evaluation. The internal rule-derived “silver” labels are generated only within the training/validation corpora using the fixed JSON ruleset and are not tuned on the test set or on the synthetic stream.

4.2.2. Evaluation Stream (Mixed Traffic) and Scenario Generator

End-to-end evaluation is performed on an independent mixed-traffic stream generated and replayed by a single scenario driver (owasp_top_10_smoke.py). This stream is used as a synthetic stress test of the full pipeline, and it is kept separate from the held-out test split used for final model reporting.

Attack events.

The generator produces HTTP requests covering the same OWASP-like topics as the ruleset (SQL Injection, NoSQL Injection, LDAP Injection, Command Injection, XSS, SSRF, Cloud Metadata SSRF (IMDS), API Key Exposure, Credential Stuffing, WebSocket Abuse, and Business Logic Abuse). Payload variants are emitted across multiple endpoints (e.g., /payments/charge, /auth/login, /metadata/fetch, /socket.io/, /cart/apply-coupon) to reduce endpoint-specific artifacts.

Benign events.

For benign background traffic, the generator loads and samples access-log entries from the Access Log dataset [42] are replayed under the same preprocessing and inference conditions as the attack subset.

The final mixed evaluation stream consists of N_total = 26,025 events, including N_attack = 1025 and N_benign = 25,000. Results from this stream are reported separately as a synthetic end-to-end stress test and are not used for threshold selection or calibration.

4.3. Evaluation Protocol and Metrics

Each processed HTTP event is assigned a discrete risk level from the ordered set: Normal, Low, Medium, High, Critical.

For evaluation, each event also has a ground-truth label, defined as the reference “true” class used for scoring. In this study, ground-truth is binary: events generated from the attack subset are labeled as attack, and events sampled from the benign access-log subset are labeled as benign.

To convert risk levels into a binary decision used for confusion-matrix reporting, two operating points are evaluated:

• Operating point A (Alert, Medium+): an event is predicted as an attack if $\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$∈ {Medium, High, Critical}.
• Operating point B (Suspicious, Low+): an event is predicted as an attack if ${\mathrm{r}\mathrm{i}\mathrm{s}\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$∈ {Low, Medium, High, Critical}.

For each operating point, the confusion-matrix counts are defined as follows:

• TP (true positives): ground-truth = attack and predicted = attack.
• FP (false positives): ground-truth = benign and predicted = attack.
• FN (false negatives): ground-truth = attack and predicted = benign.
• TN (true negatives): ground-truth = benign and predicted = benign.

From these counts, the reported detection metrics are computed:

• Precision = TP/(TP + FP)
• Recall (TPR) = TP/(TP + FN)
• F1-score = 2·Precision·Recall/(Precision + Recall)
• False Positive Rate (FPR) = FP/(FP + TN)

All metrics are computed on the full mixed-traffic stream and are reported for both operating points.

4.4. Mixed-Traffic Detection Results

Table 4. Mixed-traffic confusion matrix and detection metrics for two operating points (Medium+ and Low+).

Operating Point	Threshold Rule	Total (n)	Attack (n)	Benign (n)	TP	FP	FN	TN	Precision (%)	Recall (%)	F1 (%)	FPR (%)
A—Alert (Medium+)	$\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$ ∈ {Medium, High, Critical}	26,025	1025	25,000	1005	0	20	25,000	100.00	98.05	99.01	0.00
B—Suspicious (Low+)	$\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$ ∈ {Low, Medium, High, Critical}	26,025	1025	25,000	1024	18	1	24,982	98.27	99.90	99.08	0.07

reports the mixed-traffic detection results for the two operating points defined in Section 4.3. For each operating point, the table provides the confusion-matrix counts (TP, FP, FN, TN) on the full evaluation stream and the derived metrics (Precision, Recall, F1, and FPR).

At operating point A (Alert, Medium+), the pipeline achieves zero false positives on the benign subset (FP = 0, FPR = 0.00%) while maintaining a high detection of attacks (TP = 1005, FN = 20, Recall = 98.05%). This operating point prioritizes false-alarm suppression at the cost of a small number of missed attack events.

At operating point B (Suspicious, Low+), the detection of attacks increases (TP = 1024, FN = 1, Recall = 99.90%), while a limited number of benign events are flagged as suspicious (FP = 18, FPR = 0.07%). Figure 6 summarizes the trade-off between the two operating points in terms of Precision, Recall, F1, and FPR.

Potential false positives on complex legitimate traffic. The reported benign escalation (Medium+ = 0.00%, Low+ = 0.07%) is measured primarily on access-log-style corpora dominated by plain-text and query-like parameters. However, production API workloads may include large nested JSON bodies, Base64/JWT blobs, code-like strings inside user-generated content, debug traces, and rare but valid endpoints (exports/webhooks), which can trigger false positives. This limitation is addressed in future work by extending evaluation with JSON-heavy benign traces and adding payload-structure-aware handling.

4.5. Risk Stratification by Attack Topic

In addition to the binary mixed-traffic evaluation, the study analyzes risk stratification across attack topics, i.e., how detected events are distributed over the discrete risk levels—Normal, Low, Medium, High, Critical. This view complements Section 4.4 by characterizing the severity assignment per ground-truth attack class rather than only the binary decision outcomes.

Table 5. Risk level distribution by ground-truth class and operating-point rates (Medium+ and Low+).

Ground-Truth Class	Support (n)	Critical (n)	High (n)	Medium (n)	Low (n)	Normal (n)	Alert Rate @Medium+ (%)	Suspicious Rate @Low+ (%)
SQL Injection	225	190	35	0	0	0	100.00	100.00
NoSQL Injection	110	15	85	10	0	0	100.00	100.00
LDAP Injection	40	20	20	0	0	0	100.00	100.00
Command Injection	50	40	10	0	0	0	100.00	100.00
Cross-Site Scripting	70	38	20	12	0	0	100.00	100.00
SSRF	90	10	22	58	0	0	100.00	100.00
Cloud Metadata SSRF (IMDS)	10	7	3	0	0	0	100.00	100.00
API Key Exposure	30	10	20	0	0	0	100.00	100.00
Authentication Brute-Force	80	0	67	10	3	0	96.25	100.00
Credential Stuffing	50	40	0	10	0	0	100.00	100.00
IDOR	40	0	0	38	2	0	95.00	100.00
Misconfiguration	40	0	26	10	4	0	90.00	100.00
Data Exposure	50	20	10	10	10	0	80.00	100.00
DoS	90	37	28	24	0	1	98.88	98.88
WebSocket Abuse	20	0	12	8	0	0	100.00	100.00
Business Logic Abuse	30	0	30	0	0	0	100.00	100.00
Benign	25,000	0	0	0	18	24,982	0.00	0.07

reports the per-topic distribution of predicted risk levels for all attack classes, together with the corresponding Alert rate (Medium+) and Suspicious rate (Low+). Most attack topics are consistently assigned at least Medium risk, yielding Alert rate = 100.00% and Suspicious rate = 100.00% for SQL Injection, NoSQL Injection, LDAP Injection, Command Injection, Cross-Site Scripting (XSS), SSRF, Cloud Metadata SSRF (IMDS), API Key Exposure, Credential Stuffing, WebSocket Abuse, and Business Logic Abuse. Several topics exhibit partial down-shifts into the Low or Normal levels, including Authentication Brute-Force (Alert rate = 96.25%), IDOR (95.00%), Misconfiguration (90.00%), Data Exposure (80.00%), and DoS (98.88%, with a small Normal portion).

For benign traffic, Table 5 shows that almost all events are classified as Normal (24,982 of 25,000), with a small fraction assigned Low risk (18 of 25,000), resulting in Alert rate @Medium+ = 0.00% and Suspicious rate @Low+ = 0.07%. This indicates that the Low threshold can be used as a high-recall “suspicion” operating point while keeping benign escalation limited.

Figure 7 visualizes the risk level distribution by topic as a stacked representation, highlighting the concentration of attack events in the Medium/High/Critical levels for most classes. Figure 8 summarizes the Alert rate @Medium+ per topic to provide a compact overview of which classes are most likely to trigger an alert at the stricter operating point.

4.6. Comparison with Related Approaches

Table 6. Comparison with published approaches (reported metrics).

Study	Task/Input	Dataset/Traffic Composition	Decision Output	Precision (%)	Recall (%)	F1 (%)	FPR/False Alarm (%)	Notes on Protocol
Ours (Alert, Medium+)	Web API attack detection from HTTP requests and access logs	Training (ML): CSIC 2010; Attack Simulation Lab; internal rule-derived silver-labeled corpus (JSON ruleset). Training (NLP): HttpParamsDataset; Web Application Payloads Dataset; internal request corpus with silver labels. Evaluation (mixed stream): owasp_top_10_smoke.py attack subset (1025 events) + Web Server Access Logs-Labeled benign subset (25,000 events)—N_total = 26,025	$\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$ ∈ {Medium, High, Critical}	100	98.05	99.01	0	Mixed-traffic evaluation with explicit benign stream and FPR reporting
Ours (Suspicious, Low+)	Web API attack detection from HTTP requests and access logs	Training (ML): CSIC 2010; Attack Simulation Lab; internal rule-derived silver-labeled corpus (JSON ruleset). Training (NLP): HttpParamsDataset; Web Application Payloads Dataset; internal request corpus with silver labels. Evaluation (mixed stream): owasp_top_10_smoke.py attack subset (1025 events) + Web Server Access Logs-Labeled benign subset (25,000 events)—N_total = 26,025	$\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$ ∈ {Low, Medium, High, Critical}	98.27	99.9	99.08	0.07	Mixed-traffic evaluation with explicit benign stream and FPR reporting
Pham and Do (DL-WAD) [28]	Web attack detection from URL-form inputs	CSIC 2010 (single dataset test results in comparison with other models)	Binary classifier (normal vs. abnormal)	99.09	96.21	97.63	Not reported	Reported on CSIC 2010; protocol differs from mixed benign-stream evaluation
Ontology/KG approach [31]	Cloud resource query processing from natural-language queries	Simulated cloud environment and cloud resource ontologies	Ranked retrieval (search results)	92	87	89	Not reported	Retrieval task; includes query execution time (1.2 s)
Insider threat detection [32]	Text-based insider threat classification	Email/text insider setting (reported as “present study”)	Binary classification	92	100	95	Not reported	Different domain (insider/email); Accuracy = 92% is also reported

summarizes a structured comparison between the proposed pipeline and representative published approaches that report quantitative results on security-related classification or adjacent tasks. The comparison is provided in terms of the reported metrics (Precision, Recall, F1) and, where available, false-alarm characteristics. Because the considered studies use different datasets, traffic compositions, and decision outputs, the results are interpreted as reported-performance references rather than as a direct head-to-head benchmark.

For the proposed pipeline, Table 6 reports two operating points that map the five-level risk output (Normal, Low, Medium, High, Critical) to a binary decision. Under the Alert (Medium+) operating point, the system reaches Precision = 100.00%, Recall = 98.05%, F1 = 99.01%, and FPR = 0.00% on a mixed evaluation stream of 26,025 events (1025 attack events generated by owasp_top_10_smoke.py and 25,000 benign access-log events sampled from Web Server Access Logs-Labeled). Under the Suspicious (Low+) operating point, the system increases attack coverage to Recall = 99.90% with Precision = 98.27%, F1 = 99.08%, and a limited benign escalation of FPR = 0.07%. In both cases, model training combines numerical ML sources (CSIC 2010, Attack Simulation Lab, and a rule-derived silver-labeled corpus) with payload-centric NLP sources (HttpParamsDataset, Web Application Payloads Dataset, and silver-labeled internal request samples), reflecting a hybrid ML + NLP design with an explicit operating-point control.

Pham, V.H. and Do, T.T.H. [28] report an in-domain deep-learning approach for web-attack detection on CSIC 2010, with Precision = 99.09%, Recall = 96.21%, and F1 = 97.63% (Table 6). While these results are directly relevant as a web-attack baseline, the evaluation protocol differs from the mixed-traffic setting used in this study: DL-WAD is reported as a single-dataset test in comparison with other models and does not provide an explicit benign-stream false-alarm rate comparable to the FPR reported in Table 6. Consequently, the comparison is provided as a reported-metrics reference, and a strict head-to-head conclusion would require re-running both methods under the same dataset split and traffic composition.

The remaining two sources provide contextual baselines from adjacent problem settings rather than direct web-attack detection. The ontology/knowledge-graph approach [31] targets natural-language cloud resource query processing and reports retrieval-style metrics, which are not directly comparable to attack-versus-benign confusion-matrix outcomes. The insider threat detection study [32] reports strong classification performance on an email/text insider setting (Precision = 92.00%, Recall = 100.00%, F1 = 95.00%, Accuracy = 92.00%), but the input modality and threat model differ from HTTP/API attack detection. These results motivate the broader applicability of NLP and ML techniques in security analytics, while the primary quantitative baseline for web-attack detection remains DL-WAD due to task proximity.

4.7. Qualitative OWASP Smoke-Test and SOC Recommendations

In addition to the quantitative mixed-traffic evaluation (Section 4.4 and Section 4.5), we use the OWASP-like smoke-test as a qualitative case study to demonstrate how the pipeline produces auditable and actionable explanations for SOC workflows. For each processed event, the system returns a discrete risk level (Normal/Low/Medium/High/Critical), a set of detected topics (T), and an explanation object R that records the main evidence signals and the policy-selected response actions.

Table 7. Examples of topic-specific explanations and policy-selected actions recorded in the explanation object R.

Topic	Evidence (R)	Recommended Action
SQL Injection	SQL meta-characters and operator patterns in payload; database-related keyword fragments; high topic score	1. Temporarily block the IP/user 2. Review database logs for signs of exfiltration
NoSQL Injection	NoSQL operator patterns in payload; JSON-like fragments; query-operator tokens; high topic score	1. Block malicious IPs 2. Remove $where/operators from user input
LDAP Injection	LDAP filter syntax patterns; directory-query tokens; suspicious query structure; high topic score	1. Review LDAP logs 2. Restrict the service account privileges
Command Injection	Shell metacharacters; command chaining patterns; suspicious process-related tokens; high topic score	1. Inspect processes on the host 2. Look for suspicious shell sessions and outbound connections
Cross-Site Scripting (XSS)	Script/HTML injection markers; event-handler patterns; encoded tag fragments; high topic score	1. Block the vulnerable field 2. Enable output encoding and CSP
SSRF	URL targets pointing to internal hosts; unexpected outbound destination patterns; network-location indicators; high topic score	1. Restrict outbound destinations 2. Block access to internal IP ranges
Cloud Metadata SSRF (IMDS)	Requests targeting cloud instance metadata endpoints; link-local addressing patterns; metadata-path indicators; high-risk context	1. Review calls to IMDS 2. Rotate instance credentials if needed
API Key Exposure	Token/key-like substrings in request payload; secret-format patterns; leakage indicators; high topic score	1. Immediately rotate keys/tokens 2. Enable secret scanning in CI/CD
Authentication Brute-Force	Repeated authentication attempts; login endpoint targeting; rate anomalies; high topic score	1. Strengthen rate-limiting and lockout policies 2. Review successful logins from suspicious IPs
Credential Stuffing	Credential-pattern repetition; suspicious login bursts; leaked-credential indicators; high topic score	1. Check for use of leaked passwords 2. Enforce password reset/session revocation
Broken Access Control (IDOR)	Object identifier manipulation patterns; unauthorized resource access indicators; endpoint-context mismatch; high topic score	1. Assess which objects may have been accessed 2. Add authorization checks at the object level
Security Misconfiguration	Debug/test endpoint access; directory indexing patterns; default-credential indicators; high topic score	1. Disable debug/directory indexing 2. Remove default credentials and test endpoints
Sensitive Data Exposure	PII/credential-like substrings; accidental disclosure patterns; sensitive-field indicators; high topic score	1. Determine the leak type (PII/credentials) 2. Encrypt/mask sensitive fields in logs
Denial of Service (DoS)	High-rate request bursts; resource-intensive endpoint targeting; repeated expensive operations; high topic score	1. Tighten rate limiting 2. Add timeouts and limits for resource-intensive operations
WebSocket Abuse	Abnormal message frequency; WebSocket endpoint targeting; origin/auth anomalies; high topic score	1. Limit message frequency 2. Strengthen authentication and origin checks for WS endpoints
Business Logic Abuse	Business-rule manipulation indicators; coupon/refund misuse patterns; repeated transactional anomalies; high topic score	1. Temporarily restrict coupons/refunds 2. Add idempotency and server-side business rule checks

summarizes how the explanation object R is used in practice for representative attack topics.

For each topic, R captures compact evidence cues derived from request content and context (for example, injection meta-characters and operator patterns, metadata endpoint targeting, authentication bursts, or endpoint-context mismatches). Based on these signals, the policy layer attaches a small set of recommended SOC actions. For example, SQL Injection events include SQL operator patterns and database-related keyword fragments, which map to temporarily blocking the actor and reviewing database logs for signs of exfiltration. Cloud Metadata SSRF (IMDS) events contain metadata-path indicators and link-local addressing patterns, which map to reviewing IMDS access and rotating instance credentials. For authentication-driven threats such as Authentication Brute-Force and Credential Stuffing, repeated login attempts and rate anomalies map to rate limiting, lockout policies, and follow-up validation of suspicious successful logins. For access-control and configuration weaknesses, such as IDOR and Security Misconfiguration, endpoint-context mismatches or debug/default-credential indicators map to targeted remediation steps, such as authorization hardening and removal of unsafe defaults.

Overall, this qualitative view complements the mixed-traffic metrics by showing that alerts are not only detected but also delivered with topic-aligned evidence and response guidance, enabling rapid triage and consistent first-response actions.

4.8. Dashboards and Incident Aggregation

The pipeline integrates with OpenSearch to support operational triage and investigation. For each processed HTTP event that crosses the selected operating point, the alerting component writes a structured alert document into the alerting-* indices.

Figure 9 illustrates the alert dashboard: the upper table provides per-event context fields (context.ts, context.endpoint, context.method, context.source_ip) together with the predicted risk level and the leading topic score (context.topics.score). The summary panels (“Attacks by Topic” and “Total Attacks (over time)”) provide a compact view of topic distribution and temporal concentration of suspicious activity.

To reduce alert fatigue and provide investigation-friendly entities, the pipeline also performs incident aggregation and stores aggregated records in the incidents-* indices. As shown in Figure 10, each incident represents a grouped security case with a dominant topic, the aggregated $\mathrm{r}\mathrm{i}\mathrm{s}{\mathrm{k}}_{\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}}$, a human-readable title, affected labels (labels.endpoint, labels.method, labels.source_ip), the final_score, and a short list of reasons supporting the escalation.

This separation between event-level alerts and incident-level summaries enables a workflow where analysts review fine-grained evidence when needed, while primarily operating on consolidated cases for faster triage.

4.9. Performance and Latency

Latency is defined as the end-to-end processing time required to ingest, preprocess, score (ML/NLP), fuse, and export a single HTTP event through the pipeline. Throughput is defined as the number of HTTP events processed per second under a fixed configuration.

Performance is measured using the same mixed-traffic stream of 26,025 events and three execution modes: (i) online processing with detailed JSON output exported to an XLSX report, (ii) access-log replay with detailed result output, and (iii) access-log replay with simplified output and concurrency enabled (concurrency = 20).

Table 8. Latency and throughput measurements for the containerized pipeline in the experimental setup.

Scenario	Events (n)	Total Time (s)	Avg Time per Event (ms)	Throughput (Events/s)
OWASP smoke test with detailed JSON output in XLSX report	26,025	2016.884	77.5	12.9
Access-log replay with detailed result output	26,025	2081.354	79.9	12.5
Access-log replay with simplified output, concurrency = 20	26,025	649.664	24.9	40.1

summarizes the total processing time and the average time per event for each mode.

The results show that the detailed modes operate at approximately 77–80 ms per event, while enabling concurrent log replay with simplified output reduces the average time to 24.9 ms per event and increases throughput. This reflects expected overhead from detailed serialization, logging, and report generation in the detailed modes, and improved pipeline utilization under controlled concurrency in the simplified replay mode.

5. Conclusions

In this work, we propose and implement a final HTTP/API protection pipeline that combines three layers of analysis, including numerical ML, textual NLP, and risk policy with hysteresis of decisions. An API event is described by a single model in the form of a feature vector ${\mathrm{x}}_{\mathrm{n}\mathrm{u}\mathrm{m}}$, a text representation ${\mathrm{x}}_{\mathrm{t}\mathrm{e}\mathrm{x}\mathrm{t}}$, a risk context $\mathrm{c}$, and a function $\mathrm{F}\left(\mathrm{e}\right)$ that returns an integral score, risk level, and attack topic. All the services in the pipeline work with the same entities and can evolve independently of each other.

A key difference between the proposed approach and typical WAF/WAAP solutions is the combination of multiple signal sources. The ML branch works with aggregated numerical features (URI length, path depth, header count, header entropy, query-parameter count, payload size, suspicious-character ratio, JSON-payload flag, HTTP-method encoding, private-IP indicators, and request rate). The NLP branch analyzes URIs, headers, and request bodies using rules, TF-IDF, and character n-gram models. Additionally, a risk policy is in place that takes into account the environment, endpoint class, data type, service exposure, and likely attack class. As a result, the system does not simply mark a request as anomalous. Rather, it returns the results of an analysis of suspicious activity such as SQL Injection, Cloud Metadata SSRF, or Business Logic Abuse, along with a set of recommended actions for the SOC.

Another unique feature is the training database on which the pipeline is built. The models are trained on a combination of public datasets (CSIC 2010 Web Application Attacks, Attack Simulation Lab, HttpParamsDataset, Web Application Payloads, Web Server Access Logs-Labeled and Access Log datasets) and internal silver-label samples ml_rules_silver and nlp_train_silver. We are not confined to classic SQLi/XSS, but confidently work with scenarios such as access to metadata services, key leaks, Credential Stuffing, Business Logic Abuse, and WebSocket channels. In fact, the training data already reflects the types of attacks that the SOC team encounters in their daily work.

Unlike a number of works that propose general-purpose deep models for analyzing web attacks, we deliberately chose a combination of classic ML models and lightweight NLP classifiers. For HTTP/API traffic with limited message length and well-structured features, this offers several practical advantages, such as the transparent interpretation of decisions, low processing latency, no dependence on GPU infrastructure, and a simpler retraining process in the operational environment.

The experimental results on OWASP-like scenarios show that even without deep networks, the pipeline consistently detects classic injections, SSRF to metadata services, key leaks, and Business Logic Abuse, assigning them mostly high/critical risk levels. This makes it possible to present the proposed solution as a functional WAAP layer with a reasonable trade-off between the quality of detection, explanation, and resource costs.

Equally significant are the results regarding performance. In the detailed mode with full JSON output and report generation, the average delay is tens of milliseconds per event. Moreover, in the parallel access log processing mode, the throughput increases to several tens of events per second on a single node.

In conclusion, the work presents a comprehensive solution from a formal event model and a combined ML/NLP pipeline to a containerized prototype. All this makes our solution suitable for further academic research and as a basis for integration into real cloud API security environments.

6. Future Work

Future work should go beyond the controlled test bench. To begin with, a long-term validation on real business service traffic in different domains (finance, e-commerce, B2B integrations) is crucial to adapt the risk policy to specific business processes and understand the real balance between missed attacks and background noise. The automation of the feedback and deployment needs to be improved. Marked incidents from OpenSearch should automatically be included in the updated ml_rules_silver and nlp_train_silver, trigger retrain processes, and safely deploy new model versions. Therefore, it is logical to strengthen the NLP component with compact transformer models pre-trained on HTTP logs and vulnerability descriptions, as well as to explore few-shot and continual learning to support new classes of attacks without completely retraining the entire pipeline.

Additionally, validation should include benign but complex API payloads that are underrepresented in public access log datasets. These payloads should include JSON-heavy traces with deeply nested objects, high-entropy Base64/JWT fields, and debug-like bodies. To further reduce false positives for this type of traffic, features that are aware of payload structure and entropy can be introduced alongside per-endpoint adaptive calibration.

Consider an empirical refinement of the risk policy parameters based on historical incidents and feedback from the SOC team so that the proportion of alerts with high/critical levels for various classes of threats corresponds to the risk portfolio that the organization finds acceptable.