--- title: "NIST's Agentic Attack Taxonomy: What Government Agencies Should Check Before Deploying AI Agents" slug: "nist-agentic-ai-attack-taxonomy-government-agencies" author: "Miguel Amigot" date: "2026-11-13 08:00:00" category: "Premium" topics: "NIST SP 2400-102e2026, NIST adversarial machine learning taxonomy, agentic AI security, AI agent attacks, memory poisoning, agent hijacking, malicious tools, malicious skills, MCP security, government AI agents, AI security for federal agencies" summary: "NIST's November 2026 draft of its adversarial machine learning taxonomy indexes 12 attack types against agentic systems across five attacker objectives, and its strongest mitigations are architectural, which turns an agency's agent security into a question of who operates the runtime." banner: "" thumbnail: "" linkedin: | NIST published the 2026 draft of its adversarial machine learning taxonomy on 9 November, and for the first time in that series the agentic part has its own attack index. Comments close 18 December. The index lists 12 attack types against agentic systems, filed under five attacker objectives: availability, integrity, privacy, misuse and supply chain. → Memory poisoning: one planted record can steer many later tasks, and a dormant payload can wait until a user raises a sensitive topic. → Malicious tools: a tool's description enters the agent's context before the tool ever runs. → Malicious skills: unlike tool output, a skill is followed as trusted guidance and can persist across sessions. → Decomposition attacks: a harmful task split into steps that each look benign. The line agencies should underline is NIST's own assessment of model-level defenses: adaptive attacks bypassed twelve recent defenses, most of which had reported near-zero attack success. The defenses that hold are system-level: information-flow control, sandboxed tool execution, least privilege, signed tool definitions. Those are properties of the runtime, not of the model. So the procurement question is who operates it, who can read its logs, and who approves a new tool. With ibl.ai you own all the code and the data, self-hosted inside your own perimeter, model-agnostic across any LLM, usage-based with no per-seat pricing, deployable anywhere from GovCloud to a fully air-gapped network. #iblai #AgenticAI #NIST #AISecurity #GovTech #PublicSector --- ## 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](https://csrc.nist.gov/pubs/sp/2400-102/e2026/ipd). 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](https://csrc.nist.gov/pubs/ai/100/2/e2025/final), was published in March 2025. The circulating "first taxonomy" framing overstates that. What is new is structure. The [full draft](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.2400-102e2026.ipd.pdf) 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](/blog/agent-skill-supply-chain-pre-deployment-scanning), 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](https://ibl.ai/docs/os/organization-settings/roles). Code execution runs in an isolated [Sandbox](https://ibl.ai/docs/os/agent-settings/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](https://ibl.ai/docs/os/analytics/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](/blog/enterprise-agent-security-what-shipped-2026) for the vendor side of the same problem, and [air-gapped AI for federal agencies](/blog/air-gapped-ai-for-federal-agencies) for the deployment model.* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.