What attacks does NIST consider
In Chapter 4 on agentic systems, the authors examine attacks according to the stages of an agent’s operation, objectives, and attacker capabilities. An attacker may intervene in task formulation, planning, action execution, or the retrieval of tool outputs and the refinement of the subsequent plan.
Among the attacker’s objectives, NIST identifies loss of availability, loss of integrity, disclosure of sensitive data, and the use of an agent for malicious purposes. Availability, for example, can be compromised by causing an agent to call tools indefinitely. It will consume computational resources and be unable to complete the task. If integrity is compromised, an agent may alter the course of its work, produce a distorted result, or perform an action the user did not request.
The attack method depends on which system components or data the attacker has accessed.The authors consider several options.
Through the user request, the attacker attempts to bypass the model’s restrictions and induce the agent to perform a malicious action. A dangerous task, for example, can be broken down into outwardly innocuous steps that, when carried out together, lead to an outcome harmful to the system and desired by the attacker.
In the model supply chain, the attacker can replace or modify the model before it is incorporated into the agent system or during integration. To do so, they can poison the training data, tamper with the model itself, or interfere with the components used during fine-tuning.
Through untrusted data and memory, the attacker influences the agent’s behavior by placing false instructions in documents, web pages, and knowledge bases. The agent reads these materials while performing a task and may mistake the instructions found in them for an assignment. This is how indirect prompt injection works. By poisoning the long-term memory, the attacker ensures that the agent stores false information and uses it in subsequent tasks. This is one way to persist influence across the agent’s operating sessions (persistence).
Through tools and pluggable skills (skills), malicious instructions enter the tool description, the data returned by the tools, or the connected set of operating instructions and scripts. The agent may alter its plan under the influence of the tool description even before the tool is called.If malicious code is embedded in the tool itself, executing it may result in data theft or disruption of operation.
When multiple agents interact, an attacker may compromise one of them and use it to send forged messages to the others. If the other agents mistake these messages for legitimate instructions, the attack will also affect their actions.
A separate section is devoted to agents that operate for extended periods and preserve state between sessions. An instruction injected once will continue to affect the system, so it is important to monitor what the agent retains after an attack and how it uses that information in subsequent work cycles.
What security measures does NIST consider?
The authors consider defenses against forged instructions at both the model and system levels. The model is trained to distinguish a user’s request from instructions in untrusted content, however, carefully crafted attacks can bypass such defenses. To contain the consequences, data transmission and operation execution are restricted at the system level, even if the model has accepted and is executing an injected malicious instruction. The authors also separately consider isolating the execution of tools that may contain malicious code.
Restrictions on an agent’s actions naturally also affect its ability to perform useful tasks. Therefore, when designing a system, it is necessary to account for which operations will be prohibited and whether the agent will be able to function under those conditions. The authors also note that combining model- and system-level defenses requires further research.Sections 4.4–4.5 of the NIST project.
How to use the taxonomy when preparing tests
To determine whether the chosen defense will work in a specific system, testing is required. Let us consider how the NIST taxonomy can be used to prepare such tests using our hypothetical example. Suppose an agent is preparing responses to customers. It has access to an email service, but can send an email only after receiving approval from an employee. What happens if a document attached to the request instructs the agent to send the response immediately?
To assess the impact of the forged instruction, testers compare the performance of the same task with and without it, repeating both variants under identical system settings. The tool-call log is compared with the email service log to determine whether the agent attempted to send an email without approval. If the agent attempted to send the email but the email service rejected the request because employee confirmation was missing, the approval check worked on the service side. If the service nevertheless sent the email, the report should specify the conditions under which this occurred so that the team can reproduce the bypass and repeat the test after remediation. OWASP also recommends model-independent validation of whether an operation is permissible and human confirmation of actions with serious consequences in the description of the Excessive Agency risk category. LLM03:2026 Excessive Agency.
In the Russian project, such a check can be organized with reference to GOST R 56939-2024, which establishes general requirements for developing secure software. At the same time, the NIST taxonomy can be used as the primary or an additional source for selecting and describing relevant threats.In the threat model, we specify what the attacker targets and what an attack could lead to. During non-functional testing, we reproduce the attacker’s actions and record the test scenario, result, and scope in the report. Clauses 5.7.3.1, 5.19.2.4, and 5.19.3.2 of GOST R 56939-2024.
Based on the test results, the customer will be able to assess how the system responded to a specific attempt to send an email without approval and whether it blocked the email from being sent. This is one of the results that can support an assessment of trust in the system, while the balance between trust and effectiveness must also be assessed. GOST R 59276-2020 links trust to a broader question: does the system fulfil its assigned tasks to the required quality standard? Clause 3.3 of GOST R 59276-2020.
A final version will be released in due course
After discussion and refinement of the NIST project, the final version will be released. To apply the taxonomy in practice, it will be necessary to determine which of the described attacks are possible in a particular system and how to test its security. I have already presented one method for conducting such tests in the article about the OWASP guide.
Russian materials on threat modeling already exist. In its updated threat model for AI systems, Sber accounts for the risks of agentic and multi-agent systems, while Yandex describes threats and security measures for AI agents in AI-SAFE. The Consortium for Research into the Security of Artificial Intelligence Technologies has a working group on testing AI technologies. We look forward to further development of these approaches, including with reference to the NIST taxonomy.For the customer, recommendations are especially useful if they show how to link the tasks and authorities assigned to the agent with the test scenarios and the criteria for passing them.
