NIST's New Agentic AI Security Taxonomy Is a Draft Vocabulary, Not a Checklist

When an AI agent can read data, call tools and take actions across a workflow, “prompt injection” is too narrow a description of the security problem. A defender needs to ask where an attack enters, which stage it reaches, what access the attacker has and what outcome they want. NIST’s new adversarial-machine-learning draft tries to give those questions a shared structure. Its immediate value is a better map for discussion; its status is still explicitly draft. ^[1]

Why a taxonomy matters for agents

Security teams often inherit overlapping vocabulary: model attacks, application flaws, data poisoning, tool abuse, identity compromise and operational mistakes. A taxonomy does not prevent these events. It can help a product team compare reports that use different terms and notice a neglected part of the lifecycle.

NIST says this edition builds on its earlier adversarial machine-learning taxonomy and focuses on attacks against agentic SI systems. The hierarchy spans machine-learning methods, stages in an attack lifecycle and an attacker’s goals, objectives, capabilities and knowledge. The publication page also identifies questions for commenters: which attacks and mitigations are missing, and which terms need standardization. ^{[1] [2]}

That framing fits agent systems because the exposed surface is not only a model endpoint. Consider a support agent that retrieves customer records, drafts a refund and can submit it. A hostile instruction might arrive in user text, a retrieved document or a compromised tool response. The impact then depends on permissions, confirmation steps, logging and whether the system can cross from reading into writing. Mapping entry point, lifecycle stage and attacker objective helps teams avoid treating every incident as the same prompt-filtering problem.

A useful tool, with limits

NIST describes the draft as a common-language foundation intended to inform future standards and practice guides. It is not yet a final specification, and an organization should not present it as a certification requirement. The comment deadline is December 18, 2026. ^[1]

It also cannot replace a system-specific threat model. A taxonomy can name attack classes, but it does not tell a team which API permission is overbroad, which data source is untrusted, how long credentials persist or what a customer could lose. Those answers depend on architecture and deployment context.

Nor is one source of guidance enough. NIST’s prior AI 100-2 work gives continuity for adversarial machine learning, while OWASP’s GenAI Security project focuses on practical risks for generative AI applications. These resources use different scopes and purposes; teams should connect them rather than assume one list subsumes the others. ^{[3] [4]}

Turn the draft into a review session

Pick one agent workflow and draw its path from user request to data retrieval, model reasoning, tool call and external effect. For every transition, ask five questions: what is trusted, what can be influenced, what capability is available, what can go wrong, and how would the team detect it? This produces a concrete system map against which taxonomy terms can be tested.

Then write scenarios rather than only labels. For example: “An attacker places crafted content in a source the agent retrieves; the agent treats it as an instruction; it uses an authorized write tool; an approval gap allows the action; audit records fail to connect the source to the change.” The scenario identifies where controls belong: source handling, instruction/data separation, least privilege, action confirmation, logging and incident response.

Make the result operational. Record the scenario owner, existing controls, evidence that each control works, residual risk and a review date. Keep unknowns visible. If the draft’s terminology does not fit a real attack path, note that mismatch; that is exactly the kind of feedback a public draft can benefit from.

A comment window, not a finish line

The release of a taxonomy is not the same as the release of a working security program. NIST has put a structured draft into public review, giving implementers a short window to challenge its coverage and language. Security teams can benefit before it is finalized by using it to sharpen threat discussions, but should keep their existing risk controls grounded in actual system behavior.

The strongest response is not to wait for the final document or to declare compliance today. Use the draft to find ambiguities in your own threat model, compare it with established application-security guidance and send specific, evidence-based comments before the deadline.

Good comments are concrete. Point to a lifecycle stage or term, describe a plausible scenario, explain why the current category does not fit, and suggest what evidence or mitigation would make the distinction useful. If you are writing from an operational incident, remove customer identifiers and exploit details that could create new exposure. NIST’s publication page identifies the questions it wants reviewers to answer and provides the submission route; a short, well-supported gap report is more useful than a generic statement that the field is changing quickly. ^[1]

For product teams, do not wait for the public-comment process to finish before asking whether an agent can read untrusted material or take consequential actions. The draft supplies a way to organize those questions; system controls still need to be chosen and tested now. Our articles on sandboxing computer-use agents and agent access to business workflows discuss concrete permission boundaries that a threat review can map to a larger taxonomy.