模块五：传统网络安全在 AI 时代的升级

模块五：传统网络安全在AI时代的升级模块概述前四个模块，我们深入了PromptInjection、Agent威胁建模、攻防实战——这些是AI安全特有的新挑战。但一个容易被忽视的事实是：AI系统首先是软件系统，它运行在服务器上、通过网络通信、调用API、访问数据库。传统网络安全的“老兵”——ZeroTrust、IAM、网络分段、API安全——在AI时代不仅没有过时，反而因为Agent的引入而变得更加关键。本模块将帮你完成一次“传统安全技能的AI化升级”。你会学到如何将ZeroTrust架构的三大原则映射到AI系统中，如何为AIAgent设计Non-HumanIdentities和最小权限策略，如何通过网络微隔离限制Agent被攻破后的横向移动，以及如何加固AI服务暴露的API。最后，你将亲手为一个AI服务设计完整的ZeroTrust安全策略。学习目标：理解ZeroTrust架构在AI系统中的适用性和特殊要求掌握Non-HumanIdentities的管理方法，能够为AIAgent设计身份、权限和审计链路能够设计网络分段和微隔离策略，限制Agent被攻破后的影响范围掌握AI服务API的安全加固措施，能够防御常见的API层攻击能够为一个生产级AI服务设计并配置ZeroTrust安全策略5.1ZeroTrustArchitectureforAI系统5.1.1为什么传统边界安全在AI时代彻底失效传统安全模型的核心假设是：网络内部是安全的，威胁来自外部。所以防御策略很简单——建一道防火墙，把内外隔开，内部流量默认信任。这个模型在AI时代失效，原因有三个：第一，AIAgent本身就是“不可信内部实体”。在传统模型中，内部服务之间的调用是受信任的。但一个被PromptInjection攻破的Agent，虽然运行在“内部”，其行为却可能完全是攻击者操控的。如果你默认信任Agent发出的数据库查询，你就等于默认信任攻击者。第二，AI系统的边界是模糊的。一个RAG架构的AI知识助手，需要实时检索外部知识源；一个代码Agent需要访问GitHub仓库；一个数据分析Agent需要连接外部API。这些外部连接让“内外”边界变得模糊不清。第三，攻击者的横向移动路径更短。在传统系统中，攻击者从Web服务器横向移动到数据库服务器，至少需要利用一个漏洞。在AI系统中，Agent本身就拥有调用多个后端服务的权限——攻击者一旦通过PromptInjection控制了Agent，就“免费”获得了这些横向移动能力。ZeroTrust的核心理念正是为这种环境而生的：永不信任，始终验证。每一个请求——无论来自外部用户还是内部Agent——都必须经过认证、授权和加密。这一原则在AI系统中比在任何传统系统中都更迫切。5.1.2ZeroTrust三大原则在AI系统中的映射ZeroTrust有三大经典原则。在AI系统中，它们需要被重新解释：原则一：验证显式（VerifyExplicitly）传统理解：基于所有可用的数据点（用户身份、设备健康状态、位置、异常检测）进行认证和授权。在AI系统中的映射：不仅验证“谁在发请求”（用户身份），还要验证“请求经过了哪些Agent代理”、“Agent当前的行为模式是否与正常基线一致”、“请求的Prompt是否通过了注入检测”。这意味着AI系统的认证不再是一次性的登录验证，而是每一次Agent的工具调用、每一次对后端服务的访问，都需要独立验证调用链上每一环的合法性和可信度。原则二：最小权限（UseLeastPrivilege）传统理解：只授予完成任务所需的最小权限。在AI系统中的映射：这是模块三已经深入讨论的主题，但这里需要补充一个关键点——最小权限不是“Agent配置时设置一次就完事了”，而是每次工具调用时动态评估的。一个客服Agent在回答“你们的营业时间是几点”时需要的权限，和回答“帮我查一下我昨天那笔交易的状态”时需要的权限，是完全不同的。AI系统的权限控制必须从“角色级”进化到“请求级”。原则三：假设已被入侵（AssumeBreach）传统理解：设计系统时假设攻击者已经在内部网络中，通过分段、加密、监控来限制爆炸半径。在AI系统中的映射：假设任何一个Agent都可能被PromptInjection攻破。基于这个假设，你需要做以下设计：每个Agent只能访问自己的“信任域”，无法越界Agent之间的通信必须加密和认证，不能因为是“同一个系统内的Agent”就裸奔所有Agent的操作被完整记录，形成不可篡改的审计日志高敏感操作必须在Agent和被操作资源之间加入一个“Agent无法影响的人类决策点”5.1.3AI系统的ZeroTrust参考架构以下是一个将ZeroTrust原则全面植入AI系统的参考架构：┌─────────────────────────────────────────────────────────┐

│ZeroTrustAI系统│

││

│用户→[身份验证]→[策略决策点]→[AI服务]│

│↓↓↓│

│MFA+动态授权Agent隔离│

│设备合规+行为分析+权限边界│

││

│AgentA←→[mTLS]←→AgentB（服务间通信加密）│

│↓↓│

│[策略执行点][策略执行点]│

│↓↓│

│数据库AAPIB│

│(只读,有限行)(限流+校验)│

││

│所有访问日志→[SIEM/审计系统]←实时异常检测│

└─────────────────────────────────────────────────────────┘这个架构的核心思想是：在用户和资源之间、Agent和资源之间、Agent和Agent之间，每一跳都部署策略决策点和策略执行点。没有“隐式信任”，没有“默认放行”。5.2Non-HumanIdentities：AIAgent身份治理5.2.1什么是Non-HumanIdentity（NHI）在传统的IAM体系中，“身份”通常对应一个人类用户或一个服务账号。但AIAgent的身份特征与两者都不完全重叠：它不是人类用户：Agent没有“入职”“离职”的HR流程，它的生命周期可能只有几小时甚至几分钟它不是静态的服务账号：传统服务账号通常长期存在、权限稳定。而Agent可能被按需创建和销毁，其权限需求随任务变化这就是Non-HumanIdentity（NHI）——为AIAgent、自动化脚本、微服务等非人类实体设计的专用身份体系。2026年，NHI管理已成为AI安全领域最热门的子课题之一。5.2.2NHI管理的核心挑战挑战一：Agent数量爆炸。在多Agent系统中，一个用户请求可能触发路由Agent创建3个子Agent，每个子Agent可能在完成任务后自动销毁。这意味着IAM系统需要能够处理高频的身份创建和销毁，而不留下“孤儿身份”。挑战二：权限的动态性。同一个Agent，在处理任务A时可能只需要读取用户表，在处理任务B时可能需要读取订单表和调用支付API。静态的角色绑定无法满足这种动态需求。挑战三：可追溯性。当审计日志显示“AgentX在14:32查询了用户表”，安全团队需要回答的是：“AgentX当时在执行哪个用户的哪个请求？经过了多少层代理？”——这要求NHI系统能够记录完整的身份代理链。5.2.3身份代理链在AI系统中，一次操作的真实发起者可能经过了多层代理：用户Alice→路由Agent→研究员Agent→数据库身份代理链的核心原则是：下游服务看到的“调用者”不应该是最后一个Agent，而应该是完整的代理链。权限决策应该基于原始用户（Alice）的身份和权限，而不是中间Agent的身份。实现方式：每个Agent在调用下游服务时，必须在请求头中携带完整的代理链信息（如X-Proxy-Chain:user=alice;agent=router;agent=researcher）下游服务的策略执行点解析代理链，提取原始用户身份，基于该用户的权限进行授权所有中间Agent的身份也必须被记录，用于审计5.2.4动态授权与短期凭据AIAgent不应持有长期有效的静态凭据（如写入配置文件的APIKey）。推荐实践：短期凭据：Agent启动时，通过身份代理服务获取一个短期有效的访问令牌（如1小时），过期后需要重新获取。动态授权：每次工具调用前，Agent向策略决策点发起授权请求。策略决策点综合评估：原始用户是谁、Agent的角色是什么、请求的操作是什么、当前的时间/位置/行为基线是否正常，然后返回“允许”或“拒绝”。凭据的安全注入：凭据不应该写在Agent的配置文件中，也不应该出现在Agent可能通过PromptInjection泄露的上下文里。推荐使用WorkloadIdentity机制（如SPIFFE/SPIRE、云厂商的实例身份服务），让Agent的运行环境本身成为它的身份证明。5.2.5NHI治理Checklist所有AIAgent拥有独立的Non-HumanIdentity，不共享账号Agent的身份凭据有明确的有效期，过期自动失效Agent销毁时，其身份和凭据被同步清理所有Agent的操作日志中记录完整代理链（用户→Agent→下游服务）动态授权策略在每次工具调用前执行，不依赖Agent的“自觉”定期审计Agent的身份和权限，回收未使用或过度的权限5.3网络分段与微隔离5.3.1为什么AI系统需要比传统应用更细粒度的网络控制在传统三层架构（Web→App→DB）中，网络分段通常只需要三个安全域。但在AI系统中，Agent的数量和交互关系远比传统应用复杂。如果所有Agent都在同一个网络段内，一旦某个Agent被攻破，攻击者可以：扫描并探测所有其他Agent的API端点直接访问共享的记忆存储或知识库拦截或篡改Agent之间的通信以被攻破的Agent为跳板，攻击后端数据库网络分段和微隔离的目标是：将“一个Agent被攻破”的影响范围，限制在该Agent所在的最小网络段内。5.3.2微隔离策略设计策略一：基于身份的Agent间通信白名单不使用IP地址作为通信策略的基础（Agent的IP可能动态变化），而是基于Agent的身份（NHI）定义通信策略。以模块三的SmartBank系统为例：源Agent目标Agent/服务是否允许理由路由Agent查询Agent✅允许正常业务流路由Agent操作Agent✅允许正常业务流查询Agent操作Agent❌拒绝查询Agent不应直接触发交易任何Agent记忆存储✅允许（但需校验读写权限）正常功能任何Agent审计日志系统❌拒绝所有非日志Agent审计日志应该是只被日志收集器写入的隔离系统策略二：网络策略的分层实施在Kubernetes环境中，可以通过NetworkPolicy或CiliumNetworkPolicy实现细粒度的网络控制：#示例：限制查询Agent只能访问数据库的特定端口，

#且只能被路由Agent访问

apiVersion:cilium.io/v2

kind:CiliumNetworkPolicy

metadata:

name:query-agent-policy

spec:

endpointSelector:

matchLabels:

agent:query

ingress:

-fromEndpoints:

-matchLabels:

agent:router

toPorts:

-ports:

-port:"8080"

egress:

-toEndpoints:

-matchLabels:

service:accounts-db

toPorts:

-ports:

-port:"5432"策略三：隔离敏感组件以下组件必须部署在独立的、与其他Agent严格隔离的网络段中：记忆存储和知识库：虽然Agent需要访问它们，但访问必须经过API网关而非直接数据库连接审计日志系统：应该是一个“只进不出”的隔离环境，Agent只能写入，不能读取或删除人类审批网关：必须部署在Agent无法访问的独立网络段，防止被攻破的Agent绕过审批5.3.3东西向流量监控在网络分段的基础上，必须对所有东西向流量（Agent到Agent、Agent到后端服务）进行监控。2026年推荐实践：在ServiceMesh层启用mTLS加密所有Agent间通信在ServiceMesh的Sidecar中记录访问日志，包含：源身份、目标服务、请求内容摘要、响应状态设置异常检测规则：如果某个Agent突然开始访问它从未访问过的服务，触发告警定期审查网络策略日志，发现并回收未使用的通信权限5.4API安全：AI服务的“最后一道大门”5.4.1AI服务API的独特风险无论是LLM推理API、RAG检索API，还是Agent的工具调用API，AI服务暴露的API都是攻击者最直接的入口。与传统API相比，AI服务的API有几个独特风险：风险一：Prompt作为API参数。用户输入的Prompt是通过API传入的。如果API没有输入验证，攻击者可以在Prompt参数中发送超长文本（导致ModelDoS）、恶意指令（PromptInjection）、或编码后的攻击载荷。风险二：输出包含不可信内容。AIAPI的响应内容由模型生成，可能包含恶意代码、错误信息、或泄露的敏感数据。API消费者如果直接信任这些输出，可能被间接攻击。风险三：流式响应的安全处理。许多LLMAPI使用Server-SentEvents（SSE）或WebSocket提供流式响应。流式传输中的安全校验比一次性响应更难——你需要在内容被逐步生成时就进行实时检测，而不是等全部生成完毕。5.4.2API安全加固措施认证与授权所有AIAPI端点必须要求认证。绝不暴露未认证的LLM推理接口。使用OAuth2.0+JWT进行用户到API的认证，使用mTLS或SPIFFE进行服务到服务的认证。不要在URL参数中传递APIKey。使用Authorization请求头。为每个API消费者分配独立的APIKey（如果使用APIKey方案），且APIKey应具有速率限制和使用范围限制。输入验证对Prompt参数强制最大长度限制（Token数量上限）。对请求体进行Schema验证——拒绝不符合预期JSON结构的请求。扫描输入中的已知恶意模式（结合模块四的Guardrails输入模块）。对非文本输入（图片、音频）进行格式验证和文件大小限制。速率限制与资源保护按用户、按APIKey、按IP实施多层级速率限制。为LLM推理API设置“每个请求的最大Token数”硬限制。设置并发请求上限，防止单个用户耗尽推理资源。监控并告警：某个API消费者的请求模式突然变化（如从每分钟10次突增到1000次）。输出安全处理在API响应中设置安全相关的HTTP头：Content-Security-Policy、X-Content-Type-Options等。对于流式响应，使用流式内容过滤器，逐段检测输出中是否出现敏感信息或恶意模式。在API响应中包含“内容来源”和“置信度”元数据，让API消费者能够判断输出的可信度。5.4.3API网关作为AI安全的策略执行点2026年推荐的最佳实践是：将所有AI服务的API置于统一的API网关之后，在网关上集中实施安全策略。API网关应承担以下安全职能：认证与授权（验证JWT、执行OAuth流程）速率限制输入验证（拒绝不符合Schema的请求）请求/响应日志记录（用于审计和异常检测）集成Guardrails模块（请求进入LLM之前、响应离开网关之前，经过安全检测）实验五：为AI服务配置ZeroTrust策略实验目标假设你是一家企业的安全架构师。公司即将部署一套名为“LegalBot”的AI法律助手服务，该服务能够回答员工关于公司内部法律政策的问题，并通过RAG检索内部法律文档。你的任务是为LegalBot设计一套完整的ZeroTrust安全策略，覆盖身份、网络、API和权限四个维度。实验场景设定LegalBot系统架构：员工→[企业SSO]→API网关→LegalBotAgent→法律文档知识库（RAG）

↓

审计日志系统安全要求：只有经过企业SSO认证的员工才能使用LegalBotLegalBotAgent自身不能访问互联网，只能访问法律文档知识库法律文档知识库包含“公开政策”和“机密法律意见”两类文档。普通员工只能检索“公开政策”，法务部门员工可以检索全部所有对LegalBot的请求和Agent的检索行为必须被记录LegalBotAgent不能删除或修改知识库中的任何文档实验步骤第一步：设计NHI和权限策略（20分钟）为LegalBotAgent创建一个Non-HumanIdentity，命名并描述其生命周期设计LegalBotAgent的最小权限策略：它需要哪些权限才能完成工作？哪些权限是绝对不应授予的？设计动态授权逻辑：当普通员工和法务部门员工分别使用LegalBot时，Agent的知识库检索权限应如何动态调整？画出身份代理链：员工→API网关→LegalBotAgent→知识库，标注每个环节的身份传递方式第二步：设计网络分段方案（15分钟）画出LegalBot的网络拓扑图，至少包含三个安全域定义每个安全域之间的通信策略（哪个域可以访问哪个域，使用什么协议/端口）特别说明审计日志系统的网络隔离方案解释你如何防止LegalBotAgent在万一被PromptInjection攻破后，攻击者利用它进行横向移动第三步：设计API安全策略（15分钟）定义LegalBotAPI的认证方案列出API的输入验证规则（至少5条）设计速率限制策略说明API响应中应包含哪些安全相关的HTTP头第四步：撰写ZeroTrust策略文档（25分钟）将前三步的设计整合为一份《LegalBotZeroTrust安全策略》文档。文档结构：策略版本与生效日期系统描述身份与访问管理（NHI设计、权限矩阵、动态授权逻辑）网络分段（拓扑图、通信矩阵、微隔离策略）API安全（认证、输入验证、速率限制、输出安全）审计与监控（日志记录内容、异常检测规则、日志保留策略）第五步：同行审查与改进（15分钟）如果条件允许，与一位同事交换策略文档，互相审查。如果独自练习，请从以下角度自我审查：是否存在任何“隐式信任”的假设？（如“Agent到知识库的流量是安全的，因为都在内网”）如果LegalBotAgent被完全攻破，攻击者最大能造成什么损害？是否还能进一步限制？策略中是否有任何条款会严重影响正常