The Short Answer
NIST's 2026 draft taxonomy of adversarial machine learning, SP 2400-102e2026, indexes 12 attack types against agentic systems and finds that model-level defenses alone do not hold. The mitigations that do are architectural, so an agency's agent security depends on who runs the runtime. With ibl.ai you own all the code and the data, inside your own perimeter.
The draft was published on 9 November 2026 and is open for public comment through 18 December 2026, according to the NIST CSRC publication page.
It is voluntary guidance, not a regulation. It matters because NIST taxonomies tend to become the vocabulary that later standards, audits and contract language borrow.
What is NIST SP 2400-102e2026?
It is the initial public draft of "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations."
Its authors are Apostol Vassilev and Maia Hamin of NIST, Alina Oprea of Northeastern University, Alie Fordyce of ElevenLabs and Xander Davies of the U.K. AI Security Institute.
It is not a brand-new document. NIST describes it as building on the AI 100-2 series, whose previous edition, AI 100-2 E2025, was published in March 2025. The circulating "first taxonomy" framing overstates that.
What is new is structure. The full draft gives agentic systems their own section (Section 4) and their own attack index, separate from predictive and generative models. The draft calls these "agentic SI systems."
Which 12 attack types does NIST's agentic taxonomy list?
The agentic index files 12 distinct attack types under five attacker objectives. Several appear under more than one objective, because one technique can serve several goals.
| Attacker objective | Attack types indexed under it |
|---|---|
| Availability | Resource exhaustion, malicious tools, malicious agents |
| Integrity | Agent hijacking, indirect prompt injection, memory poisoning, malicious tools, malicious skills, malicious agents, backdoor poisoning, targeted poisoning |
| Privacy | Agent hijacking, indirect prompt injection, prompt injection, memory poisoning, malicious tools, malicious agents |
| Misuse | Prompt injection, decomposition attacks |
| Supply chain | Model poisoning, malicious tools, malicious skills |
Seven of the 12 carry new agent-specific identifiers in the draft (NISTAML.061 to .067): agent hijacking, memory poisoning, malicious tools, malicious skills, malicious agents, resource exhaustion and decomposition attacks.
The rest are older techniques, such as indirect prompt injection, re-filed for agents.
Malicious tools is the most cross-listed entry, appearing under four of the five objectives. That is a fair summary of where agent risk concentrates: at the point where an agent reaches outside itself.
How does memory poisoning work against a government AI agent?
Memory poisoning, in NIST's description, means inserting malicious content into a knowledge base or long-term memory the agent retrieves later. One insertion can influence many subsequent tasks.
The draft's sharper point is timing. A dormant payload planted through a single untrusted tool call can sit in memory until a user later raises a sensitive topic, then activate to exfiltrate personal data. Injection and exploitation are decoupled.
For an agency, that maps onto any agent that remembers across sessions: a benefits-intake assistant, a procurement agent reading vendor submissions, a records agent indexing inbound correspondence. Each ingests content written by people outside the agency.
Why does NIST treat malicious tools and skills as a supply chain problem?
Because the attack can land before anything executes. NIST notes that a tool's natural-language description is placed in the agent's context during planning, so a crafted description can bias tool selection even if the tool is never invoked.
Rogue MCP servers extend this. The draft describes attackers registering servers in public tool registries, and a "rug pull" variant that looks benign at install and silently changes its tool descriptions afterwards, with no new approval.
Skills get a separate entry for a specific reason.
NIST observes that a tool's output enters context as data, while a skill is loaded and followed as trusted guidance and may persist across sessions. Audits of public skill marketplaces have already found deliberately malicious skills.
We covered the measured size of that exposure in NVIDIA's SkillSpector and the agent skill supply chain, where a study of 31,132 skills found 26.1% with at least one vulnerability.
Do model-level AI safety defenses stop these agent attacks?
Not on their own, by NIST's account. The draft reviews model-level defenses that train a model to separate instructions from data, and concludes they "do not establish a strict boundary between benign and malicious content."
The supporting figure is stark: adaptive attacks designed against a specific defense bypassed twelve recent defenses with high success rates, most of which had originally reported near-zero attack success.
Computer-use agents fare no better. NIST cites a study in which agents clicked adversarial pop-ups in 86% of cases on average. A model that reads the screen can be instructed by the screen.
Which mitigations does NIST's draft actually recommend?
The defenses NIST describes as holding up are system-level, meaning they constrain the agent's architecture so untrusted content cannot drive its actions even when the model is fooled.
| Threat | Mitigation named in the draft | What an agency has to control to apply it |
|---|---|---|
| Untrusted data, indirect injection | Information-flow control, plan-then-execute, context minimization | The orchestration code that decides what reaches the model |
| Malicious tools and skills | Signed tool definitions with immutable versions, sandboxed tool execution | The tool registry and the execution environment |
| Malicious agents | Agent identity and authorization, least privilege, control-flow integrity | Permissions on every agent-to-agent and agent-to-system call |
| Long-horizon drift | A persistent safety context across an agent's history, cited as early research | The agent's memory and its full action history |
NIST is candid that these cost something: they "restrict the generality of the agent, and in most cases induce utility loss." It also calls multi-agent defenses understudied and long-horizon agent security an open research problem.
What should a government agency ask an AI agent vendor after this draft?
Every mitigation in the table above lives in the runtime, not in the model. So the questions belong in the solicitation, before award, not in a security review after go-live.
- Who approves a new tool or skill? If a vendor's marketplace can add or update one, the rug-pull scenario is inside your boundary.
- Can you inspect the orchestration code that separates trusted instructions from retrieved content, or only its documentation?
- Where does agent memory live, who can read it, and can you purge a poisoned record yourself?
- Is every tool call logged in a system your security team already monitors, and do you keep those logs when the contract ends?
A vendor can answer all four well while operating the stack for you. The point is that the answers have to exist in writing, and that the 18 December comment window is the moment to tell NIST which of them should become standard.
How does ibl.ai map onto NIST's agentic mitigations?
On ibl.ai you own all the code and the data. The stack is model-agnostic across any LLM, carries no per-seat pricing, and can deploy anywhere, from GovCloud to a fully air-gapped network.
That ownership is what makes NIST's system-level mitigations something an agency can apply rather than request. Tool access runs through an MCP broker with deny-by-default role-based access and audit logging, configured under Roles.
Code execution runs in an isolated Sandbox with credential injection, so secrets never sit in the agent's context. Skills are plain Markdown files your own staff write and review. Every query and action lands in the Audit log, inside your perimeter.
None of that removes the open problems NIST names. It means the agency holding the risk also holds the code, the memory and the logs. ibl.ai is family-owned and operated from New York, with engineers who build alongside your team.
Related reading: Enterprise agent security: what actually shipped in 2026 for the vendor side of the same problem, and air-gapped AI for federal agencies for the deployment model.