What Is Adversarial AI? Attacks, Defenses & Governance

Adversarial AI attack on a stop sign recognition model

Key takeaways

  • Adversarial AI is the deliberate manipulation of a machine learning model, through its inputs, its training data, or its parameters, so that it misclassifies, leaks data, or produces attacker-chosen outputs.
  • The main attack families are evasion, data poisoning, and privacy or extraction attacks, plus prompt injection and jailbreaks against generative models.
  • Adversarial robustness is now a legal duty: Article 15 of the EU AI Act makes accuracy, robustness, and cybersecurity mandatory for high-risk AI from 2 August 2026.
  • Real defense takes both technical controls (adversarial training, input filtering, red-teaming) and governance controls (a named owner, documented evidence, a review cadence).
  • Treat adversarial AI as a governed risk inside your AI management system, not as a one-off security purchase.

What is adversarial AI?

Adversarial AI is the practice of attacking machine learning systems by exploiting how they learn and how they make decisions. Rather than breaking into a server, the attacker feeds the model data that looks ordinary to a human but steers the model toward a wrong or dangerous result. The research and security communities also call this adversarial machine learning, and in practice the two terms describe the same field. The clearest illustration is the adversarial example. Add a few small stickers to a stop sign, or change a handful of pixels in a photo, and a vision model that was highly accurate can suddenly read the stop sign as a speed-limit sign. The change is often imperceptible to people, yet it flips the model’s output. That gap between human perception and model perception is the surface every adversarial attack targets. What makes this different from classic hacking is the target. Traditional cybersecurity protects code, networks, and credentials. Adversarial AI goes after the statistical logic of the model itself: the training data it learned from, the boundaries it draws between classes, and the confidence it places in its own answers. For any organization deploying AI in hiring, credit, medical triage, fraud detection, or content moderation, that logic is exactly where the business value, and the risk, sits. The field now has an official reference point. NIST AI 100-2e2025, published in March 2025, is the United States taxonomy of adversarial machine learning attacks and mitigations, and it anchors much of the vocabulary used below. If you are standing up an AI risk management program, it is the document to map your controls against.

How adversarial AI attacks work

Most adversarial attacks follow a recognizable arc. First the attacker studies the target system to learn what it does and how it responds. Next they craft an input, a poisoned training sample, or a manipulated prompt designed to trigger the failure they want. Then they deliver that payload and observe the result. Finally they refine the attack or cover their tracks. The NIST taxonomy classifies attacks along a few practical dimensions, and each one changes how you defend. The first is the attacker’s goal: break the model’s integrity (force a wrong answer), its availability (degrade performance), or its confidentiality (extract data or the model itself). The second is capability and access: can the attacker only send inputs, or can they also reach the training pipeline. The third is knowledge. In a white-box attack the adversary knows the model’s architecture and weights, which makes crafting adversarial inputs far easier. In a black-box attack they know almost nothing and must probe the model from the outside, often transferring an attack built against a similar model. The last dimension is timing across the machine learning lifecycle. Training-time attacks corrupt the data or the process while the model is being built. Deployment-time attacks manipulate live inputs after the model is in production. Governing adversarial risk means covering both ends of that lifecycle, not just the running system, which is why an inventory of your AI assets and their training sources is a prerequisite rather than a nice-to-have.

The main types of adversarial attacks

Four attack families cover most of what organizations face today. Evasion attacks happen at inference time. The attacker perturbs a legitimate input so the deployed model misclassifies it, while the input still looks normal to a person. Spam that slips past a filter, malware tuned to read as benign, and the perturbed stop sign are all evasion attacks. Poisoning attacks happen at training time. The attacker injects corrupted or mislabeled data into the training set, or tampers with the model during fine-tuning, so the finished model carries a hidden flaw. A backdoor that behaves normally until it sees a specific trigger is a poisoning attack. Privacy and extraction attacks target confidentiality. Membership inference reveals whether a specific record was in the training data. Model extraction steals a functional copy of a proprietary model by querying it repeatedly. Model inversion reconstructs sensitive training inputs from the model’s outputs. Generative AI adds its own category. NIST AI 100-2e2025 extends the taxonomy to prompt injection (direct and indirect), jailbreaks, and supply-chain compromise of foundation models and their components. Indirect prompt injection is especially hard to govern because the malicious instruction hides inside content the model retrieves, not in anything the user typed. For a full catalogue of techniques, MITRE ATLAS documents fourteen adversarial tactic categories and more than eighty techniques targeting AI systems, structured like the familiar ATT&CK matrix. It is a useful backbone when you want to move from awareness of these categories to a concrete list of things to test and monitor across your AI systems.

Real-world examples of adversarial AI

Adversarial AI is not a laboratory curiosity. Researchers have repeatedly shown that small physical alterations to road signs can fool the perception models used in driver-assistance systems, turning a stop sign into a sign the model ignores. The consequences of an evasion attack in that setting are obvious. Data poisoning has an equally long track record. Public chatbots that learn from user interactions have been steered into offensive behavior within hours by coordinated malicious input, a live demonstration that an open feedback loop is an attack surface. Generative AI has widened the target. Security researchers disclosed EchoLeak, an indirect prompt injection against Microsoft 365 Copilot that could exfiltrate data without the user doing anything unusual, showing how retrieval-augmented assistants inherit the trust of whatever content they read. And this is now scale, not anecdote: the CrowdStrike 2026 Global Threat Report found that adversaries abused legitimate generative AI tools at more than ninety organizations during 2025. Adversarial techniques have moved from academic papers into the standard attacker toolkit, which is why they belong on the same risk register as any other material threat.

Why adversarial AI is a governance problem, not just a security one

Most explainers stop at the technical defenses. That is a mistake, because adversarial robustness has crossed from best practice into legal obligation. Article 15 of the EU AI Act requires high-risk AI systems to reach an appropriate level of accuracy, robustness, and cybersecurity, and to keep it across their entire lifecycle. Recital 76 is explicit about the threat model, naming data poisoning, adversarial examples, model evasion, and confidentiality attacks as risks that providers must address with technical measures. These obligations become enforceable from 2 August 2026. That reframes the question. Adversarial AI is no longer only about whether a model can be fooled; it is about whether you can demonstrate, to an auditor or a regulator, that you identified the risk, applied proportionate controls, and can prove they work. Article 15 also expects providers to declare relevant accuracy and robustness metrics in their technical documentation, so the evidence has to exist on paper, not just in an engineer’s head. Other frameworks point the same direction. The NIST AI Risk Management Framework asks organizations to measure and manage AI risks continuously, and ISO/IEC 42001 sets out an AI management system with controls and an AI asset inventory. The common thread is accountability: a named owner, a documented control, and a repeatable review. The readiness gap is real. Industry surveys in 2025 found that while roughly 83 percent of organizations planned to deploy agentic AI, only about 29 percent felt ready to do so securely. Closing that gap is a governance exercise, not a purchase.

How to defend against adversarial AI

Effective defense combines two layers that most teams treat separately. The technical layer reduces the attack surface of the model itself. Adversarial training exposes the model to adversarial examples during development so it learns to resist them. Input preprocessing and sanitization strip likely perturbations before they reach the model. Robustness testing and red-teaming, including the adversarial testing workflow that Google and others document for generative systems, probe the model the way an attacker would. Anomaly monitoring watches live inputs and confidence scores for the statistical signatures of an attack, and strict access control limits who can query or fine-tune the model. The governance layer decides whether those technical controls are actually applied, evidenced, and maintained. AI Sigil’s own control mapping frames each risk as prevention, detection, and response. For adversarial inputs that means prevention through adversarial training and red-team testing, detection through input-anomaly and confidence-based monitors, and response through alerts, containment, and model patching once a vulnerability is found. Wrapping those actions around the NIST AI 100-2e2025 mitigations and the MITRE ATLAS techniques turns a threat list into an auditable control set that lives inside your governance platform. The point is that a single tool cannot solve this. Robustness has to be owned and reviewed like any other control.

Building adversarial AI into your AI governance program

Practically, that means giving adversarial AI a home in your operating model rather than a mention in a slide deck. Start by putting adversarial risk on the AI risk register and rating it by the criticality of each system, so a fraud model or a medical triage tool gets more scrutiny than an internal chatbot. Assign a single accountable owner for that risk, then attach the prevention, detection, and response controls above, with the specific tests each system must pass. Capture the evidence as you go: adversarial test results, robustness metrics, monitoring logs, and incident records, which is exactly the documentation Article 15 expects. Finally, set a review cadence, because a model that was robust at launch drifts, and new attack techniques appear constantly. This is where an AI management system earns its place. Doing it in spreadsheets across dozens of models does not scale, and it leaves gaps an auditor will find. A platform that keeps the inventory, the risks, the controls, and the evidence in one linked structure is what lets you show, on demand, that adversarial AI is governed and not just noticed.

FAQ

What is adversarial AI? Adversarial AI is the deliberate manipulation of a machine learning model to make it fail or behave in an attacker’s favor. Attackers craft inputs, poison training data, or exploit prompts so the model misclassifies, leaks information, or produces harmful output, usually without any obvious sign to a human observer. What is an adversarial example? An adversarial example is an input that has been changed just enough to fool a model while still looking normal to people. A photo with a few altered pixels, or a stop sign with small stickers, can cause a highly accurate model to produce the wrong answer. Adversarial examples are the classic form of an evasion attack. How does a poisoning attack differ from an evasion attack? Timing is the difference. A poisoning attack corrupts the training data or the model while it is being built, planting a flaw that ships with the finished model. An evasion attack leaves the model untouched and instead manipulates a live input at inference time to trigger a misclassification. Can adversarial attacks be fully prevented? No. There is no single control that eliminates adversarial risk, because defenses and attacks co-evolve. The realistic goal is to raise the cost and lower the impact through layered controls, adversarial training, monitoring, red-teaming, and a governance process that detects, responds to, and learns from incidents. Is adversarial AI covered by the EU AI Act? Yes. Article 15 requires high-risk AI systems to be accurate, robust, and cybersecure across their lifecycle, and Recital 76 explicitly names data poisoning, adversarial examples, and model evasion as risks providers must address. These obligations apply from 2 August 2026. What is the difference between adversarial AI and adversarial machine learning? In everyday use there is none. Adversarial machine learning is the technical term for the research field, and adversarial AI is the broader label often used in business and security contexts. Both describe attacks that exploit how models learn and predict.

Conclusion

Adversarial AI is where cybersecurity meets AI governance. The attack families, evasion, poisoning, extraction, and prompt injection, are well documented, and the technical defenses are known. What separates exposed organizations from resilient ones is whether adversarial risk is governed: owned by someone, backed by controls, and evidenced for an auditor. With Article 15 of the EU AI Act enforceable from August 2026, that is now a compliance requirement as much as a security one. Treat adversarial AI as a managed risk inside your AI governance platform, and you turn a moving threat into a controlled one.

What Is Adversarial AI? Attacks, Defenses & Governance

Adversarial AI attacks ML models through poisoning, evasion and prompt injection. See the attack types, defenses, and governance controls the EU AI Act now requires.

California AI Laws: Who Must Comply, and by When

California AI laws explained by role and date: SB 53, SB 942, SB 243, CCPA ADMT, FEHA rules and the bills Newsom signed in September 2026.

TRAIGA Compliance: The Texas AI Law, Operationalized

TRAIGA has been in force since January 2026. What the Texas AI law prohibits, how the NIST AI RMF safe harbour works, and the evidence you need to rely on it.

Vendor Due Diligence for AI: 12 Questions Checklists Miss

Standard vendor due diligence was built for a pre-AI supply chain. Here are the 12 AI-specific questions to add, and the legal duty behind them.

Model Risk Management for AI and Machine Learning

Model risk management is being rewritten for AI. See how SR 26-2, the EU AI Act, ISO 42001 and NIST AI RMF reshape MRM for machine learning and GenAI.

Policy Management Software: The AI-Era Buyer’s Guide

Policy management software must now prove AI policies work, not just that staff signed them. Evaluation criteria, EU AI Act duties and buying traps.