Agentic Autonomy Levels and Security
Agentic workflows
are the next evolution in AI-powered tools. They enable developers to chain multiple AI models together to perform complex activities, enable AI models to use tools to access additional data or automate user actions, and enable AI models to operate autonomously, analyzing and performing complex tasks with a minimum of human involvement or interaction.
Because of their power, agentic workflows also present an element of risk. The most common model at the core of agentic systems remains some variety of LLM, which remains vulnerable to prompt injection if untrusted data can be introduced into the system.
To help assess and mitigate those vulnerabilities, NVIDIA presents an Agentic Autonomy framework, which we use for the following purposes:
Understand risks associated with increasing complexity of AI workflows
Help model and mitigate the risks posed by such workflows
Introduce how we use it to model threats to agentic systems
Explore how NVIDIA uses this framework for security for AI and more
cybersecurity use cases at NVIDIA GTC
.
Manipulating autonomous systems
In practice, exploitation of AI-powered applications requires two key components:
An adversary must be able to get their data (read: attack) into the system through some mechanism.
There must be a downstream effect that their malicious data can trigger.
When the AI component of the system is an LLM, this is commonly referred to as either direct prompt injection (the adversary and user are the same person) or indirect prompt injection (the adversary and the user could be different people).
However, similar threats exist for other types of AI models used in autonomous AI powered applications. Both flavors of prompt injection are rooted in the lack of separation between the control and data plane in the LLM architecture.
Direct prompt injection can be commonly seen in such examples as “Do Anything Now” (or DAN) prompts, which attempt to subvert safety and content filters trained into the model, and enable it to produce objectionable or unwanted content. These attacks typically only impact the active user’s session, and so typically have limited impact.
Indirect prompt injection, in which a threat actor causes their data to be included in another user’s session and thus takes control of the LLM’s behavior and productions, is more serious. This is often accomplished by targeting data sources used by retrieval augmented generation (RAG) tools, including internet search, such that documents containing malicious instructions are unknowingly included in the current user’s session. When the capability to manipulate another user’s session,– particularly LLM outputs, is combined with the use of tools, a significant number of new potential risks present themselves.
When potentially untrusted data enters an agentic system, any downstream actions taken by that system become potentially adversary-controlled.
Security and complexity in AI autonomy
Even before “agentic” AI became a distinct class of product offerings, the orchestration of AI workloads in sequences was commonplace. Even simple flows, such as an endpoint security product routing a sample to the correct AI powered analysis engine depending on file format, is arguably an example of such a workflow.
Because workflows such as these are deterministic, it’s straightforward to enumerate all possible paths, map out data flows, and isolate untrusted data from potentially risky actions that might be impacted by attacker-controlled data.
As the industry moves to systems that have more internal decision making capabilities, higher degrees of tool use, and more complex interactions between model components, the number of potential data flow paths increases exponentially, making threat modeling more difficult.
The following set of classification, ordering systems from least autonomous to most, distinguishes between different degrees of autonomy afforded by different architectures, and helps assess corresponding risks.
Autonomy level
Description
Example
0 – Inference API
A single user request results in a single inference call to a single model.
An
NVIDIA NIM microservice
serving a single model
1 – Deterministic system
A single user request triggers more than one inference request, optionally to more than one model, in a predetermined order that does not depend on either user input or inference results.
NVIDIA Generative Virtual Screening for Drug Discovery Blueprint
2 – Weakly autonomous system
A single user request triggers more than one inference request. An AI model can determine if or how to call plugins or perform additional inference at fixed predetermined decision points.
Build an Enterprise RAG Pipeline Blueprint
3 – Fully autonomous system
In response to a user request, the AI model can freely decide if, when, or how to call plugins or other AI models, or to revise its own plan freely, including deciding when to return control to the user.
NVIDIA Vulnerability Analysis for Container Security Blueprint
, “BabyAGI”, computer use agents
Table 1. System autonomy level classification
Level 1
Level 1 is a linear chain of calls, where the output of one AI call or tool response is conveyed to the next step in an entirely deterministic manner. The complete flow of data through the system is known in advance.
Figure 1. First level of autonomy
Level 2
In level 2, the output from the AI model may be sent along different paths through the workflow in a data-dependent manner. While every execution path can be traced, it’s not known until the workflow is executed which execution path is used.
Figure 2. Linear chain of AI calls and tool responses
It forms a directed acyclic graph in that there is no path through the workflow that could potentially form a loop or cycle. All possible paths can be finitely enumerated. Most LLM routers fall into this level.
Level 3
For level 3, the number of potential execution paths grows exponentially with the number of execution steps in the workflow. Tools or other AI models may be invoked as the workflow progresses.
Figure 3. Output from the AI model goes along different paths
The presence of a cycle within the directed graph means that an exponentially increasing (and, at least in theory, potentially infinite) number of paths through the graph exist. It’s generally not tractable to enumerate all possible paths ahead of time, nor predict which specific path will be used for a particular input.
Separation of security boundary analysis and tool security
Our early experience with analyzing and securing agentic systems in the field led us to realize that the risk associated with these systems lies mostly in the tools or plugins available to those systems. In the absence of a tool or plugin that can perform sensitive or physical actions, the primary risk posed by manipulation of the AI component is misinformation, regardless of the degree of complexity of the workflow.
This observation drives the primary difference between this framework, which focuses on security boundaries as being distinct from tool security, and other frameworks, such as that proposed by HuggingFace in their smolagents library (
Introduction to Agents
). Some levels align closely. Their
simple processor
is approximately a
deterministic system
and their
multi-step agent
maps closely onto a
fully autonomous system
.
However, this framework focuses on the difficulty of identifying security boundaries given the degree of autonomy expressed by an AI component in describing program flow. HuggingFace’s description of agency, by combining the risks of tool use with the complexity of program flow, provides a quick rubric to judge systemic risks at the level of the system. This framework’s approach of separating the risks of tool calling and tool use from the difficulty of drawing security boundaries supports more detailed threat modeling of complex flows and potential mitigations.
In the proposed framework, separating the following concerns enables you to more concretely assess the risk posed by an agentic workflow:
Security boundaries with respect to the flow of untrusted data through the system
Security properties of specific functions or tools that may be called by the agentic system
Within a simple deterministic system with clear security boundaries, even a sensitive plugin may be a fairly low-risk if you can clearly separate it from untrusted input. In a similar manner, even a fully agentic system may be relatively low-risk as long as no sensitive tools are available to it and the output of the system is appropriately validated before use.
The combination of a more complex workflow with sensitive tools, however, demands further analysis to ensure secure operation.
Threat modeling under this framework
Increasing autonomy levels do not inherently represent increasing risk. Instead, they represent increasing lack of determinism and predictability of the system behavior, which makes it more difficult to assess the impact of untrusted data.
Risk associated with agentic systems is located largely in the tools or plugins that the system has access to which can perform sensitive actions, including the following examples:
Completing a purchase
Sending an email
Physical actions such as moving a robot or setting a thermostat
Broadly speaking, anything that takes an action on behalf of a user that requires their delegated authorization to complete, or anything that results in a physical change in a system should be treated as potentially sensitive, and analyzed for its potential to act upon or be influenced by untrusted data.
Mitigation of this tool risk relies in large part on the ability to block the ability of attackers to inject malicious data into plugins, which becomes significantly more difficult with each increase in autonomy level.
Possible downstream effects are much more dependent on the details of the system and what plugins are being used, but at a minimum, a threat actor who can feed malicious data to the system must be presumed to be able to at least influence, if not control outright, the responses of the system.
If tools or plugins are being used, the potential threat increases significantly. A bad actor who can control the output of an AI model embedded in a system that uses tools might also be able to control which plugins are used and what actions those tools take. This can lead to a range of threats:
Data exfiltration, for example, through Markdown rendering plugins
Remote code execution, for example, through plugins that run LLM-provided code
The risk of physical harm, if the system has control or influence over some sort of physical system
As you climb the autonomy hierarchy, you need a more careful analysis of and management of potentially untrusted data (Figures 4 and 5).
A Level 0 system, with no vectors for untrusted data, is relatively straightforward from this perspective.
A Level 1 system, with a predetermined workflow, always accesses the same data sources, models, and tools in the same sequence, making it straightforward to determine if untrusted data can be introduced into the workflow. The designer can either isolate sensitive functionality from the untrusted data, or design appropriate sanitization strategies for that data.
The number of potential execution paths in a Level 2 system is greater than in Level 1 systems but still enumerable, and specific paths that contain untrusted data can be analyzed in greater detail.
Level 3 autonomous systems pose the largest difficulty, as the number of execution paths typically grows exponentially in the number of self-reflection steps performed by the agent. In this case, these include time-of-use sanitization, time-of-use taint tracing, or other risk mitigations such as requiring manual user approval of potentially hazardous actions.
Taint tracing
Taint tracing
is marking an execution flow as having received untrusted data and then either preventing use of or requiring manual re-authorization for any sensitive tool.
For Level 1 and Level 2 systems, identifying potential sources of untrustworthy data, and evaluating the risks of downstream impacts is relatively straightforward. When untrustworthy data enters the system, every downstream AI model and its associated outputs and every downstream tool and its associated actions and outputs are also untrusted.
Figure 4. Taints from untrusted sources can be bounded and enumerated in Level 1 and 2 systems
For level 3 systems, taint tracing in the general case becomes almost intractable. When untrusted data has been introduced into the workflow, it has the potential to propagate to any other downstream component through the looping structure inherent to level 3 workflows.
Figure 5. Taints from untrusted sources are difficult to bound and enumerate in Level 3 systems
By classifying an agentic application into the correct level, it becomes simpler to identify the overall level of risk posed by the application and corresponding security requirements.
Recommended security controls per autonomy level
Table 2 provides a high-level summary of some suggested mitigating controls that should be placed around agents of various autonomy levels. Not all controls are required for all agentic workloads, depending on the sensitivity of tools provided to the workload.
Autonomy level
Recommended security controls
0 – Inference API
Use standard API security.
1 – Deterministic system
Manually trace dataflows and order workflow correctly to prevent untrusted data from entering sensitive plugins.
2 – Bounded agentic workflow
Enumerate dataflows, identify ones with potentially untrusted data, explore isolation or sanitization options, and consider time-of-use manual approval of sensitive actions.
3 – Fully autonomous system
Implement taint tracing and mandatory sanitization of potentially untrusted data. Consider time-of-use manual approval of sensitive actions.
Table 2. Recommended security controls by level
For Level 0 systems, you can apply simple application and API security. Due to lack of further interaction taken by the system on the basis of AI model output, overall risk here is largely limited to non-AI components.
Level 1 and 2 systems provide a slightly elevated level of risk, but one that is straightforward to evaluate. Because these systems contain no loops, all execution flows through the systems can be exhaustively enumerated and examined for cases when untrusted data may flow into a sensitive tool.
Flows of this type are particularly risky when they pass through an LLM between the source and the sink. In level 1 systems, it’s often sufficient to reorder the workflow. For more complex (level 2) systems, risky flows from untrusted sources to sensitive sinks should be carefully evaluated to see if they can be eliminated, or otherwise if the untrusted data or input to the sensitive tool can be properly sanitized to remove risk.
Finally, if the flows cannot be rearranged or eliminated, or robust sanitization is not possible, add time-of-use manual approval to sensitive tools that may receive untrusted data, thus placing a human in the loop. This enables users of agentic workflows to inspect risky actions before they are performed and deny the workflow the ability to perform adversarially manipulated ones.
Level 3 systems, due to their complexity, typically cannot be meaningfully rearranged to block untrusted sources to sensitive sink flows. In this case, sanitization of untrusted data at time of retrieval should be implemented.
If possible, implementing taint tracing should also be considered. In the event that neither is possible, simply requiring that all potentially sensitive tools require manual approval before executing their function may be used as a last resort.
As with threat modeling, breaking agentic workloads into different complexity levels enables the quick determination of reasonable security controls to avoid the risk of having sensitive tools ingest untrusted data, including LLM outputs that have been manipulated by prompt injection.
Conclusion
As systems climb the autonomy hierarchy, they become more complex and more difficult to predict. This makes threat modeling and risk assessment more difficult, particularly in the presence of a range of data sources and tools of varying trustworthiness and sensitivity.
Identifying the system autonomy level provides a useful framework for assessing the complexity of the system, as well as the level of effort required for threat modeling and necessary security controls and mitigations.
It’s also important to analyze the plugins in the pipeline and classify them depending on their capabilities to provide an accurate risk evaluation based on the autonomy level.
代理自主级别与安全性
智能体工作流是 AI 赋能工具的下一次演进。它们使开发者能够将多个 AI 模型关联在一起以执行复杂的活动，使 AI 模型能够使用工具来访问其他数据或自动执行用户操作，并使 AI 模型能够自主运行，以尽可能减少人类参与或交互的方式分析和执行复杂的任务。
由于其强大的功能，代理工作流也存在风险因素。代理系统的核心最常见的模型仍然是各种 LLM，如果可以将不受信任的数据引入系统，这些模型仍然容易受到 prompt injection 的影响。
为帮助评估和缓解这些漏洞，NVIDIA 提供了一个 Agentic Autonomy 框架，我们将其用于以下用途：
了解与日益复杂的 AI 工作流相关的风险
帮助模拟和减轻此类工作流程带来的风险
介绍如何使用它对 agentic 系统的威胁进行建模
操控自主系统
在实践中，开发 AI 赋能的应用需要两个关键组件：
对手必须能够通过某种机制将其数据 (读取：攻击) 传入系统。
必须存在其恶意数据可能触发的下游影响。
当系统的 AI 组件是 LLM 时，这通常被称为直接提示注入 (对手和用户是同一个人) 或间接提示注入 (对手和用户可以是不同的人)。
然而，对于 AI 驱动的自主应用中使用的其他类型的 AI 模型，也存在类似的威胁。这两种提示注入的根源在于 LLM 架构中控制平面和数据平面之间缺乏分离。
直接提示注入通常出现在“Do Anything Now”（或 DAN）提示等示例中，这些示例试图颠覆训练到模型中的安全和内容过滤器，并使其产生令人反感或不需要的内容。这些攻击通常只影响活跃用户的会话，因此通常影响有限。
间接提示注入 (即威胁行为者将其数据包含在其他用户的会话中，从而控制 LLM 的行为和生产) 更为重要。这通常通过定位检索增强生成 (RAG) 工具 (包括互联网搜索) 使用的数据源来实现，这样就会在不知情的情况下将包含恶意指令的文档包含在当前用户的会话中。当操控其他用户会话 (尤其是 LLM 输出) 的能力与工具的使用相结合时，会出现大量新的潜在风险。
当潜在的不可信任数据进入代理系统时，该系统采取的任何下游操作都可能受到对手的控制。
AI 自主领域的安全性和复杂性
早在“代理式”AI 成为一类独特的产品之前，按序列编排 AI 工作负载就已屡见不鲜。即使是简单的流程 (例如端点安全产品，根据文件格式将样本路由到由 AI 驱动的正确分析引擎) 也可以说是此类工作流的示例。
此类工作流程具有确定性，因此您可以直接列举所有可能的路径，绘制数据流地图，并将不受信任的数据与可能受攻击者控制数据影响的潜在风险操作隔离开来。
随着行业转向拥有更多内部决策能力、更高工具使用率以及模型组件之间更复杂交互的系统，潜在数据流路径的数量呈指数级增加，从而增加了威胁建模的难度。
以下分类将系统从最不自主排序为最自主排序，可区分不同架构提供的不同自主程度，并有助于评估相应的风险。
自主级别
说明
示例
0 – 推理 API
单个用户请求会导致对单个模型进行一次推理调用。
为单个模型提供服务的 NVIDIA NIM 微服务
1 – 确定性系统
单个用户请求会按不依赖于用户输入或推理结果的预定顺序触发多个推理请求 (可以选择触发多个模型)。
NVIDIA
生成式虚拟筛选蓝图
2 – 弱自主系统
单个用户请求会触发多个 inference 请求。AI 模型可以确定是否或如何调用插件，或在固定的预定决策点执行额外 inference。
构建企业 RAG Pipeline Blueprint
3 – 全自主系统
根据用户请求，AI 模型可以自由决定是否、何时或如何调用插件或其他 AI 模型，或者自由修改自己的计划，包括决定何时将控制权交回给用户。
针对容器安全蓝图“BabyAGI”、计算机使用代理的 NVIDIA 漏洞分析
表 1. 系统自主级别分类
1 级
1 级是线性调用链，其中一个 AI 调用或工具响应的输出以完全确定的方式传输到下一步。通过系统的完整数据流是预先知道的。
图 1. 第一级自动驾驶
2 级
在第 2 级中，AI 模型的输出可能会以数据依赖的方式在工作流中沿不同路径发送。虽然可以追踪每个执行路径，但在工作流执行之前，我们不知道使用的是哪种执行路径。
图 2、AI 调用和工具响应的线性链
它形成了有向无环图，因为工作流中没有可能形成循环或循环的路径。所有可能的路径都可以有限枚举。大多数 LLM 路由器都属于这一级别。
3 级
对于级别 3，潜在执行路径的数量会随着工作流中执行步骤的数量呈指数级增长。随着工作流的进展，可能会调用工具或其他 AI 模型。
图 3、AI 模型的输出路径不同
有向图形中存在循环意味着图形中存在呈指数级增加（至少理论上可能是无穷大）的路径。通常无法提前列举所有可能的路径，也无法预测特定输入将使用哪种特定路径。
安全边界分析与工具安全性分离
我们早期在现场分析和保护代理系统的经验使我们意识到，与这些系统相关的风险主要在于这些系统可用的工具或插件。在缺乏可执行敏感或物理操作的工具或插件的情况下，无论工作流程的复杂程度如何，操作 AI 组件所带来的主要风险都是错误信息。
这一观察结果决定了此框架与其他框架 (例如 Hugging Face 在其 smolagents 库
(Introduction to Agents)
中提出的框架) 之间的主要区别，前者侧重于安全边界，而后者不同于工具安全边界。一些层次非常相似。他们的简单处理器近似为
确定性系统
，并且他们的多步骤智能体紧密地映射到完全自主的系统上。
但是，鉴于 AI 组件在描述程序流时表示的自主程度，此框架重点关注识别安全边界的难度。Hugging Face 对机构的描述将工具使用的风险与程序流程的复杂性相结合，提供了在系统层面判断系统风险的快速指南。此框架将工具调用和工具使用的风险与绘制安全边界的难度分开，支持对复杂流程和潜在缓解措施进行更详细的威胁建模。
在建议的框架中，通过分离以下问题，您可以更具体地评估由 agentic workflow 带来的风险：
与通过系统的非可信数据流相关的安全边界
代理系统调用的特定函数或工具的安全属性
在具有明确安全边界的简单确定性系统中，如果您能够将敏感插件与不信任的输入明确分开，即使是敏感插件也可能风险较低。同样，只要没有可用的敏感工具，且系统的输出在使用前经过适当验证，则即使是全代理系统也可能相对风险较低。
然而，将更复杂的工作流程与敏感工具相结合需要进行进一步分析，以确保安全操作。
此框架下的威胁建模
自动驾驶级别的增加本身并不代表风险的增加。相反，它们代表着系统行为越来越缺乏确定性和可预测性，这使得评估不可信任数据的影响变得更加困难。
与代理系统相关的风险主要存在于系统可以访问的工具或插件中，而这些工具或插件可以执行敏感操作，其中包括以下示例：
完成购买
发送电子邮件
物理动作，例如移动机器人或设置 thermostat
从广义上讲，任何代表用户采取行动且需要其授权才能完成的操作，或任何导致系统发生物理变化的操作，都应被视为潜在的敏感数据，并分析其对不受信任数据采取行动或受其影响的可能性。
降低此工具风险在很大程度上依赖于能否阻止攻击者向插件中注入恶意数据，而随着自主级别的提升，这一能力会变得更加困难。
可能的下游影响更多取决于系统的细节和使用的插件，但至少必须假定能够向系统提供恶意数据的威胁行为者至少能够影响（如果不是完全控制）系统的响应。
如果使用工具或插件，潜在威胁会显著增加。控制嵌入到使用工具的系统中的 AI 模型的输出的坏行为者也可能能够控制使用哪些插件以及这些工具执行哪些操作。这可能会导致一系列威胁：
数据泄漏，例如通过 Markdown 渲染插件
远程执行代码，例如，通过运行 LLM 提供的代码的插件
如果系统控制或影响某种物理系统，则会产生物理伤害风险
在提升自主层次结构时，您需要更仔细地分析和管理潜在的不可信任数据（图 4 和图 5）。
从这个角度来看，没有不可信数据向量的 Level 0 系统相对简单。
具有预定工作流的 1 级系统始终可以按相同顺序访问相同的数据源、模型和工具，从而可以直接确定是否可以将不可信任的数据引入工作流。设计师可以将敏感功能与非可信数据隔离开来，或者为这些数据设计合适的清理策略。
2 级系统中的潜在执行路径数量大于 1 级系统，但仍可枚举，并且可以更详细地分析包含非可信数据的特定路径。
3 级自主系统的难度最大，因为执行路径的数量通常随智能体执行的自反射步骤的数量呈指数级增长。在这种情况下，这些措施包括使用时间清洁、使用时间污点追踪或其他风险缓解措施，例如要求用户手动批准潜在的危险操作。
污点追踪
污点追踪
将执行流程标记为接收了不可信任的数据，然后阻止对任何敏感工具的使用或要求对其进行手动重新授权。
对于 1 级和 2 级系统，识别潜在来源的不可信数据，以及评估下游影响的风险相对简单。当不可信数据进入系统时，每个下游 AI 模型及其关联输出、每个下游工具及其关联操作和输出也同样不可信。
图 4、不可信来源的污点可以在 Level 1 和 Level 2 系统中进行限制和列举
对于 level 3 级系统，在一般情况下，污点追踪几乎难以解决。当不受信任的数据引入工作流后，它有可能通过 level 3 级工作流固有的循环结构传播到任何其他下游组件。
图 5、来自不可信来源的污点很难在 Level 3 级系统中绑定和列举
通过将代理应用程序分类为正确的级别，可以更简单地识别应用程序构成的总体风险水平以及相应的安全要求。
每个自主级别的推荐安全控制
表 2 简要概述了一些建议的缓解控制，这些控制应放置在不同自主级别的 agents 周围。并非所有 agents 工作负载都需要所有控件，具体取决于为工作负载提供的工具的灵敏度。
自主级别
推荐的安全控制
0 – 推理 API
使用标准 API 安全性。
1 – 确定性系统
手动追踪数据流并正确订购工作流，以防止不受信任的数据进入敏感插件。
2 – 有界限的代理工作流
列举数据流、识别具有潜在不可信任数据的数据流、探索隔离或清理选项，并考虑使用时间手动批准敏感操作。
3 – 全自主系统
实现污点追踪和强制清理对可能不可信的数据。考虑使用时间手动批准敏感操作。
表 2. Recommended security controls by level
对于 0 级系统，您可以应用简单的应用程序和 API 安全性。由于系统无法根据 AI 模型输出进行进一步交互，因此整体风险主要局限于非 AI 组件。
1 级和 2 级系统的风险水平略高，但评估起来很简单。由于这些系统不包含循环，因此可以详尽无遗地列举和检查流经系统的所有执行流程，以备不时之需。
当此类流通过源和接收端之间的 LLM 时，风险特别大。在 1 级系统中，通常只需重新排列工作流程即可。对于更复杂（2 级）的系统，应仔细评估从不受信任的来源到敏感汇的风险流，以确定是否可以消除这些流，或者是否可以适当清除不受信任的数据或敏感工具的输入，以消除风险。
最后，如果流程无法重新排列或消除，或无法进行可靠的清理，请为可能会接收不受信任数据的敏感工具添加使用时间手动审批，从而让用户进入循环。这使得代理工作流的用户能够在执行风险操作之前检查这些操作，并使工作流无法执行对抗性操作。
由于 Level 3 级系统的复杂性，通常无法进行有意义的重新排列，以将不受信任的源阻塞到敏感的接收流。在这种情况下，应在检索时清除不受信任的数据。
如果可能，还应该考虑实施污点追踪。如果两者都无法实现，则仅要求所有潜在敏感的工具在执行其功能之前需要手动批准即可将其用作最后手段。
与威胁建模一样，将代理工作负载分解为不同的复杂性级别有助于快速确定合理的安全控制，从而避免让敏感工具提取不受信任数据 (包括通过提示注入操作的 LLM 输出) 的风险。
结束语
随着系统对自动驾驶层次结构的要求越来越高，这些层次结构变得越来越复杂，预测难度也越来越大。这使得威胁建模和风险评估变得更加困难，尤其是在存在各种数据源以及具有不同可靠性和灵敏度的工具的情况下。
确定系统自主级别为评估系统复杂性、威胁建模以及必要的安全控制和缓解措施所需的工作量水平提供了有用的框架。
分析管道中的插件并根据其功能对其进行分类也很重要，以便根据自主级别提供准确的风险评估。