AntiFLipper: FL Defense Against Label-Flipping

• AntiFLipper is a defense mechanism against label-flipping attacks in federated learning, using client-side evaluation to detect malicious behavior.
• It distributes tasks between clients and server, employing trust inference and weighted aggregation to ensure efficient, secure updates in resource-constrained environments.
• Experimental results show comparable accuracy to state-of-the-art methods with significantly reduced server aggregation time, demonstrating its practical robustness.

AntiFLipper is a defense mechanism against label-flipping attacks in federated learning (FL), introduced as a secure and computationally efficient method for multi-class label-flipping scenarios. Its central design choice is to move attack detection toward the client side: clients evaluate the received global model on their own local data and report those evaluation scores together with their model updates, while the server infers trust, filters anomalous participants, and performs trust-weighted aggregation. The method is positioned for resource-constrained FL deployments, where preserving model integrity and limiting server-side aggregation cost are simultaneous requirements (Rahman et al., 26 Sep 2025).

1. Threat model and operating principle

Federated learning enables privacy-preserving model training by keeping data decentralized, but it remains vulnerable to label-flipping attacks, where malicious clients manipulate labels to poison the global model. In the AntiFLipper setting, these attacks may be constant or dynamic, and the experiments consider multiple flipped pairs in labels under both IID and non-IID data partitions. The paper evaluates settings with 100 clients and up to 40% malicious participants, which it identifies as the theoretical limit for robust aggregation (Rahman et al., 26 Sep 2025).

The method is based on a simple behavioral asymmetry. If a client flips its local labels, then the global model, which is shaped mostly by honest data, will perform poorly on the poisoned local data. Consequently, the accuracy of the global model evaluated on a malicious client’s local dataset is expected to be significantly lower than the corresponding accuracies reported by honest clients. AntiFLipper uses that deviation in reported local evaluation accuracy as its primary detection signal rather than relying on gradient similarity, clustering of model updates, or high-dimensional robust statistics (Rahman et al., 26 Sep 2025).

This design places AntiFLipper within the broader class of targeted-poisoning defenses in FL, but with a distinct detection proxy: local performance inconsistency under the current global model. This suggests a shift from geometry-based anomaly detection toward behavior-based telemetry.

2. System architecture and round-level workflow

AntiFLipper is organized into five modules, denoted M1 through M5. These modules distribute the computational burden between clients and server so that the server performs lightweight trust management and aggregation, while the heavier evaluation step is executed locally by clients (Rahman et al., 26 Sep 2025).

Module	Function
M1: Local Evaluation Feedback	Clients evaluate the received global model on their own local data and report model accuracy with the trained update
M2: Trust Inference	The server adjusts each client’s trust score based on the deviation of reported accuracy from the mean
M3: Behavior Profiling	The server tracks the history of client trust values or flags over rounds
M4: Anomaly-Guided Filtering	Persistently deviating clients are filtered and eventually blacklisted
M5: Weighted Aggregation	The server aggregates client models with weights proportional to current trust scores

At the client side, the round logic is: receive the global model, evaluate its accuracy on local data, locally train an updated model, and return both the updated model and the measured accuracy to the server. At the server side, the process is: receive local models and accuracy scores, compute average accuracy across clients, update trust scores, track flags for low-trust clients, exclude clients after repeated offenses, and aggregate the remaining models using trust-based weights (Rahman et al., 26 Sep 2025).

The workflow is notable because the detection signal is obtained before aggregation and does not require the server to inspect parameter geometry in detail. A plausible implication is that AntiFLipper is particularly suited to deployments where server-side memory bandwidth or aggregation latency is the dominant systems constraint.

3. Trust inference, blacklisting, and aggregation

The trust mechanism is the mathematical core of AntiFLipper. Let $acc_{ij}$ denote the accuracy of the current global model on client $j$’s local data at round $i$, and let $acc_{avg}$ denote the average accuracy over non-malicious clients. The server computes the squared deviation

$d \leftarrow (acc_{ij} - acc_{avg})^2$

and updates the trust score $\tau_j$ using a quadratic penalty or reward: $$\tau_j \leftarrow \begin{cases} \tau_j - \alpha d & \text{if } acc_{ij} < acc_{avg} \ \tau_j + \alpha d & \text{otherwise} \end{cases}$$ where $\alpha$ is a learning rate-like parameter for trust adjustment (Rahman et al., 26 Sep 2025).

Malicious-client detection is based on repeated low trust. If

$\tau_j \leq \tau_{\text{threshold}} = \frac{1}{kn}$

for $cnt_{\max}$ rounds, client $j$0 is marked as malicious and excluded from subsequent aggregation. The next global model is then formed by trust-weighted aggregation over the remaining clients: $j$1 where $j$2 is client $j$3’s model at round $j$4 (Rahman et al., 26 Sep 2025).

The paper further states three theoretical guarantees. First, malicious clients have persistently lower global-model accuracy on their poisoned data, and the quadratic trust update penalizes this behavior quickly even in the presence of noise or moderate label skew on honest nodes. Second, trust values normalize each round, so honest clients dominate aggregation as adversaries are removed. Third, blacklisting thresholds are proportional to the number of clients, and persistent poor performance leads to exclusion (Rahman et al., 26 Sep 2025).

4. Computational profile and suitability for constrained deployments

A major claim of AntiFLipper is that it balances security and efficiency by relocating the most informative auxiliary computation to the client side. The server computation is reduced to calculating a mean, applying a quadratic penalty or reward, maintaining trust histories and flags, and performing weighted aggregation. In contrast, the paper characterizes prior defenses such as FoolsGold, FLAME, MKRUM, and LFighter as requiring clustering, similarity matrices, or robust statistics, all of which place substantially greater burden on the server (Rahman et al., 26 Sep 2025).

The client-side overhead is explicitly quantified. If each client trains for $j$5 local epochs, evaluates on a fraction $j$6 of its data, and each forward pass has cost $j$7, then training cost is $j$8, evaluation cost is $j$9, and the relative overhead is

$i$0

With $i$1 and $i$2, the paper reports an overhead of $i$3 (Rahman et al., 26 Sep 2025).

This overhead estimate is important because it formalizes the paper’s systems argument: the defense adds only forward-pass evaluation on the client and lightweight bookkeeping on the server. The paper also states that evaluation can be performed on all or just a fraction of local data with little accuracy drop, which creates a tunable tradeoff between local cost and detection fidelity. In deployment terms, AntiFLipper is described as suitable for mobile, IoT, or edge FL environments where round latency and server resource usage are operational bottlenecks (Rahman et al., 26 Sep 2025).

5. Experimental evaluation and quantitative results

The empirical study uses MNIST and CIFAR-10. For MNIST, the model is a 2-layer CNN with 2 fully connected layers; for CIFAR-10, the evaluated architectures are ResNet-18 and ShuffleNetV2. Data are partitioned under both IID and non-IID conditions, with the non-IID case implemented using a Dirichlet split with $i$4. The training setup uses 200 rounds for MNIST, 100 rounds for CIFAR-10, 3 local epochs per round, and batch sizes 64 and 32 respectively. Hardware is reported as an i9-12900K, 128GB RAM, and an NVIDIA RTX 3090. The evaluation metrics are Global Accuracy, Test Error, and server-side Aggregation Time (Rahman et al., 26 Sep 2025).

On MNIST under IID partitioning, AntiFLipper achieves $i$5 accuracy with $i$6 ms aggregation time. In the same setting, FLAME reports $i$7 accuracy with $i$8 ms aggregation time, LFighter reports $i$9 with $acc_{avg}$0 ms, MKRUM reports $acc_{avg}$1 with $acc_{avg}$2 ms, Median reports $acc_{avg}$3 with $acc_{avg}$4 ms, FedAvg reports $acc_{avg}$5 with $acc_{avg}$6 ms, and FoolsGold reports $acc_{avg}$7 with $acc_{avg}$8 ms. On CIFAR-10 under IID partitioning, AntiFLipper achieves $acc_{avg}$9 accuracy with $d \leftarrow (acc_{ij} - acc_{avg})^2$0 ms aggregation time, compared with FLAME at $d \leftarrow (acc_{ij} - acc_{avg})^2$1 and $d \leftarrow (acc_{ij} - acc_{avg})^2$2 ms, LFighter at $d \leftarrow (acc_{ij} - acc_{avg})^2$3 and $d \leftarrow (acc_{ij} - acc_{avg})^2$4 ms, FedAvg at $d \leftarrow (acc_{ij} - acc_{avg})^2$5 and $d \leftarrow (acc_{ij} - acc_{avg})^2$6 ms, MKRUM at $d \leftarrow (acc_{ij} - acc_{avg})^2$7 and $d \leftarrow (acc_{ij} - acc_{avg})^2$8 ms, Median at $d \leftarrow (acc_{ij} - acc_{avg})^2$9 and $\tau_j$0 ms, and FoolsGold at $\tau_j$1 and $\tau_j$2 ms (Rahman et al., 26 Sep 2025).

The paper summarizes these outcomes in two ways. First, AntiFLipper achieves accuracy comparable to state-of-the-art defenses on both easier and harder tasks. Second, its aggregation time is substantially smaller, with the paper characterizing the CIFAR-10 savings as roughly $\tau_j$3–$\tau_j$4 faster than FLAME and LFighter on harder tasks. It also reports that local evaluation on only $\tau_j$5 of client data retains detection accuracy with approximately $\tau_j$6 client-side cost overhead, and that the method remains effective against delayed and intermittent attacks (Rahman et al., 26 Sep 2025).

6. Relation to prior defenses and research context

AntiFLipper belongs to an active line of work on label-flipping and targeted-poisoning defenses in federated learning, but it differs sharply in where it places the detection logic. Earlier FL defenses against label-flipping identified discriminative structure in output-layer gradients. One method dynamically extracted gradients corresponding to source and target output neurons, then clustered and filtered suspicious clients before FedAvg aggregation, achieving lower test error, higher overall accuracy, higher source class accuracy, lower attack success rate, and higher source class accuracy stability across IID and non-IID settings (Jebreel et al., 2022). FL-Defender similarly exploited last-layer gradients, using worker-wise angle similarity, PCA compression of similarity vectors, and deviation-from-centroid re-weighting to defend against label-flipping and backdoor attacks while maintaining main-task performance and minimal server overhead (Jebreel et al., 2022).

Outside the FL setting, label-flipping defenses have also been framed as data sanitization. A classical example is k-NN-based label sanitization, where suspicious points are relabeled if the neighborhood confidence exceeds a threshold, mitigating poisoning by exploiting local label homogeneity (Paudice et al., 2018). AntiFLipper does not sanitize data or cluster gradients; instead, it treats client-reported evaluation accuracy as the key observable and uses trust dynamics to control aggregation (Rahman et al., 26 Sep 2025).

Against this background, AntiFLipper can be read as a systems-oriented reformulation of the defense problem. Gradient-clustering methods are optimized for attack-discriminative feature engineering at the server; AntiFLipper is optimized for low server burden while preserving robust accuracy under IID and non-IID distributions. A plausible implication is that these approaches are complementary rather than mutually exclusive: AntiFLipper addresses the operational efficiency gap emphasized in resource-constrained FL deployments, whereas gradient-centric methods emphasize richer geometric evidence for attack detection.