GraphFaaS: Serverless GNN Intrusion Detection
- GraphFaaS is a serverless architecture that employs GNNs for provenance-based intrusion detection by transforming audit logs into dynamic, causal graphs.
- It leverages temporal locality, best-fit graph partitioning, and vertical scaling to efficiently handle bursty, unpredictable workloads.
- The system reduces detection latency by up to 85% and variability by 64%, ensuring real-time responsiveness in operational environments.
GraphFaaS is a serverless architecture for GNN-based intrusion detection that targets provenance-based intrusion detection systems (PIDS), in which raw audit logs are transformed into directed provenance graphs whose nodes represent system entities and whose edges represent system events and interactions. In this setting, Graph Neural Networks (GNNs) are used to exploit contextual, relational, and causal structure for anomaly detection, but conventional statically provisioned inference architectures are described as poorly matched to the latency-sensitive, highly bursty, irregular, and unpredictable workload profile of operational intrusion detection. GraphFaaS addresses this mismatch by using Function-as-a-Service elasticity to parallelize and dynamically scale graph construction, node-level embedding, and GNN inference, with the stated goal of reducing redundant computation, keeping latency low and stable, and maintaining real-time responsiveness under fluctuating load (Wang et al., 13 Nov 2025).
1. Provenance-based intrusion detection as the application context
The system is situated in provenance-based intrusion detection, where raw audit logs are converted into provenance graphs that evolve over time. In these graphs, nodes represent entities such as processes, files, sockets, pipes, memory objects, and network endpoints, while edges represent events and interactions such as file reads and writes, process creation, or network connections. The graphs are directed and provide a causal record of system activity, which is useful because attacks typically manifest as multi-step causal traces rather than isolated events (Wang et al., 13 Nov 2025).
The paper emphasizes three reasons for adopting provenance-based detection. First, attack behavior is contextual and relational: actions that appear benign in isolation may become suspicious when interpreted through graph structure. Second, causality matters: provenance graphs preserve “who caused what,” supporting both detection and forensics. Third, temporal locality is significant: many graph regions change slowly, creating opportunities to reuse prior graph state and reduce repeated computation. A typical PIDS pipeline in the paper consists of log ingestion and graph construction, node textual attribute embedding, GNN message passing, and a downstream scoring, clustering, or thresholding stage for anomaly detection.
This framing places GraphFaaS in a line of work where the central computational object is not an independent event stream but an incrementally changing graph. A plausible implication is that the runtime architecture is as important as the learning model when operational requirements emphasize bounded response time rather than offline throughput alone.
2. Motivation: latency sensitivity, burstiness, and the limits of static provisioning
The paper argues that traditional statically provisioned GNN inference systems are a poor fit for intrusion detection because they assume fairly stable resources, whereas IDS workloads are latency sensitive and highly bursty. Low latency is treated as operationally necessary: if inference is slow, the system may miss the narrow window in which mitigation is still possible, allowing attacks to progress further, evidence to be lost or overwritten, and real-time response to become ineffective (Wang et al., 13 Nov 2025).
The workload is described as irregular and unpredictable because malicious events are rare and sporadic, while graph analysis demand rises sharply only when certain streams of logs or attack-related activity arrive. Under these conditions, static provisioning introduces a familiar but acute tradeoff. A system may overprovision to survive spikes, thereby wasting resources most of the time, or underprovision and incur latency spikes during bursts. For GNN-based PIDS, the paper treats this tradeoff as especially problematic because inference latency must remain not only low but also stable.
GraphFaaS is presented as a response to that systems problem rather than as a change to the underlying detector. The paper states that the detection model is unchanged relative to the baseline system Flash, and that detection accuracy remains the same; the principal difference lies in the runtime architecture and its handling of workload variability. This directly addresses a common misconception that the reported gains derive from a more accurate model. In the reported design, the gains concern inference latency and latency variability, not a different detection objective.
3. Architecture and graph construction strategy
GraphFaaS is organized into three main components: graph construction, serverless node-level embedding, and serverless GNN inference (Wang et al., 13 Nov 2025). The architecture is designed to exploit elasticity while avoiding unnecessary recomputation.
In graph construction, the system starts from the log stream and builds a provenance graph, but it does not recompute the entire graph at every detection interval. Instead, it exploits temporal locality by keeping only parts that changed and retaining nodes within a $2K$-hop neighborhood of active nodes, where is the number of GNN layers. The paper also describes optional frequency-based filtering: rare nodes and edges and their $2K$-hop neighborhoods can be retained because rare patterns are often more suspicious and more informative. The result is a smaller filtered subgraph that can then be divided into parallel subtasks.
The stated rationale for the $2K$-hop neighborhood is tied to message passing depth. For a -layer GNN, information can propagate across hops during inference; using a $2K$-hop neighborhood is intended to preserve enough context for message passing while trimming irrelevant regions. This suggests that GraphFaaS treats graph reduction not as arbitrary sampling but as a locality-preserving preprocessing step aligned with model depth.
A second misconception addressed implicitly by this design is that serverless deployment alone would be sufficient. The paper instead presents graph filtering and state reuse as integral components of the system. In that sense, GraphFaaS is not merely “GNN inference on FaaS,” but a pipeline redesign that couples graph-structural reduction with elastic execution.
4. Serverless execution model for embeddings and GNN inference
The node embedding stage transforms textual node attributes into vector features. The paper gives examples including process names, command lines, file paths, IP addresses, and ports. Because these embeddings are independent per node, GraphFaaS parallelizes them naturally using serverless functions (Wang et al., 13 Nov 2025).
A practical issue identified in the paper is that embedding time depends on string length. GraphFaaS therefore partitions the embedding workload by feature length: shorter strings can be grouped together, while longer strings are processed separately. The stated purpose is to improve balance and avoid the overhead of launching too many tiny tasks. The paper explicitly notes a tradeoff between finer-grained parallelism and networking or packet-processing overhead, so the system does not simply maximize the number of functions; rather, it attempts to keep each function under a latency bound while avoiding fragmentation.
For the GNN inference stage, latency is described as being driven mainly by graph size and the amount of message passing needed, since the model is fixed at inference time. GraphFaaS therefore partitions large provenance graphs into subgraphs close to a target size. The paper uses a greedy best-fit algorithm to pack graph neighborhoods into clusters or subgraphs with three objectives: keeping each subgraph within a predefined capacity, minimizing the number of subgraphs, and reducing waste from too many tiny functions.
The appendix formulation is expressed in bin-packing terms. For a cluster , if the current node set is and the current edge count is , then adding a new vertex 0 incurs
1
This 2 is compared to the remaining capacity of the cluster; if the vertex fits, it is inserted, and otherwise a new cluster is created. The appendix also presents a First-Fit Decreasing bin-packing variant, but the main idea remains efficient packing of neighborhoods while controlling subgraph size.
The paper identifies dependency explosion as a crucial challenge. A super-node or a dense local region may make even the smallest useful subgraph too large for a normal function instance. In those cases, GraphFaaS uses vertical scaling rather than further horizontal splitting, allocating more resources to the same function instance, such as more CPU cores or memory. This vertical scaling fallback is reserved for pathological cases where horizontal scaling alone is insufficient.
5. Latency stabilization mechanisms and reported evaluation
GraphFaaS is designed around the observation that serverless platforms can scale on demand. Under bursty arrivals, the system splits the workload into more execution units, the serverless platform automatically launches more instances, and parallel processing absorbs the burst. When workload is low, the platform scales down, idle resources are released, and costs are reduced. The paper presents this elasticity as the main mechanism for burst resilience (Wang et al., 13 Nov 2025).
The paper attributes latency stabilization to five mechanisms: smaller bounded execution units, load-aware partitioning, automatic elastic scaling, best-fit packing, and vertical scaling fallback. The intended effect is not only lower average latency but also lower variance, which the paper treats as critical for real-time intrusion detection.
The implementation and experimental setup are specified as follows. GraphFaaS was implemented in Python on OpenFaaS. The baseline system Flash was reimplemented to use the same server-client detection model, and for fairness Flash was deployed in a Docker container simulating a statically provisioned environment. The dataset was DARPA TC Engagement 3, containing 11 days of audit logs and 4 attack campaigns.
The reported metrics are latency, standard deviation, and coefficient of variation (CV), with
3
where 4 is the standard deviation and 5 is the mean. CV is used to quantify relative variability in detection latency over time.
| System | Mean latency | CV |
|---|---|---|
| GraphFaaS | 6 s | 7 |
| Baseline | 8 s | 9 |
The paper reports that GraphFaaS reduces average detection latency by 85% and CV by 64% compared to the baseline. It also states that this corresponds to about a $2K$0 reduction in average latency relative to Flash. GraphFaaS has mean latency $2K$1 s, standard deviation $2K$2, and $2K$3, while the baseline has mean latency $2K$4 s and $2K$5. The paper further notes that GraphFaaS maintains low latency during sudden surges in demand and that latency never exceeded 10 seconds, despite occasional spikes. Because the detection model itself is unchanged, the paper states that detection accuracy remains the same as Flash.
These results are framed as preliminary. Within that framing, the emphasis on CV is notable: the system is presented not merely as faster on average, but as more predictable under bursty load. For operational intrusion detection, the paper treats this predictability as central rather than secondary.
6. Limitations, interpretation, and significance
The paper identifies several open challenges. Dependency explosion remains difficult: super-nodes and dense local structures can still dominate latency. Dynamic graph scaling remains hard because attack-driven changes in provenance graph size are not fully controlled by the current design. The paper also raises adaptive model depth as a future direction, suggesting that later systems may need to change the number of GNN layers dynamically depending on the graph and workload. Finally, the evaluation is limited to preliminary results on DARPA TC Engagement 3 and one main baseline (Wang et al., 13 Nov 2025).
These limitations delimit the scope of the claims. GraphFaaS is not presented as a general proof that all GNN inference workloads are naturally serverless, nor as a complete solution to dynamic graph pathologies. Instead, the paper’s main insight is narrower and more specific: serverless elasticity is a natural fit for bursty IDS inference when combined with graph-level partitioning, temporal-locality-aware filtering, and mechanisms for handling oversized subgraphs.
The work also has a broader operational interpretation. The paper suggests that faster detection can support quicker containment, lower variance can support more dependable incident response, and serverless scaling can reduce the need to keep large idle detection clusters on standby. In practical terms, this could help security operations centers and automated defense systems respond more quickly to lateral movement, suspicious process trees, unusual file or network activity, and multi-stage APT behavior. A plausible implication is that near-real-time provenance analysis becomes more deployable when the inference architecture is designed for bursty, event-driven workloads rather than static benchmarks alone.
Within provenance-based intrusion detection, GraphFaaS is therefore significant less for altering the semantics of detection than for reorganizing the inference pipeline around burst resilience and latency stability. The paper’s central contribution is the claim that GNN-based provenance detectors can be adapted to serverless execution without changing the underlying detection model, while achieving markedly lower mean latency and lower relative variability under the evaluated workload.
