haotianblog
AI Security Engineering
An AI security topic hub for threat modeling, adversarial examples, poisoning, model privacy, and LLM/RAG/Agent security.

AI Security Engineering

AI Security Engineering

This hub organizes AI security material around defensive review rather than attack spectacle. The route covers threat modeling, adversarial examples, data poisoning, model privacy, and LLM/RAG/Agent security, but the examples are kept to local toy settings, built-in datasets, and synthetic cases. The purpose is to help readers identify trust boundaries, choose evaluation metrics, and document mitigations without turning the page into instructions against real systems.

AI security problems often look unrelated on the surface. A poisoned training set, an adversarial image, a membership inference risk, and a prompt-injection failure all involve a boundary where the system trusts data, output, retrieval context, or tool behavior too much. This hub keeps that common structure visible so readers can move from individual demos to a review checklist.

Defensive Reading Path

Start with threat modeling. Before running any experiment, identify the asset, actor, boundary, failure mode, and evidence that would show the risk. Then read the adversarial example and poisoning articles as controlled metric exercises: what changes in accuracy, robustness, attack success rate, or false-positive behavior? Move to model privacy and RAG/Agent controls after that, because those pages require careful separation between demonstration, policy, and operational misuse.

For each article, write down three things: what the toy experiment proves, what it does not prove, and which production control would need independent validation. This prevents a small lab from being overclaimed and makes the material safer for education, academic discussion, and defensive engineering practice.

Safety Boundary

The site does not provide help for unauthorized access, evading platform controls, attacking third-party services, stealing data, or bypassing security systems. Security examples are framed as local defensive learning material. If a technique can be misused, the article should emphasize the metric, mitigation, and review process rather than provide operational targeting guidance.

Review Checklist

A useful AI security review starts with scope. Identify the model or workflow, the asset being protected, the attacker capability assumed by the article, the data boundary, the evaluation metric, and the mitigation that would be considered acceptable. Without that scope, an adversarial example, poisoned sample, privacy test, or prompt-injection demonstration can sound dramatic while proving very little.

The pages in this route should therefore separate three layers: the educational toy experiment, the general security concept, and the production control that would require independent validation. A toy poisoning demo can teach how labels influence training, but it does not automatically measure the risk of a real data pipeline. A RAG prompt-injection lab can teach trust boundaries, but it does not replace access control, tool allowlists, monitoring, and incident response.

How Demos Are Limited

AI security demos on this site are intentionally constrained. They use local scripts, built-in datasets, synthetic examples, and defensive language so the reader can study the failure mode without targeting a third-party system. Those limits are part of the value of the page because they keep the experiment reproducible and reduce unnecessary operational detail.

Readers should not overclaim the result of a limited demo. A successful attack in a toy setting does not prove broad real-world exploitability, and a mitigation that works in a small notebook does not prove production safety. The durable lesson is the review method: define the boundary, measure the failure, document the assumption, and choose a control that can be tested again.

AI Security Review Matrix

Review object Core question Evidence to preserve Boundary statement
Threat model Are the asset, attacker, entry point, and failure impact explicit? System diagram, trust boundary, attacker assumption, failure metric, and priority. A threat model starts the review; it is not proof that the system is protected.
Toy lab What exactly does the demo prove? Data source, parameters, random seed, metric movement, and failed examples. A local toy experiment does not directly measure production risk.
Mitigation Can the mitigation be tested, rolled back, and monitored? Filter rule, permission boundary, log fields, alert condition, and retest result. One mitigation technique does not replace access control, monitoring, and response.
Misuse limit Does the article avoid unauthorized operational guidance? Authorization note, synthetic data, local run path, and defensive conclusion. The material is for education, academic discussion, and defensive research.

Topic hub

AI Security Engineering

A reproducible route through threat modeling, adversarial examples, poisoning, model privacy, and LLM/RAG/Agent security.

Built for engineers researching AI security threat modeling, robust evaluation, poisoning defense, membership inference, model extraction, and prompt-injection controls.

Open AI learning path Open resources Copy share links

Editorial notes

Why these articles belong in one route

AI security content needs a clear boundary between defensive learning and abuse. This hub uses built-in datasets, synthetic examples, and local toy pipelines, with emphasis on threat modeling, metrics, and defensive review.

Adversarial examples, poisoning, model privacy, and RAG injection are connected by one question: whether the trust boundary among training data, model output, external documents, and tool calls is explicit.

Each article turns risk into audit-friendly items, including trigger conditions, observable metrics, false-positive concerns, and mitigation controls that readers can adapt to their own defense checklists.

What you will build

You will use a safe toy lab and connect risks, metrics, boundaries, and engineering controls into one reviewable workflow.

  • AI security threat modeling
  • adversarial examples robust evaluation
  • data poisoning backdoor defense
  • model privacy membership inference
  • RAG prompt injection defense

Recommended reading order

Start with concepts, then move into runnable projects

AI Security Threat Modeling

Build a defense map with NIST adversarial ML, MITRE ATLAS, and OWASP LLM risks.

Level: Professional Reading time: 12 min
  • AI Security
  • Threat Modeling
  • NIST
  • MITRE ATLAS
  • OWASP

Adversarial Examples and Robust Evaluation

Evaluate clean and perturbed accuracy with an FGSM-style digits experiment.

Level: Professional Reading time: 11 min
  • Adversarial Examples
  • FGSM
  • Robust Evaluation
  • scikit-learn

Data Poisoning and Backdoor Defense

Study poison rate, trigger behavior, attack success rate, and training pipeline controls.

Level: Professional Reading time: 11 min
  • Data Poisoning
  • Backdoor Defense
  • Training Pipeline
  • scikit-learn

Model Privacy and Extraction Defense

Measure membership inference signal and surrogate fidelity against a local toy model.

Level: Professional Reading time: 12 min
  • Model Privacy
  • Membership Inference
  • Model Extraction
  • Prediction API

LLM, RAG, and Agent Security

Separate instructions from data and enforce tool permissions against indirect prompt injection.

Level: Professional Reading time: 12 min
  • LLM Security
  • RAG
  • Agent Tools
  • Prompt Injection

Resources and distribution assets

Code, data, diagrams, and share assets in one place

FAQ

Direct answers to common search questions

Does this hub provide steps for attacking real systems?

No. The lab uses only scikit-learn built-in data and synthetic toy data, with a focus on defensive evaluation, risk records, and engineering review.

Who is the intended reader?

It is for engineers who can read Python, understand basic ML workflows, and want to put AI systems into security review.

Scroll down