AI平台的零信任架构

在AI治理的框架下，AI平台的零信任架构已经从概念走向落地。当大模型开始接触企业数据，传统的"边界信任"安全模型已经失效：防火墙内并非净土，而AI让攻击面变得更大、更复杂、更隐蔽。

零信任对 AI 平台而言，具体意味着什么？

零信任的原则是：任何用户、设备、工作负载或网络位置默认都不可信；每一次访问决策都要显式做出，只授予所需的最小权限，并且以「某处已经发生了入侵」为前提。把这一原则应用到 AI 平台时，原则本身没有变，但几乎所有实现细节都变了，因为发出访问请求的东西不再只是人。

传统的企业系统拥有一组有边界的身份：员工、服务账号，以及少量集成。AI 平台则新增了几类边界时代的控制手段从未被设计去应对的东西：

• 代表用户行事的智能体。一个会读取文档、调用内部 API 并写入记录的系统，继承了用户的权限，却没有继承用户的判断力。你让它尝试什么，它就会尝试什么。
• 非确定性的执行路径。同样的输入，明天可能产生不同的工具调用序列。你无法预先批准一条在运行时刻才决定的路径，因此授权必须按动作来判定，而不是按会话来判定。
• 被当作数据对待的概率性输出。生成的文本会以「权威」的姿态进入下游系统。消费它的任何环节，都可能依据一段没有任何人撰写或审阅过的内容采取行动。
• 第三方模型端点。提示词与检索到的上下文会离开网络，交由供应商处理。这是一条承载着你最敏感的已拼装上下文的出站通道。
• 横跨信任域的检索面。一个由密级混杂的文档构建出的向量索引，可能因为一个无伤大雅的问题而把一段受限内容呈现出来。

由此得出的运维结论是：AI 的零信任更多关乎按动作的授权、数据溯源与输出处理，而不是网络分段。问题从「这个请求是否来自网络内部」转向了「这个具体动作、针对这条具体记录、由这个具体智能体、代表这个具体用户、在此时此刻是否被允许」。

能否把它做对，正是一个 AI 平台能否向整个组织开放、与只能锁在一个小试点团队手里之间的分界线。

为什么传统的边界控制对 AI 负载会失效？

边界安全假设你能区分内部与外部，并假设需要保护的贵重资产位于某道边界之后。在 AI 平台中，这两个假设都不成立。

边界消失了，但数据被拼装起来了。检索增强生成会刻意把来自多个来源的片段拉进同一个上下文窗口。每个来源可能各自都受到保护，但拼装出来的提示词却可能比其中任何一份文档都更敏感，因为它把它们组合在了一起。边界控制看到的是许多次已授权的读取；而 AI 系统看到的是一件必须被整体定密的复合制品。

授权现在要按动作判定，而不是按会话判定。一个被授权读取文档库的会话，并不因此就被授权把其中内容发邮件到外部。有了智能体在环里，这个区别恰恰就是最容易被模糊掉的那一处。智能体会去做任务所隐含的事，而任务隐含的范围，往往比用户手动去做时更广。

身份被委托并被串成链条。用户问助手，助手调工具，工具调 API，API 查数据库。到了第四跳，原始用户的权限已经以一种几乎没有系统记录的方式被传递了下去。没有显式委托令牌，每一跳都会以一个权限很宽的服务账号身份运行。

输出本身就是一条外泄通道。摘要、翻译和代码生成都是正当功能，却都能把敏感内容搬进一种看起来无害的形式里。一个被要求「把你看到的文档做个总结」的模型，会照做，而且做给任何提出这个要求的人。

务实的解读不是「现有控制没用了」，而是「它们是必要的，但已不再充分」。身份、分段和监控依然极其重要，只是它们已经覆盖不到那些属于概率性、委托式、检索驱动系统的失效模式。

AI 平台带来了哪些新的攻击面？

六个攻击面解释了大部分新增风险，每一个都有各自对应的控制手段，把它们混为一谈会导致买错工具。

1. 提示词注入，直接的与间接的。直接注入是用户构造输入来覆盖指令。间接注入危险得多：把恶意指令放进模型代表用户去处理的检索文档、网页或邮件里。模型无法可靠地区分「内容」与「指令」，因此缓解措施必须是结构性的——约束工具能做什么，而不是约束文本说了什么。
2. 工具与动作滥用。智能体拥有的每一种能力，都能通过语言被触达。如果一个智能体能发邮件、删记录或转钱，一次成功的注入就能触发这些动作。这里的控制关乎能力范围、人工审批阈值和幂等性，而不是过滤。
3. 跨密级的检索泄露。向量索引没有原生的密级概念。若在查询时刻不强制执行按文档粒度的访问控制，检索就会把请求者在源系统里根本打不开的内容呈现出来。这是 AI 平台评估中最常见的严重发现。
4. 训练与微调数据暴露。用于微调的数据可能被记忆并复述。敏感记录未经专门决策不应进入训练集，即便进了也应做记忆化评估。
5. 模型与依赖的供应链。开放权重模型、适配器、向量化模型以及围绕它们的软件包，全都是可执行的供应链。序列化格式与加载路径中的远程代码执行风险是真实存在的，不是理论上的。
6. 把输出消费当作注入载体。生成的内容经常被渲染进浏览器、作为代码执行，或送入另一个系统。请把每一个模型输出都当作消费它的系统的不可信输入。

请注意这份清单里缺了什么：模型权重本身。在实践中，常见得多的失效发生在周围的管道里——智能体被允许做什么、检索能呈现出什么、以及输出最终去了哪里。把注意力放在模型上而忽略管道的安全方案，总是会漏掉真正发生的事故。

如何为智能体与流水线建立身份与最小权限？

身份是一切其他控制所依赖的控制面。对 AI 平台而言，这项工作包含四个部分。

给每个智能体一个可验证的独立身份。不要共用服务账号。每个智能体定义、每个流水线阶段、每个工具连接器，都有自己的工作负载身份、自己的凭据、自己的审计轨迹和自己的吊销路径。当出问题时——而它一定会出问题——能够只吊销一个智能体而不停掉整个平台，这份价值就抵得过搭建成本。

让用户的身份在链路中传递下去。使用短时效、限定受众的委托令牌，而不是在第一跳就把用户上下文替换成服务身份。令牌中应当携带：原始用户是谁、他授权了什么、正在行动的是哪个智能体，以及一个以分钟计的过期时间。每一个下游服务都要校验令牌，并针对「用户加智能体」的组合身份做授权，而不只是针对智能体。

按任务而不是按系统来界定能力。一个回答发票问题的智能体需要读发票的权限。它不需要写权限，不需要访问薪酬数据，也不需要发邮件。为每个智能体定义一份能力清单——哪些工具、哪些数据域、哪些动作——并在工具网关处强制执行，而不是写在提示词里。

把读、写和不可撤销的动作分开。读权限可以在有良好审计的前提下放宽。写权限需要更严格的范围界定，并且通常需要幂等键。不可逆的动作——发送对外消息、执行付款、删除记录——应当要求显式的人工审批，并把请求内容、受影响的记录和推理过程一并展示给审批人。

有两个实现细节，其重要性远超表面所见。第一，在工具网关处强制执行授权，这样即使模型被攻陷或注入成功，也无法触达从未被授予的能力。第二，让委托令牌激进地过期；存活时间长于任务的令牌，会把一次性的范围化权限变成一个常设权限。

如何保护流入和流出模型的数据？

AI 的数据保护有三个不同的时刻，而大多数方案只处理了其中一个。

入：什么进入了上下文。被检索的文档必须带着密级一起走，而检索必须在结果到达模型之前就按请求者的密级做过滤。请在检索层强制执行，而不是对模型输出做事后过滤——到那时内容已经被处理过了。当数据源横跨多个密级时，应按密级维护独立的索引，而不是建一个混合索引再在上面加过滤；过滤的缺陷是无声的，而且是灾难性的。

处理：供应商看到了什么。要明确决定推理在哪里跑。对于敏感负载，使用一个提示词与补全结果不被留存、也不被用于训练的部署形态；优先选择私有或虚拟私有部署而非共享端点，并把这一决定记入风险登记册。当提示词必须流向第三方时，先剥离或令牌化直接标识符，并记录发送了什么。

出：什么回来了、去了哪里。生成的输出就是数据。对它套用与文档相同的密级与处理规则：在渲染前扫描敏感模式，限制它可以被存储或转发到哪些地方，并在可行时加水印。将被渲染进浏览器的输出，必须像对待任何其他不可信输入一样做转义。

再补充两项横切实践。把提示词与检索日志当作安全遥测来保存，套用与数据库审计日志相同的留存期与访问控制——它们往往包含着组织内最敏感的已拼装内容。以及为向量定义留存立场：向量表示可以被反推到足以还原出近似原文的程度，因此它们不是匿名制品，不应被无限期留存。

应该如何对 AI 平台做分段与监控？

分段与监控，是零信任从一份文档变成一种运维姿态的地方。

请沿三个轴而不是一个轴做分段：

• 环境。把 AI 的开发、评测与生产环境分开，各自使用不同的凭据、不同的数据，并且开发环境中不放生产数据。评测环境尤其常被忽略，而它往往含有生产样本。
• 数据域。按密级和按数据域把检索存储分开，这样营销索引被攻陷也不会波及财务或人力内容。
• 能力。把只能读的智能体与能写的智能体分开，再把两者与能执行不可逆动作的智能体分开。一个被注入攻陷的只读智能体，其爆炸半径远小于一个带写权限的智能体。

监控必须做相应调整，因为失效特征不同。传统安全监控寻找的是异常访问；AI 平台监控还必须寻找已授权身份的异常行为——某个智能体突然调用一个它从未用过的工具、检索量异常放大，或产出了触发内容过滤器的输出。

要专门针对被拒绝的动作设置告警。一个范围界定良好的智能体，几乎不该去尝试它无权做的事；拒绝次数的突然上升，要么意味着配置错误，要么意味着一次注入尝试，而两者都值得立即关注。

如何处理供应链与模型来源风险？

AI 平台是由许多并非你建造的组件拼装而成的：基座模型、适配器、向量化模型、智能体框架，以及围绕它们的一大棵依赖树。每一个都是一条可执行的供应链。

1. 维护带有来源信息的模型清单。对每一个在用的模型记录：来源、版本、许可协议、已知漏洞、谁批准的、以及它被允许处理什么数据。没有这份清单，你无法回答审计师「哪些模型接触过客户数据」的提问。
2. 锁定版本并校验校验和。模型文件与适配器应像任何其他制品一样被锁定并校验。未锁定版本的模型引用，是一条等着被人利用的远程代码执行路径。
3. 避免使用不安全的序列化格式。权重文件优先选择 safetensors 而非基于 pickle 的格式，并对任何在加载过程中允许可执行内容的格式做扫描。
4. 持续扫描依赖树。智能体框架迭代很快，其传递依赖迭代更快。带明确修复时限的自动化扫描是最低要求。
5. 显式评估托管与自托管。托管端点降低运维负担，但把风险集中到一个你必须评估的供应商身上。自托管带来控制权，却增加了一个你必须防守的运维面。无论选哪个都要记录理由。
6. 在敏感数据上微调之前先做记忆化测试。金丝雀测试——插入已知的唯一字符串、训练、再探测它是否出现——能对「模型是否复述了训练数据」给出一个可度量的答案。

有一项治理实践很快就能回本：要求任何新的模型、适配器或智能体框架都要经过一次评审，评审只问三个问题——它会处理什么数据、它能做什么、以及我们如何吊销它。大多数有风险的新增项都栽在第三个问题上，所以它放在最后问。

一套零信任 AI 平台参考架构长什么样？

把这些控制组装起来，会得到一套分层架构。层次顺序很重要：每一层都以下面那层为前提。

1. 身份与访问。企业级身份提供方，每个智能体与流水线各有工作负载身份，短时效委托令牌，以及按智能体划分的能力清单。以上一切都以这一层的正确性为前提。
2. 网关与策略执行。单一入口点，负责认证、按动作授权、执行速率与成本上限，并路由到模型。所有流量都经过它，没有任何请求能绕过。
3. 带按文档访问控制的检索层。按密级分段的索引，在查询时刻针对请求身份强制执行访问控制，并对查询与返回文档标识做完整记录。
4. 模型服务层。被锁定且经过校验的模型，运行在带有出站限制的隔离环境中，除检索层提供的通道外，不拥有对生产数据源的隐式访问。
5. 工具网关。每一个动作的授权点。校验委托链、检查能力清单、对不可逆动作执行审批阈值，并记录参数。
6. 输出处理。在生成内容被渲染或存储之前，对其执行定密、扫描、转义与去向控制。
7. 可观测性与响应。把提示词、检索、工具和输出日志当作安全遥测来对待，配备针对智能体异常行为的检测规则，以及一条经过演练的吊销路径。

其中最重要的单一设计属性是：工具网关是通向动作的唯一路径。如果一个智能体可以不经过它就触达某种能力，那么上述所有控制都能被一句足够巧妙的提示词绕过，而让提示词变得巧妙的成本极低。

同样重要的是那条经过演练的吊销路径。在一次事故中，真正有用的能力不是检测，而是在几分钟内、无需一次部署就能禁用某个智能体、吊销其凭据并保全其日志。从未演练过的团队，会在事故中才发现吊销竟然需要一次发版。

如何在不拖慢交付的前提下落地零信任？

零信任方案一旦被当成一道闸门来推行，就会失败。六项实践能让安全与交付同行。

1. 从资产清单开始，而不是从控制开始。列出每一个智能体、模型、数据源和工具连接，以及它们能触达什么数据、能做什么动作。大多数组织会由此发现一些自己都不知道存在的智能体，而单是这份清单就能消除很大一部分风险。
2. 先交付网关。让所有流量经过一个可强制执行的点，是杠杆最高的早期步骤，因为一旦有了单一的施加点，此后每一项控制都变得更容易。
3. 新智能体默认只读。让写权限和不可逆能力成为团队必须申请并论证的东西，而不是默认就能拿到的东西。这把常见模式倒了过来，并消除大部分意外的过度授权。
4. 在需要之前就建好审批通道。对不可逆动作的人工在环审批，应当在第一个具备该能力的智能体出现时就存在，而不是在事故之后才补上。
5. 提供一条铺好的路。给团队一个模板智能体，其中身份、日志、范围化能力和审批阈值都已经接好了。团队会绕开需要自己搭建的安全措施，却会采用开箱即用的安全措施。
6. 每个季度演练一次事件响应。做一次桌面推演：某个智能体被攻陷，必须被吊销。第一次演练总会暴露出吊销比预想的慢，而这正是你希望在演练中发现的东西。

衡量一个方案是否奏效的标准，不是部署了多少项控制，而是这个组织能否随着时间推移，安全地把更大的能力开放给更多的人。做得好的零信任不会缩小 AI 能做的事，它会让扩大 AI 被允许触及的范围变得安全。