跳转到内容

安全、隐私与防护栏

智能体系统把能够解释自然语言的组件与私有数据、外部内容、凭据、软件接口和执行操作的能力连接起来。这带来了灵活性,也带来了新的安全问题:数据可能表现得像指令,指令也可能藏在数据中;如果没有其他组件强制执行边界,一段具有说服力的模型输出就可能转化为真实世界的操作或影响。

提示词注入(prompt injection)很重要,但它并不等于完整的威胁模型。常见的访问控制缺陷、不安全的默认配置、密钥或机密信息泄露、存在漏洞的依赖项、针对下游解释器的注入、多租户隔离薄弱以及审计记录缺失,同样可能危及系统。针对 AI 的控制必须建立在既有应用与基础设施安全之上,并对其加以补充,而不是取代它们。

在安全边界上,将每一项模型输入、输出、检索内容、记忆、接口返回结果和委托消息都视为不可信数据。安全来自于限制系统能够接触的数据和造成的影响、在模型判断之外强制校验每一项受保护操作,并采用分层控制,防止一个被操纵的决策演变为不可接受的后果。

防护栏可以降低风险,但“我们有防护栏”本身并不是一项安全属性。必须明确它针对的威胁、受保护资产、信任边界、强制执行点、失效时的行为、验证证据和残余风险。仅仅要求同一个模型安全行事,只能以概率方式影响模型行为,无法构成完整的强制执行机制。

从资产、参与者和可触达的影响入手

Section titled “从资产、参与者和可触达的影响入手”

威胁建模应针对完整系统,而不是只看一个聊天框。识别:

  • 资产:用户和企业数据、密钥与其他机密信息、身份、资金、文件、代码、基础设施、模型权重、提示词、策略、记忆、日志和声誉;
  • 参与者和威胁主体:终端用户、管理员、开发者、运营人员、模型和基础设施提供方、集成负责人、外部内容作者、已被攻破的服务、内部人员和攻击者;
  • 入口点:提示词、上传内容、网页、电子邮件、检索集合、记忆、反馈、模型输出、回调、API、插件、MCP 服务器、Skills、包注册表和供应链更新;
  • 主体与权限:每项操作使用谁的身份、代表谁执行、适用哪个租户和目的,以及谁可以委托或审批;
  • 信任边界:浏览器、模型提供方、应用、沙盒、执行代理、数据存储、队列、外部服务、租户、区域和管理平面;以及
  • 影响落点:不可信输入在这里转化为实际后果,例如数据披露、网络请求、文件或数据库写入、代码执行、支付、消息发送、权限变更、部署或持久化记忆。

追踪从输入来源到影响落点(source-to-sink)的现实攻击路径。对于只能总结公开文本的系统,一份植入恶意内容的文档造成的影响可能较低;但如果文档中的指令可以促使系统读取私有记录,再将其发送到攻击者控制的 URL,后果就会显著放大。OpenAI 当前关于提示词注入的安全文章采用了类似的来源到影响落点分析,并指出仅靠输入过滤无法遏制复杂的社会工程式攻击(OpenAI, 2026)。

按受影响的安全属性和后果对威胁分类,而不是按它们是否使用了“越狱”来分类。包括机密性、完整性、可用性、真实性、可问责性、隐私、用户安全、财务损失和失控。记录对提供方行为、模型可见性、租户隔离和人工审查的假设;假设不是控制。

提示词注入会跨越指令与数据的边界

Section titled “提示词注入会跨越指令与数据的边界”

直接提示词注入来自用户或 API 调用方。间接注入则藏在系统检索或观察到的内容中,例如网页、文档、电子邮件、工单、仓库、图片中的文字、Tool 返回结果、记忆或其他智能体的消息。被操纵的内容一旦写入记忆、工件、摘要或受信任集合,并继续影响后续运行,就形成了持久性注入。

核心困难在于语义。模型被设计用来解释自然语言,而没有任何分隔符、消息标签、转义约定或类似“忽略下面的指令”这样的短语,能够保证文本只会被当作数据处理。模型训练和分类器可以提升抵抗力,但自适应攻击者可以反复尝试,并将操纵与看似合法的任务上下文结合起来。

围绕偶尔会成功的攻击来设计:

  1. 标注信息来源和信任级别,使系统和模型能够区分控制系统行为的指令与作为证据使用的内容;
  2. 排除密钥、其他机密信息、大范围私有数据以及任务并不需要的能力;
  3. 防止不可信内容重新定义目标、权限、审批、策略或目标地址;
  4. 根据用户的实际请求和当前状态验证准备执行的操作及其影响;
  5. 通过非模型控制隔离代码、文件、网络、身份和租户;
  6. 在适当情况下,对具体且有后果的传输或操作要求显式确认;以及
  7. 监测、测试并响应新的攻击路径。

OpenAI 描述了分层防御,包括模型训练、监测、沙盒、链接和数据传输控制、确认以及红队测试(Understanding prompt injections)。Anthropic 同样把防御分为模型、模型处理的外部内容以及模型运行环境三个层面,并明确指出模型层保护不能单独发挥作用(Anthropic, 2026)。这些是提供方发布的当前系统说明,但不能证明任何提供方或特定模型能够免疫此类攻击。

在检测攻击之前先缩小影响范围

Section titled “在检测攻击之前先缩小影响范围”

最可靠的控制往往是让被攻破的决策威力变小。将最小权限应用于每次运行和每项操作:

  • 仅暴露策略允许且任务确实需要的接口和数据集合;
  • 在授予写权限之前,优先采用只读或仅提出方案的模式;
  • 按租户、资源、操作、目的、目标地址、金额、环境和时间范围限定授权;
  • 使用短期、范围受限的委托凭据,而不是环境中长期存在的用户或服务凭据;
  • 限制记录数、接收方、金额、请求数、Token 数、运行时间、子任务数量和调用速率;
  • 隔离可能造成重大后果的能力,避免一条被攻破的路径触达全部能力;以及
  • 当关键参数或状态发生变化时,要求重新授权。

把一个接口从模型视野中隐藏可以减少误选,但这本身不是授权机制。即便请求来自已被操纵的提示词、直接 API、过期队列项、子智能体或伪造回调,每一项受保护操作都必须在执行边界处接受检查。

防止高权限组件被借权滥用(confused deputy):系统不能仅因为权限较低或不可信的一方提出请求,就动用自身更广泛的权限。必须把发起主体、委托范围、租户、目的和用户意图一直传递到下游强制执行点。子工作流、插件、Skill、MCP 服务器或外部智能体不能获得父级本身不具备的权限,也只能获得完成任务所需的权限子集。

将凭据保留在模型不可见上下文之外

Section titled “将凭据保留在模型不可见上下文之外”

模型应当在看不到执行操作所需敏感凭据的情况下提出操作。在执行边界处:

  1. 认证发起主体和调用组件;
  2. 授权具体操作和当前参数;
  3. 从密钥管理服务或工作负载身份中取得范围严格受限的凭据;
  4. 通过受控客户端或代理调用目标;
  5. 防止响应把密钥或其他机密信息带回模型上下文;以及
  6. 记录策略决策和执行结果,但不要记录凭据。

不要将 API 密钥放入系统提示词、Tool 描述、记忆、不可信运行环境能够访问的文件、环境变量转储或追踪属性中。定期轮换凭据并确保可以吊销,分离开发与生产身份,同时检测异常使用。机密信息一旦进入模型,即使随后再脱敏,也可能已经传给模型提供方或留在遥测数据中。

网络出站访问(network egress)控制也是保护机密信息的一部分。攻击者要把数据带走,还需要一个可达的目标地址。任务边界明确时,应使用目标地址允许列表,阻止访问回环地址和云平台元数据服务,按策略处理 DNS 解析和重定向,限制协议与端口,并检查敏感数据是否正被发送给新的第三方。OpenAI 关于链接安全的研究说明,即使只是访问 URL,也可能通过路径或查询参数造成数据外泄(OpenAI, 2026)。

Shell、浏览器、代码解释器、文件编辑器和计算机操作能力都会暴露较大的影响面。运行环境的安全边界不能依赖生成的命令本身是否安全:

  • 适合威胁模型的临时容器、VM 或进程沙盒;
  • 带有独立读写范围的允许列表挂载;
  • 不暴露主机套接字、凭据目录、元数据端点或无关用户文件;
  • 非特权身份、系统调用和进程限制、配额和时间限制;
  • 受控的网络代理和 DNS 行为;
  • 可随时丢弃的工作状态,以及经过验证的工件导出机制;以及
  • 租户、运行和不可信代码之间的隔离。

沙盒(sandbox)并不是无条件的安全保证。内核、运行时、浏览器、代理和配置漏洞仍然存在;沙盒可能限制了文件系统写入,却仍允许数据外泄;挂载的仓库本身也可能包含密钥。应对具体沙盒实现进行威胁建模、及时修补漏洞、测试逃逸路径,并明确它实际提供哪些隔离保证。

Anthropic 的 Claude Code 材料使用文件系统和网络隔离来限制损害,即使提示词注入成功也是如此(Anthropic, 2025)。可以迁移到其他系统的经验,是在模型之外建立隔离边界,而不是照搬产品配置,更不是把沙盒理解成绝对安全。

在任务允许时,优先提供领域专用操作,而不是无限制命令。issue_refund(order_id, amount, reason) 可以比持有数据库凭据的 shell 脚本更可靠地校验资源归属、额度、策略和幂等性。开放式接口对于编码和调查仍然有用,但其数据、网络、凭据、生命周期和导出边界必须与潜在后果相匹配。

结构化输出可以减少歧义,但不代表其中的内容可信。使用前应校验语法、类型、长度、取值范围、枚举值、资源归属、状态版本、目标地址和业务不变量,然后再针对下游解释器进行安全编码或参数化处理。

绝不要将模型输出直接拼接到:

  • SQL、shell、HTML、模板、正则表达式或查询语言;
  • 文件路径、URL、头部、电子邮件收件人或访问控制规则;
  • 在合适沙盒之外执行的代码;或
  • 未经验证或缺少来源标记的策略、记忆、检索索引或审计记录。

使用参数化查询、安全 API、规范化路径检查、输出编码、模式验证和显式允许列表。一个生成看似正确 JSON 的模型,仍可能请求未授权资源。内容安全分类器也可能批准一段在另一个解释器中会变成命令注入的文本。

当模型输出成为另一个模型的上下文时,必须保留其来源和信任级别。多个智能体得出一致结论,并不能让攻击者控制的内容变得可信;如果这些智能体共享模型、信息来源、记忆或权限,这一点尤其重要。

在整个生命周期中设计数据隐私

Section titled “在整个生命周期中设计数据隐私”

隐私不只是输出过滤。应绘制数据从采集到模型输入、提供方处理、检索、记忆、日志、评估、支持、导出、备份和删除的全流程。针对每一类数据记录:

  • 目的以及适用时的合法或政策依据;
  • 数据主体、所有者、租户、地理位置、驻留要求和敏感性;
  • 谁可以访问它以及代表谁访问;
  • 哪个模型、提供方、区域、分包商或外部服务接收它;
  • 它是否会被保留、用于训练、缓存、生成嵌入或摘要,或者与其他数据合并;
  • 保留、删除、更正、导出和法律保全行为;以及
  • 下游副本和派生记录遵循该决定的证据。

只收集和披露任务所需的数据,并在提交给模型之前就完成数据最小化,而不是只在展示结果前处理。如果模型不需要原始身份信息,可以采用字段筛选、假名化标识符、数据令牌化、受保护引用、本地处理或聚合等方式。不能仅仅因为凭据允许访问,就检索整个邮箱或完整客户记录。

嵌入、摘要、标签、提示词、输出、记忆和追踪记录即使来自原始数据的加工,也仍可能属于个人数据或机密数据。删除源记录,却保留可搜索向量、评估案例、缓存和备份,未必符合系统承诺的删除规则。应记录数据的来源与流转,使更正和删除请求能够按需传递到下游副本。

隐私规则因司法辖区、行业、合同、年龄组和目的而异。NIST AI 600-1 提供了跨行业的风险管理考量,涵盖数据隐私、来源、价值链依赖和生成式 AI 生命周期风险,但它只是美国的自愿性风险管理资料,而非法律建议或通用合规清单(NIST, 2024)。

“防护栏”包含多种控制,而它们能够提供的保障程度差异很大。至少应区分:

防护栏类型 适用场景 重要限制
确定性验证 模式、限制、允许列表、状态谓词、签名 无法判断每一种语义或上下文危害
授权和策略引擎 主体、资源、操作、目的、目标地址和审批决策 依赖正确的身份、策略,以及所有受保护操作都经过强制校验
模型或分类器检查 语义内容、相关性、可疑指令、可能的泄露 具有概率性,会遭遇自适应攻击,也会受版本漂移和误判影响
输入转换 文件解析、规范化、恶意软件扫描、内容分离 转换可能丢失来源,且不能使语言变得可信
输出处理 安全编码、数据防泄漏(DLP)、引用与格式检查、针对影响落点的校验 如果副作用或提供方侧的数据泄露已经发生,再处理输出就为时已晚
沙盒和能力边界 限制文件系统、进程、网络、数据和影响范围 实现漏洞和过宽配置仍然存在
人工审批 结合具体上下文审查可能造成重大影响的决策,并明确责任 审批者可能疲劳、证据可能不足、说明可能受操纵,审批范围也可能不清楚
监测与速率控制 检测滥用并限制重复尝试或资源消耗 通常只是降低或发现伤害,而不是证明正确性

必须明确每道防护栏究竟会阻止、脱敏、收窄范围、请求确认、隔离、记录,还是只给出分数;同时说明超时或失效时如何处理。安全检查超时后不能悄悄放行。另一方面,如果低风险分类器每次故障都默认拒绝(fail closed),攻击者也可能借此影响系统可用性,因此失败策略必须与后果等级相匹配。

控制顺序同样重要。并行运行输入分类器可以降低延迟,但所有必需的阻断性检查完成之前,不得提交会产生实际后果的操作。输出过滤器无法收回已经通过 URL 或 Tool 调用发出的数据。每项控制都应尽量靠近它所保护的影响落点执行,并在关键状态发生变化后重新校验。

应使用具有代表性的正常、恶意、模糊、多语言、混淆和自适应案例来校准基于模型的防护栏。通过多次试验测量攻击成功率、误接受率、误拒绝率、模型拒绝请求的表现、功能损失、延迟和成本,并对模型、提示词、阈值和策略进行版本管理。绝不能把被监测模型的自我评价,作为它能够抵御攻击的唯一证据。

让审批成为有效的安全控制,而不只是点一下按钮

Section titled “让审批成为有效的安全控制,而不只是点一下按钮”

审批应把具备相应权限的人与具体操作、目标、披露的数据、金额、目标地址、状态版本、时间和后果绑定起来。审批界面应展示:

  • 将会发生什么,以及哪个系统将接收它;
  • 精确的敏感字段或外部影响;
  • 为什么需要该操作,以及哪些证据支持它;
  • 它是否可逆以及将如何被验证;以及
  • 自上次审批以来发生了什么变化。

不能让不可信内容直接决定审批界面展示的说明。关键字段应根据结构化状态和执行策略生成,清楚区分模型给出的解释与已经验证的事实,并突出可疑目标地址或范围变化。还应避免反复弹出低价值的确认提示,否则用户容易形成不经判断就批准的习惯。

审批不能把一个本身不安全的操作变安全。用户无法合理审查隐藏的数据流、编码后的载荷、成千上万项文件变更或范围宽泛的 shell 命令。应先采用确定性约束和受限接口,把人工判断留给人确实能够理解和评估的决策。

系统依赖的不只是一个模型端点。应清点并治理:

  • 模型、权重、提供方、适配器、系统提示词、策略和推理配置;
  • 框架、SDK、容器、浏览器、解释器、扩展和原生库;
  • Tool 和 MCP 服务器、插件、Skills、脚本、模板、注册表和清单;
  • 训练、微调、检索、评估、反馈和记忆数据;
  • 构建流水线、包源、工件存储、部署身份和更新通道;以及
  • 外部 API、托管搜索、向量存储、监测服务,以及提供人工运营服务的供应商。

核验发布方及所有权,固定或审批版本,扫描依赖项和工件,保护构建与发布身份,记录来源和许可证,关注安全公告,并在扩大访问权限前测试更新。注册表里的描述和清单只是一方声明,不能自动视为授权依据。还要审查嵌套脚本和传递依赖产生的网络行为,不能只看一个看似友好的包名。

英国 NCSC 与 CISA 及其他 17 个国家的机构共同制定的安全 AI 开发资料,涵盖安全设计、开发、部署、运营、供应链、资产、基础设施、监测和负责任披露(NCSC, 2023)。它是覆盖生命周期的通用材料,而不是某个组件安全性的认证。

数据供应链也需要同样的纪律。保留来源、访问控制、审查状态和转换历史。将受信任的策略材料与用户内容分离。检测投毒、未授权添加、大规模变更、异常检索影响,以及允许攻击者将生成内容提升为未来权限的反馈回路。

安全评估应检查端到端影响,而不只是模型是否说出了禁用短语。测试应围绕威胁场景构建:

  • 直接、间接、多语言、编码、视觉、多轮和持久性提示词注入;
  • 通过 URL、图像、DNS、错误信息、日志、文件、消息和已允许的第三方渠道进行数据外泄;
  • 权限提升、借用高权限组件实施越权、跨租户访问、过期审批和委托权限扩张;
  • 恶意 Tool 结果、MCP 服务器、Skills、依赖项、回调和受损子智能体;
  • 不安全的模型输出进入 SQL、shell、浏览器、模板、代码、路径和策略引擎;
  • 沙盒逃逸、发现挂载目录中的密钥、访问元数据服务、网络重定向和利用工件偷带数据;
  • 检索、记忆、反馈、评估和配置投毒;
  • 重复的自适应攻击、绕过速率限制、耗尽资源和成本消耗攻击;以及
  • 控制故障、超时、版本漂移、故障转移、回滚和事件遏制。

首先针对强制执行点建立确定性的单元测试和集成测试,再增加针对语义攻击和链式攻击的对抗性模拟,以及由专业人员开展的红队测试。既要用同一个输入来源测试多个影响落点,也要通过多个输入来源测试同一个影响落点。孤立的提示词注入基准测试可能漏掉产品中真正把操纵转化为危害的完整路径。

OWASP 的 2025 LLM Top 10 是一份有用的社区检查清单,涵盖提示词注入、敏感信息泄露、供应链、投毒、不当输出处理、权限或自主行为过度、向量与嵌入机制薄弱、错误信息和无边界资源消耗等风险(OWASP, 2025)。它是一套帮助建立安全意识的分类,不是完整的威胁模型或控制标准;勾选其中十项,也不能证明应用已经安全。

红队测试必须安全:隔离目标和租户,使用合成数据或授权数据,防止真实外部影响,与提供方协调,保留证据,并遵循负责任披露。模型、提示、策略、接口、数据、依赖项和沙盒发生变化后,应重新运行测试。随着系统和攻击者都在变化,安全声明也会衰减。

为威胁模型、身份、数据类、策略、沙盒、供应链资产、防护栏、漏洞和例外指定负责人。监测:

  • 被拒绝和被允许的高风险操作;
  • 异常的数据访问、目的地、凭据使用和跨租户尝试;
  • 提示词注入和数据外泄信号,但不能把检测器输出当作事实依据;
  • 模型、提示词、策略、权限、集成、数据和防护栏版本的变化;
  • 沙盒违规、网络出站请求被拒、输出校验失败和重复审批;
  • 误报造成的影响、用户手动绕过、例外规则的存续时间和控制可用性;以及
  • 已发现的漏洞、补丁状态和残余暴露。

《可观测性与事件响应》一章负责检测流水线、证据处理和协同响应。本章定义这些流程需要处理的安全信号和遏制控制。应保留足够的证据用于调查,但不能让安全日志变成另一个缺少治理的提示词、密钥和个人数据存储库。

选择 收益 成本或风险
广泛上下文和凭据 更多任务无需中断即可完成 提示词注入和信息泄露的影响范围更大
任务级窄委托 更强的最小权限和归因 更多策略、身份和集成工作
基于模型的语义防护栏 对开放式内容的灵活覆盖 概率性错误、漂移、规避、成本和延迟
确定性允许列表 对受限操作具有清晰保证 灵活性有限且维护负担较重
严格网络隔离 有效限制数据外泄 也会阻断正常的信息发现和外部依赖访问
用户确认 增加上下文控制和问责 摩擦、疲劳、操纵以及在大规模下薄弱的审查
完整安全日志 更丰富的调查证据 敏感数据集中和内部人员/访问风险
最小日志 更低的隐私暴露 更弱的检测、归因和取证
自动记忆 个性化和连续性 持久性注入、范围泄露、更正和删除负担
频繁组件更新 更快的修复和能力改进 供应链漂移和回归测试不足

系统要求模型忽略恶意指令,却允许它不受限制地接触私有数据、凭据和网络。

分类器批准了一个请求,于是执行器跳过了主体、资源、租户、目的和当前状态检查。

因为某个插件、MCP 服务器、Skill、模型或连接器出现在注册表中,或由管理员添加,它就被赋予了广泛权限。

模型看到的只是一个读操作,但受损的集成或生成的查询可能触达允许变更的凭据。

凭据被嵌入提示词或 Tool 返回结果中,随后出现在模型输出、追踪记录、记忆、提供方日志或攻击者控制的网络请求里。

被注入的文档为危险操作提供了看似合理的解释;接口在未验证目标、数据或影响细节的情况下展示了该解释。

文本经过过滤,影响落点仍然危险

Section titled “文本经过过滤,影响落点仍然危险”

内容通过了毒性或注入分类器,然后被拼接进 SQL、shell、HTML、URL 或访问控制表达式中。

文件系统写入虽然受到限制,但进程仍能读取挂载的凭据或私有源码,并发送到任意目标地址。

不可信的外部内容被摘要并作为受信任记忆存储,从而让持久性注入跨越未来会话。

相似度搜索先检索跨租户的私有候选项,等到排序之后甚至内容已经暴露给模型后才做权限过滤。

删除源数据,却保留所有派生物

Section titled “删除源数据,却保留所有派生物”

应用删除了主记录,却仍保留可搜索的嵌入、提示词、追踪记录、评估案例、缓存、备份和记忆。

系统只用一小组固定攻击做过一次测试并成功阻止,就宣布控制已经安全,却没有检查自适应攻击、端到端影响落点、正常请求的误报或重复试验结果。

为每一项有后果的能力维护一份安全与隐私设计记录

运行主张、用户和后果等级:
资产和不可接受的结果:
参与者、威胁主体、对手和假设:
输入来源、信任标签、转换和持久化存储:
数据类、目的、提供方、区域、保留和删除路径:
主体、委托权限、凭据和审批范围:
可触达的能力、影响落点、目标地址和外部影响:
从输入来源到影响落点的攻击路径:
确定性强制执行点和失效行为:
基于模型的防护栏、校准和已知错误率:
沙盒、文件系统、进程、租户和网络边界:
供应链清单、来源、版本和更新策略:
监测、遏制控制和证据策略:
对抗性测试、重复试验结果和残余风险:
负责人、例外授权、补偿控制和到期时间:

在审查期间使用一条简洁规则:

假设模型可以被说服。它能看见什么,能造成什么,以及哪一道非模型边界仍然能阻止不可接受的结果?

如果答案只依赖于模型拒绝,就应缩小数据或影响面,或添加可执行控制。

  • 威胁模型是否覆盖已组装的应用、传统软件风险、模型特有风险、供应链、运营人员和外部服务?
  • 受保护资产、参与者与威胁主体、权限主体、租户、信任边界、输入来源和可能造成后果的影响落点是否明确?
  • 是否已针对直接、间接、持久性和多智能体提示词注入,测试从输入来源到影响落点的完整路径?
  • 每次运行是否只获得其所需的数据、接口、目标地址、凭据、运行时间和影响范围?
  • 认证、授权、审批和凭据解析是否在访问时于模型判断之外强制执行?
  • 凭据是否未出现在模型上下文、不可信文件、追踪记录、记忆、错误和生成代码中?
  • 网络出站访问、重定向、元数据服务、DNS、协议和携带数据的 URL 是否受到控制?
  • Shell、浏览器、代码、文件和开放式接口是否根据其真实威胁和租户模型进行了隔离?
  • 模型输出是否针对每个下游影响落点完成校验和安全编码,而不是仅因采用结构化格式就被信任?
  • 来源和信任标签是否在检索、提取、摘要、记忆、委托和日志记录过程中得以保留?
  • 数据目的、最小化、提供方流转、区域、保留、更正、删除和派生副本是否已记录并实现?
  • 每个防护栏是否明确其针对的威胁、强制执行点、具体动作、超时、失效行为、验证证据和已知限制?
  • 基于模型的防护栏是否在良性与自适应恶意案例、语言、混淆、重复试验和版本变更上完成校准?
  • 审批是否显示已验证的操作、目标、数据、目标地址、后果、状态以及自上次审批以来的变化?
  • 模型、提示、策略、依赖项、容器、集成、Skills、MCP 服务器、数据和更新通道是否已清点并治理?
  • 是否对租户隔离、委托权限、子任务、回调和过期队列请求实施了端到端约束?
  • 安全测试是否验证了实际的数据外泄和外部影响,而不仅仅检查模型文本?
  • 红队环境是否经过授权、隔离、无破坏性,并与修复和回归案例相连?
  • 控制健康状况、拒绝记录、用户手动绕过、异常访问、目标地址、例外规则、漏洞和残余暴露是否可观测?