A January 2024 archive, not a new announcement
This is a retrospective archive edition, not news published today. On January 4, 2024, the U.S. National Institute of Standards and Technology (NIST) described adversarial machine learning, or AML, threats and mitigation approaches in a publication titled *Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations*. The record belongs to a period in which AI systems were already being used in areas ranging from chatbots to vehicles and clinical support, according to NIST’s account.
The publication’s most consequential message was caution, not a promise of complete protection. NIST stated that no foolproof method then existed for protecting AI from misdirection, and said developers and users should be wary of claims otherwise. [5] This was not a prediction that every AI system would malfunction, nor a finding that defensive work has no value. It was a limit on what the publication said could be assured.
That limit remains important when reading security marketing. A product statement about a filter, guardrail, monitoring function, or model configuration is a vendor claim unless accompanied by evidence relevant to the buyer’s own system and conditions. The supplied sources do not provide universal effectiveness figures, comparative benchmarks, or an assurance rating for any individual deployment. They therefore do not justify a general declaration that an AI service is secure.
NIST’s January 2024 material also connected the AML publication to its broader AI Risk Management Framework. AI RMF 1.0, released in January 2023, was voluntary guidance for organizations designing, developing, deploying, or using AI systems. Its practical core identifies four functions: govern, map, measure, and manage. [1] The connection is useful as an organizing frame, but it should not be mistaken for a compliance verdict or a guarantee.
What NIST classified
The January 2024 report considered four major categories: evasion, poisoning, privacy, and abuse attacks. [5] The classification is relevant because “AI security” is not a single exposure. The categories identify different ways an AI system, its inputs, or its information environment may be manipulated.
NIST described evasion attacks as taking place after deployment and attempting to alter an input so that a system responds differently. It used examples involving altered road markings and the risk of an autonomous vehicle misinterpreting what it sees. Poisoning attacks occur during training through corrupted data. NIST illustrated this category with inappropriate language introduced into conversation records in an attempt to influence a chatbot’s later behavior.
Privacy attacks, in NIST’s account, seek sensitive information about an AI system or its training data during deployment. Abuse attacks involve incorrect information inserted into a source that appears legitimate but has been compromised, which an AI system then absorbs. These descriptions are included here to clarify the defensive taxonomy, not to provide procedures for carrying out attacks.
The categories do not automatically map to every architecture in the same way. A model that is fixed after training, a chatbot connected to external material, and an AI application allowed to take actions can expose different inputs, data dependencies, and consequences. The source record supports the need to identify attack types and mitigation approaches; it does not prescribe a single test suite for all of those systems.
A practical reading is to begin with system boundaries. Organizations can identify where user inputs enter, which data sources influence outputs, which information requires protection, and which outputs have material consequences. That is a defensive scoping exercise. It avoids collapsing training data, live external content, application interfaces, and model behavior into one undifferentiated category.
Mitigations require bounded claims
NIST did not present mitigations as a solved problem. Its January 2024 announcement said that current defenses lacked robust assurances that they fully mitigated risks. [5] That qualification should shape how mitigation results are reported. A test result can describe performance under the stated system version, scenario, configuration, and method. It cannot, on its own, establish protection against every possible manipulation or future change.
For an organization, the first useful question is not whether it has “solved AI security.” It is whether a claimed control has a defined purpose, a known operating context, and evidence that can be reviewed. For example, a team may examine whether untrusted content reaches a system, whether an application separates content from operational instructions, whether consequential actions are subject to authorization, and whether incidents can be observed and investigated. These are defensive review questions rather than bypass instructions.
Results should retain their context. Record the model and application release, connected sources, relevant policy settings, evaluators, test dates, and decision criteria. This is an editorial recommendation rather than a requirement stated in the supplied NIST capture. Its purpose is to prevent an old result from being presented as evidence for a materially changed system.
The distinction matters because AI applications can change through model releases, altered data sources, integrations, or changes in how users interact with them. NIST’s sources establish that AI risks can emerge from technical and societal factors and that AI systems may be affected by changing data. They do not establish how often a particular organization should retest. Any review cadence should therefore be tied to local risk, system changes, and accountable decision-making rather than represented as a universal NIST rule.
Using the AI RMF as a frame
The AI RMF’s four named functions offer a way to structure a discussion without claiming that the framework removes AML risk. Govern concerns organizational approach and accountability. Map concerns context and risks. Measure concerns assessing and monitoring AI risks. Manage concerns responding to those risks. NIST said the functions can be applied in context-specific use cases and at stages of the AI life cycle. [1]
In a defensive implementation, those labels can help teams make their work legible. Under govern, an organization can establish who may make security assertions and who receives unresolved issues. Under map, it can describe intended use, data flows, affected parties, interfaces, and dependencies. Under measure, it can select authorized assessments relevant to the identified exposure and state their limitations. Under manage, it can decide whether to change a design, narrow a use case, add oversight, monitor, or accept a documented residual risk.
These are practical interpretations of a voluntary framework, not claims that NIST mandated a particular governance process. The supplied record says the framework is flexible, structured, and measurable, and intended for organizations with varying capacities. It does not supply a universal assurance template.
The same caution applies to vendor material. A vendor can provide useful documentation about intended controls, supported configurations, known limitations, and product changes. That information should be separated from independent evidence. Where an organization cannot validate a claim in its own context, the responsible description is uncertainty. Repeating a vendor assertion as a fact would add confidence without adding evidence.
Later knowledge and the historical boundary
NIST published a later AML update on March 24, 2025. That later account said the report addressed predictive AI and generative AI, including misuse attacks for generative AI, and that NIST planned annual updates as developments emerged. [4] This later information is relevant to the continuing subject, but it must not be recast as though it were part of the January 2024 announcement.
The distinction is more than a dating detail. It preserves what the archive actually shows: in January 2024, NIST published a taxonomy and terminology of attacks and mitigations, warned that no foolproof defense existed, and encouraged better defenses. Later reporting can expand the current context; it cannot retroactively change the claims made in the original publication.
The sources also do not establish that every newly introduced AI feature creates a specific AML vulnerability, or that a particular mitigation is effective. They establish a changing field and voluntary guidance. Organizations should therefore use current technical assessment alongside historical taxonomy, rather than treating either a past publication or a later update as a complete answer for a live system.
Limitations and practical implication
The supplied captures are NIST publications and secondary reporting about NIST’s work. They do not provide deployment-specific assurance, comparative attack-success rates, or a ranked list of controls. This article makes no benchmark claim, gives no exploit instructions, and does not infer effectiveness merely because a taxonomy or mitigation exists.
The practical implication is deliberately limited: use the four attack categories to make risk discussions more specific, and use the AI RMF’s govern, map, measure, and manage frame to assign and document decisions. Review the AI system’s exposed inputs, data sources, interfaces, and consequential outputs. Define authorized defensive checks. Preserve the evidence context and state what those checks cannot prove. Route unresolved issues to a named owner.
That approach reflects the archive’s central caution. Shared terminology can improve communication, but it is not a substitute for evidence. Mitigations can reduce some risks, but the January 2024 record did not claim a foolproof defense. The appropriate outcome is clearer, bounded security claims—not stronger assurances than the evidence supports.