AutoAttack is a standardized evaluation protocol that combines four complementary adversarial attacks—two white-box parameter-free variants of APGD (one targeting cross-entropy loss, the other targeting the DLR loss), a white-box FAB attack, and a black-box Square Attack—into a single, computationally efficient ensemble. By removing the need for hyperparameter tuning and step-size scheduling, it provides a reproducible, worst-case estimate of a model's empirical robustness against Lp-norm bounded perturbations.
Glossary
AutoAttack

What is AutoAttack?
AutoAttack is a standardized, parameter-free ensemble of diverse white-box and black-box attacks used as a reliable benchmark for evaluating a model's empirical adversarial robustness.
Widely adopted as the default metric on the RobustBench leaderboard, AutoAttack addresses the common failure mode of gradient masking defenses that fool weaker, single-attack evaluations. Its sequential application of attacks with automatic step-size control ensures that if any vulnerability exists within the defined threat model, the ensemble is highly likely to find it, making it the de facto standard for comparing adversarial training methods and certified robustness claims.
Key Features of AutoAttack
AutoAttack is a parameter-free, ensemble attack method that combines diverse white-box and black-box attacks to provide a reliable, standardized evaluation of a model's empirical adversarial robustness.
Parameter-Free Ensemble Design
AutoAttack eliminates the need for manual hyperparameter tuning by combining four diverse attacks: two white-box attacks (APGD-CE and APGD-DLR) and two black-box attacks (FAB and Square Attack). This ensemble automatically adapts to the defense, preventing gradient masking from fooling the evaluation. The parameter-free nature ensures reproducible and comparable results across different models and defenses, making it the standard for RobustBench leaderboard evaluations.
Auto-PGD (APGD) Variants
The core white-box component uses Auto-PGD, an improved Projected Gradient Descent that automatically adjusts the step size during the attack. It comes in two loss variants:
- APGD-CE: Uses cross-entropy loss, effective against standard models
- APGD-DLR: Uses the Difference of Logits Ratio loss, specifically designed to bypass defenses that rely on logit masking or label smoothing Both variants incorporate a momentum term and restart mechanism to escape local optima.
FAB Attack Integration
The Fast Adaptive Boundary (FAB) attack is a white-box method that minimizes the Lp norm of perturbations by iteratively projecting adversarial examples onto the decision boundary. In AutoAttack, FAB is used to generate minimally perturbed adversarial examples, complementing the fixed-epsilon APGD attacks. This combination ensures that defenses relying on obfuscated gradients or non-smooth loss surfaces are reliably evaluated and not incorrectly labeled as robust.
Square Attack for Black-Box Evaluation
The Square Attack is a query-efficient, score-based black-box attack that requires only the model's predicted class probabilities. It iteratively selects random square-shaped perturbations and accepts updates that improve the attack objective. Unlike gradient-based methods, Square Attack is immune to gradient masking defenses, making it essential for detecting false robustness claims. Its inclusion ensures AutoAttack evaluates true empirical robustness, not just gradient obfuscation.
Standardized Robustness Benchmarking
AutoAttack is the default evaluation protocol for RobustBench, the leading benchmark for adversarial robustness. It provides:
- Reproducible evaluations with fixed attack parameters
- Threat model specification using L-infinity or L2 norm constraints
- Reliable ranking of defenses by measuring robust accuracy under the ensemble This standardization has exposed numerous defenses that relied on gradient masking rather than true robustness, advancing the field toward verifiable security claims.
Threat Model and Norm Constraints
AutoAttack operates under a defined threat model with specific perturbation constraints:
- L-infinity norm: Bounded pixel-wise perturbations (e.g., epsilon = 8/255)
- L2 norm: Bounded Euclidean distance perturbations
- Standard version: Combines APGD-CE, APGD-DLR, FAB, and Square Attack
- Rand version: Adds random restarts for stronger evaluation The choice of norm and epsilon defines the adversarial budget, and AutoAttack provides a reliable lower bound on model robustness within these constraints.
Frequently Asked Questions
Clear, technical answers to the most common questions about the AutoAttack benchmark, its mechanisms, and its role in evaluating adversarial robustness.
AutoAttack is a parameter-free, standardized ensemble of adversarial attacks used as a reliable benchmark for evaluating a model's empirical adversarial robustness. It works by sequentially executing a diverse set of four attacks—two white-box and two black-box—against a target model without requiring manual hyperparameter tuning. The ensemble includes an APGD (Auto-PGD) attack on the cross-entropy loss, an APGD attack on the DLR (Difference of Logits Ratio) loss, a FAB (Fast Adaptive Boundary) attack, and a Square Attack. By combining these complementary methods, AutoAttack provides a more thorough and trustworthy robustness evaluation than any single attack, eliminating the common pitfall of gradient masking defenses that appear robust against weak attacks but fail under stronger, diverse ones.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Understanding AutoAttack requires familiarity with the broader landscape of adversarial attacks, defenses, and evaluation benchmarks that define modern model security.
Projected Gradient Descent (PGD) Attack
The iterative white-box attack that forms the backbone of AutoAttack's APGD component. PGD takes multiple gradient steps, each time projecting the perturbed input back onto an epsilon-ball around the original sample.
- Key mechanism: Iterative FGSM with projection
- Standard steps: 20–100 iterations
- Norm constraint: Typically L-infinity
- Role in AutoAttack: APGD-CE and APGD-DLR are momentum-accelerated variants
Adversarial Training
The primary defensive methodology against gradient-based attacks like those in AutoAttack. During training, adversarial examples are generated on-the-fly and added to the minibatch, forcing the model to learn a robust decision boundary.
- Standard approach: PGD-based adversarial training
- Trade-off: Clean accuracy often decreases
- Evaluation: AutoAttack is the de facto standard for measuring success
- Key insight: Defenses not evaluated with AutoAttack often exhibit gradient masking
Gradient Masking
A brittle defense phenomenon where a model's gradients are intentionally or unintentionally obfuscated, causing gradient-based attacks to fail. AutoAttack's ensemble approach explicitly counters this by including black-box attacks like Square Attack.
- Symptoms: Shattered gradients, stochastic gradients, vanishing gradients
- Detection: Black-box attacks succeed where white-box fail
- AutoAttack's role: Exposes masked gradients via Square Attack and FAB
- Key lesson: High PGD accuracy without AutoAttack validation is meaningless
Certified Robustness
Unlike AutoAttack's empirical evaluation, certified robustness provides a mathematical guarantee that no perturbation within a specified bound can change the prediction. Randomized smoothing is the most common technique.
- Empirical vs. Certified: AutoAttack gives upper bounds; certification gives lower bounds
- Gap: Certified accuracy is typically much lower than empirical robust accuracy
- Complementary use: AutoAttack for practical assessment; certification for safety-critical guarantees
- Key metric: Certified radius under L2 or L-infinity norm
Threat Model
The formal characterization of an adversary's capabilities that defines the scope of AutoAttack's evaluation. Specifying the threat model is essential for meaningful robustness claims.
- Knowledge: White-box (full gradient access) or black-box (query access only)
- Perturbation norm: L-infinity (most common), L2, L0
- Epsilon budget: Maximum allowed perturbation magnitude (e.g., 8/255 for CIFAR-10)
- AutoAttack default: L-infinity, epsilon = 8/255, full model access

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us