ericyoc/the_applied_ai_universe_adversarial_defenses
The Applied AI Universe: Adversarial Defenses Coding Guide
Hardening Every Model in the AI Universe
 [](https://colab.research.google.com/github/ericyoc/theappliedaiuniverseadversarialdefenses/blob/main/AdversarialDefensesHybrid_Quantum.ipynb)    
<p align="center"> <em>Book 1 builds the models. Book 2 breaks them. Book 3 hardens them — all within one shared model universe.</em> </p>
The Adaptive AI Codex Series
Book 3 — 601 pages, 37 chapters, ISBN 9798188703509. Series overview: ericyocam.com
Overview
This repository is Book 3 of The Applied AI Universe series. Book 2 attacks the models created in Book 1; Book 3 reconstructs those attacks and applies a corresponding defense to each victim.
The notebooks do not treat success against a static, original attack as sufficient evidence of robustness. Each experiment follows the same evaluation loop:
- reconstruct the Book 2 victim and attack;
- measure the undefended result;
- apply the defense;
- measure clean and post-defense performance;
- re-attack the defended system with an adaptive adversary that knows the defense is present; and
- save figures, metrics, and leaderboards to Google Drive.
The notebooks intentionally retain weak, partial, and failed defenses. Negative results are part of the defensive evaluation rather than being removed from the record.
The headline result
Across the 29 defenses for which both a naive and an adaptive figure were measured:
71% of the apparent benefit survives contact with a knowledgeable adversary. 29% does not. Reporting only the naive figures, as much published work does, would have overstated this repository's aggregate robustness by a factor of 1.42.
The loss is not evenly distributed, and the pattern is the finding:
Integrity checks lose nothing to an adaptive attacker — a digest either matches or it does not, so knowing the check exists confers no advantage. Detection defenses lose most of their measured benefit, because the attacker adds the detector's threshold as a constraint on their search. Defense family predicts failure mode.
Repository Notebooks
Both notebooks end with a Book 2 Commitments module. Book 2 closed each attack chapter with a mitigation preview, and not every promise is the lead defense of a chapter. These cells implement the remainder — perplexity detection, the Unicode confusables table, training-data deduplication, adapter provenance, the reward-model ensemble, encoding-perturbed training, encoding-sensitivity comparison, and fidelity-bounded evaluation. Each states the promise it delivers and logs nothing to the leaderboard, since the chapter's own cell owns that row.
Every cell carries a session guard, so any cell runs on its own after a runtime restart. The leaderboard cell is the exception: it reads a list the victim cells build during the session, so run the victims you care about first.
A locally downloaded notebook may include a duplicate suffix such as(1)or(2). The canonical repository filenames used by the badges are shown above.
Defense-Level Classification
Every defense is assigned a level in the notebook. The level identifies the maturity and evidentiary status of the defense family, not a guarantee that every implementation or run will withstand all adaptive attacks.
A Gold Standard label does not mean the evaluated model is invulnerable. For example, adversarial training is a gold-standard defense family, yet a particular training budget, threat model, or implementation may still fail under a stronger adaptive attack — and the tier table above shows that family retaining 98%, not 100%, precisely because one FGSM-trained model lost half its gain to a stronger evaluation.
Why Weak and Failed Defenses Matter
Weak defenses are not included as filler, shortcuts, or substitutes for stronger methods. They are included because understanding why a plausible defense fails is one of the most important lessons in adversarial machine learning.
A defense may appear effective when tested only against the original attack, yet collapse once the attacker knows how the defense works. Reporting only successful defenses would hide this distinction and could encourage readers to deploy controls that create false confidence.
The weak-defense experiments serve five specific purposes:
- They expose false security signals. A higher score against a fixed attack does not necessarily mean the defended system is robust.
- They demonstrate adaptive bypasses. Thresholds, detectors, rejection rules, and preprocessing steps can often be incorporated into the attacker's optimization strategy.
- They establish comparative baselines. Readers can see why a stronger defense is needed and what improvement it must provide.
- They teach evaluation discipline. A negative result shows why defenses must be tested against attacks designed specifically for the defended model.
- They support honest and reproducible research. Retaining failures prevents selective reporting and makes the notebooks more useful for education, peer review, and future work.
A sixth lesson: verify what a defense is allowed to see
An earlier revision of the semi-supervised cell rebuilt its screened label vector from the clean seed labels rather than the poisoned ones the defender actually holds. Every seed the screen happened to trust was silently restored to its true value, including poisoned seeds the screen had failed to detect. The cell ran without error and reported a gain of +0.345. Rebuilt from the labels a defender really has, the same screen recovers +0.024.
The defect is worth recording because it is invisible to the checks most people run: the code executes, the numbers are internally consistent, and the figure looks convincing. It is caught only by asking a question that is not about code at all — could a real defender obtain every input this defense consumes? A defense that reads the answer key is measuring nothing, and no amount of adaptive testing will reveal that, because the leak inflates the defended score under every attack equally.
The corrected cell and the corrected figures are in this repository. The original number is recorded here rather than quietly replaced, because the failure mode is more instructive than the result.
A seventh: a defense that fails is still a result
Fine-Pruning is a published, peer-reviewed backdoor defense. Applied to the LoRA adapter at 30% pruning, it did not remove the backdoor — the trigger fired before and after, and the measured gain is 0.000. That single configuration is not evidence about the method, and the notebook says so. What it does establish is narrower and generalizable: a defense whose mechanism is search provides nothing when the search fails, and the defender cannot distinguish a clean adapter from a failed search.
The lead defense for that victim is therefore adapter provenance — hashing and signing the adapter so any modification is detected before loading. It is trigger-agnostic, catches a change of 10⁻⁶ in a single weight, and is what Book 2 actually promised.
A DEMONSTRABLY WEAK label therefore means:
This defense is realistic enough to be tempting, but the notebook shows the conditions under which an informed attacker can bypass it.
Readers should interpret these experiments as diagnostic case studies: the defense is implemented, its initial benefit is measured, its assumptions are identified, the attacker is adapted to those assumptions, and the remaining weakness is documented.
Disclaimer
This repository is intended solely for education, reproducible defensive research, and authorized security evaluation. The attacks and defenses are applied only to the author's own models and publicly available benchmark datasets.
Reported performance depends on random seeds, runtime environment, package versions, compute resources, training budget, and cached model state. The included quantum experiments run on classical simulators through PennyLane's default.qubit; no physical quantum computer is required.
A defense that improves performance against the original attack may still fail against an adaptive or stronger attack. The notebooks report those failures explicitly.
Interactive Notebooks
GitHub may time out while rendering large notebooks. Open them directly in Google Colab or use nbviewer.
Classical Adversarial Defenses
 [](https://nbviewer.org/github/ericyoc/theappliedaiuniverseadversarialdefenses/blob/main/AdversarialDefensesClassical.ipynb)
Hybrid and Quantum Adversarial Defenses
 
Cross-Book Model–Attack–Defense Map
The table below connects the complete three-book progression:
- Book 1: the model or AI system being built;
- Book 2: the adversarial attack applied to that model; and
- Book 3: the corresponding defense evaluated against the original and adaptive attacks.
Classical Models
Hybrid and Quantum Models
Executed Results — Classical
Every figure below is the output of an executed cell. Nine defenses produced a gain of zero or below; those rows are reported as measured rather than reframed.
These values are executed run outputs, not universal guarantees. Re-running training can produce different numerical results.
Executed Results — Hybrid and Quantum
A fixed ℓ∞ budget of 0.30 on the rotation angles produces state fidelities from 0.765 to 1.000 — so an ℓₚ figure for a quantum classifier bounds a quantity the circuit does not operate in. Report worst-case fidelity, not the mean, which would have claimed 0.985.
Adaptive-Attack Evaluation
Every defense cell contains an adaptive check appropriate to the defended system. Three patterns cover all of them:
Upgrade the attack within the same family. A defense trained on single-step FGSM is evaluated with multi-step PGD. The hybrid QNN loses half its gain this way; the PGD-trained VQC in the same notebook loses none.
Re-fit the attacker's search to the defense's own criterion. Where a defense computes a statistic and compares it to a threshold, the adaptive attacker treats the threshold as a constraint and searches beneath it. The ensemble detector falls from +0.233 to +0.066; the quantum anomaly detector from 0.350 to 0.250.
Exceed the defense's stated operating limit. The Q-Learning agent's median aggregation holds at 0.82 through 40% corruption and drops to 0.14 at 60% — so the adaptive figure equals the undefended baseline.
Where no adaptive attack applies, the notebook says so and explains why. Integrity verification has no threshold to sit beneath and no criterion to satisfy, which is why that family retains 100%. "No adaptive attack applies, and here is why" is a valid result; "we did not run one" is not.
Interpreting the Results
The level and the measured outcome should always be read together.
- Gold Standard + successful adaptive result: the defense family is well established and the evaluated implementation retained an advantage under the tested adaptive attack.
- Gold Standard + failed adaptive result: the family remains well established, but this implementation, training budget, or threat-model coverage was insufficient.
- Engineering + successful result: integrity, provenance, or validation controls correctly prevented unauthorized parameter or state modification — within a scope that must be stated.
- Heuristic + successful original result: the mitigation may stop a narrow attack but should not be presented as general robustness.
- Demonstrably Weak: the notebook intentionally shows why detection or rejection alone can be bypassed by an adaptive adversary.
No defense level should be interpreted as a formal certification unless the specific experiment actually computes and reports a valid certificate. One experiment does — and that chapter is also where the limitation of certificates is measured, since the guarantee held on every point where it was issued, in an ℓ₂ ball that did not contain the ℓ∞ threat.
This evaluation is simpler than the field's standard
Fewer attacks produce an optimistic estimate, not a conservative one, because robustness is a worst case over attacks and this repository takes the worst of a smaller set. Every robustness figure here should be read as an upper bound, and none is comparable to a RobustBench leaderboard entry.
Metrics and Visualizations
Each experiment writes a standardized scorecard containing the applicable fields:
For integrity defenses, the primary result is whether corrupted parameters or weights were detected, rejected, and replaced with a trusted checkpoint. Input-space perturbation norms do not apply, and are recorded as NaN rather than zero — the distinction between not measured and measured as nothing matters when results are aggregated.
Figures and CSV leaderboards are saved throughout execution.
Google Drive Outputs
MyDrive/
├── AI_Universe_Adversarial_Defenses/
│ ├── datasets/
│ ├── models/
│ ├── def_*.png # 36 classical figures
│ └── leaderboard_defenses_classical.csv
└── AI_Universe_Adversarial_Defenses_Quantum/
├── models/ # 6 sealed circuit parameter files + digests
├── def_*.png # 8 quantum figures
└── quantum_defense_leaderboard.csvThe notebooks cache downloaded datasets and trained model weights in Google Drive so later sessions can reuse them. Two exceptions: pretrained bases downloaded by transformers (DistilBERT, GPT-2) are cached by that library in Colab's local disk rather than in models/, so they re-download on a fresh session; and several quantum circuits train in seconds on a simulator, so they retrain each session rather than caching.
For a variational circuit the parameters are the model — there is no architecture file to reload them into, only an angle array. The quantum notebook therefore writes each trained circuit's parameters alongside a SHA-256 digest, which is what makes the integrity defense meaningful across sessions rather than only within one.
Run the setup/engine cell near the top of each notebook once per Colab session. It mounts Drive, creates output directories, installs required packages, and defines shared utilities such as Scorecard, report, savefig, acc, cache_dataset, and perturbation-statistics helpers.
Technologies Used
Worth noting: the defenses are smaller than the attacks. Seven of them use nothing beyond hashlib and unicodedata, both standard library. ART is the largest dependency and is used almost entirely to attack the defended models, because a defense that has not been re-attacked has not been measured.
Not used, deliberately. TensorFlow Privacy and Opacus are the production DP-SGD implementations; this repository implements it from scratch so both halves of the mechanism are visible. The cost is real: without a privacy accountant, the DP-SGD cells can state that the mechanism was applied and cannot state what it guarantees. Production work should use the libraries.
Suggested Execution Order
- Open a notebook in Google Colab.
- Run the setup/engine cell.
- Allow Google Drive access.
- Run cells from top to bottom because later modules use shared utilities and cached assets.
- Review each original-attack scorecard and its adaptive check together.
- Run the Book 2 Commitments module at the end for the promises that are not any chapter's lead defense.
- Inspect the generated figures and CSV leaderboard in Google Drive.
- Treat weak and failed defenses as findings, not as cells to omit.
Further Reading
Each reference includes either a DOI link or, where no DOI is assigned, an authoritative publication or preprint URL.
Topics: adversarial-defenses adversarial-training machine-learning-security adaptive-attacks randomized-smoothing differential-privacy data-sanitization model-integrity model-hardening tensorflow pytorch pennylane quantum-machine-learning huggingface peft lora mamba ai-security red-team blue-team mlsecops cybersecurity educational
