9月15日，Google Developers Blog发布零信任Agent系列第二部分，把Agent安全的讨论推进到运行阶段。这个变化看似只是安全产品架构升级，背后对应的产业问题却很具体：企业已经不满足于让大模型回答问题，开始允许Agent查询数据库、修改工单、触发退款、调用代码、发送通知，模型输出由一段文本变成了可能造成业务后果的操作。
传统应用安全习惯围绕确定性代码建立边界。输入经过校验，服务账户拥有固定权限，业务规则写在程序里，日志记录已发生的动作。Agent引入了概率性决策：同一句自然语言可能被解释成不同任务，模型会依据会话历史选择工具并拼接参数，还可能在多轮交互中逐步改变计划。只检查提示词有没有敏感词，或只验证一条SQL是否合法，已经覆盖不了这类风险。
Google给出的答案，是在用户、Agent、模型与工具之间设置统一的Agent Gateway，再用入口与出口防护、工具调用前的语义治理、跨轮次异常检测组成运行时控制面。这套思路的产业意义很明确：Agent安全预算将从上线前的模型测试，持续转移到每一次生产调用的授权、观测和响应。
为什么静态规则管不住会规划的Agent
企业第一批Agent项目常沿用聊天机器人安全方案。团队过滤输入中的越狱词，限制输出格式，给知识库设置访问控制，再对工具参数做类型检查。这些措施都有必要，但它们主要回答三个问题：内容是否危险、格式是否合法、调用者是否拥有某项权限。业务执行还需要回答第四个问题：在当前语境下，这个用户让Agent做这件事是否合理。
以退款为例，合法用户可以申请退款，客服Agent也可以调用退款接口。接口收到的订单号、金额和账户均可能符合格式，调用身份也拥有权限。如果攻击者诱导Agent把一笔违规的大额退款拆成多次小额退款，每一次调用都低于单笔阈值，传统参数规则会连续放行。累计金额超过订单金额时，风险才完整显现。问题不在某一次语法违规，而在一连串动作组合形成了违规意图。
这也是Agent与普通API客户端的主要差别。API客户端通常执行人或程序预先决定的请求；Agent在执行过程中持续推理，会根据工具返回结果调整下一步动作。安全系统如果只看当前请求，相当于在审查一盘棋时只看刚落下的一子。单步合法并不能证明整盘行动合规。
静态规则还有维护上的限制。自然语言中的角色、目的、对象和条件组合极多。企业若试图把所有表达转换成正则表达式，会迅速得到庞大而脆弱的规则库。SQL解析器可以判断语句结构，却无法知道“导出这批客户名单用于活动邀约”是否超出了员工当前项目的授权目的。身份与权限系统可以确认某人属于市场部门，也未必能确定其是否应该在深夜批量读取刚完成投诉的客户记录。
因此，零信任在Agent场景中的基本单位，需要从“谁能访问哪个系统”细化到“谁在什么业务上下文中，为何调用哪个工具，对什么对象执行何种动作”。授权判断变得更动态，证据也从账户、网络位置扩展到会话历史、任务目标、调用序列和业务状态。
三层运行时控制各自解决什么问题
Google方案的第一层是Model Armor，负责在交互入口和出口识别提示注入、越狱、恶意链接与敏感数据泄露。这一层像内容安检，目标是减少恶意指令进入模型上下文，也防止模型把不应暴露的信息带出信任边界。
提示注入尤其棘手，因为攻击指令可能藏在网页、邮件、文档或检索结果里。Agent为了完成任务主动读取外部内容，外部内容又可能要求它忽略原有约束、泄露数据或调用高风险工具。入口扫描可以标记可疑内容，出口检查则能拦截密钥、个人信息和受监管数据。企业不能把这一层理解成万能防线：内容检测存在误报与漏报，经过编码、改写或多轮拼接的攻击也可能绕过单点判断。
第二层是Semantic Governance Policies，即语义治理策略。系统在工具实际执行前，根据自然语言政策评估用户意图、会话历史和业务规则。它跳过对请求字符串表象的纠缠，直接判断该动作在当前业务情境下能否被允许。
例如，政策可以表达为：客服Agent只可为已经核验身份的订单发起退款；累计退款不得超过实付金额；高于某一业务阈值的退款必须由主管确认；Agent不得把退款转入订单原支付渠道以外的账户。落到运行时，网关需要把当前工具名称、参数、用户身份、历史调用、订单状态和策略一起送入判断环节。高风险调用只有在策略返回允许后才会抵达业务系统。
语义策略的优势是更接近企业政策原文，也能处理多种自然语言表达。它的代价同样明显：判断本身可能由模型参与，因而带来延迟、成本和非确定性。生产系统不能只记录“模型认为可以”。它需要保留使用了哪版政策、读到了哪些上下文、输出了什么结论、置信度如何、是否触发人工审批。涉及资金、删除、权限变更、外部发送等不可逆动作时，语义判断应与确定性硬规则共同生效。
第三层是Agent Anomaly Detection。它分析完整会话乃至Agent群体的遥测数据，发现单次合规、累计异常的行为。退款拆分是直观案例，类似模式还包括：短时间查询大量客户记录；分多次下载后拼成完整敏感数据集；先创建低权限账户，再逐步提升权限；多个Agent使用不同身份访问同一目标；连续尝试相近参数寻找策略边界。
异常检测补足了实时策略的视野。策略擅长判断已知边界，异常检测负责从行为基线和序列中发现未知模式。两者结合后，系统可以在发现风险后新增或调整政策，并在下一次工具调用前阻断，无需重新部署Agent应用。这种闭环会改变安全运营方式：策略不再完全绑定在业务代码发布周期里，而成为可以独立更新、回滚和审计的运行时资产。
Agent Gateway会成为企业AI的新控制点
Agent Gateway的价值，在于给高度分散的模型与工具调用建立一个统一执行关口。没有网关时，每个团队会在自己的Agent代码中写权限检查、日志和拦截逻辑。项目少时看起来灵活，规模扩大后会出现策略重复、标准不一、审计字段缺失和更新困难。安全团队很难回答公司里有多少Agent、调用哪些工具、携带何种身份、近一周拒绝过哪些动作。
统一网关可以把认证、策略决策、速率限制、敏感信息处理、调用签名、日志和告警放到共同层。业务团队仍负责定义任务与工具，平台团队负责提供可靠的执行通道，安全与合规团队则维护策略和证据要求。这种分工与API网关、服务网格的发展路径相似，但Agent Gateway处理的上下文更多，也必须理解任务与意图。
企业要警惕把网关做成单一大模型裁判。如果所有调用都依赖同一个语义模型给出允许或拒绝，系统会遭遇性能瓶颈、模型故障和判断漂移。更稳妥的结构是分级决策：低风险只读工具使用确定性身份和参数规则；中风险动作增加语义策略；高风险动作叠加人工批准、双人复核或延迟执行；异常序列触发账户冻结、会话隔离和证据保存。
网关还要防止旁路。Agent能否直接连接工具，工具是否接受未经网关签名的请求，开发环境的密钥能否访问生产资源，都是架构成败的关键。如果业务系统仍接受Agent直接调用，治理层只能提供观测，无法形成强制控制。企业应让高风险工具校验短期凭证或调用签名，并把凭证签发与策略决策绑定，降低绕过控制面的可能。
从提示安全转向动作安全
目前不少企业的AI安全清单仍以内容为中心：是否产生有害回答、是否泄露隐私、是否引用错误信息。这套清单适用于问答产品，却不足以覆盖执行型Agent。动作安全至少要增加五类问题。
第一，动作是否可逆。读取库存和删除库存记录的风险不同，生成邮件草稿与直接群发也不同。企业应为工具标记风险等级、可逆性、影响范围和所需审批，而不能仅凭工具名称授权。
第二，权限是否最小化。Agent不应长期持有覆盖所有客户、所有环境的高权限令牌。更合理的做法是按任务签发短期、窄范围凭证，让凭证绑定用户、工具、对象、额度和有效期。任务结束即失效，降低提示注入成功后的横向移动空间。
第三，结果是否经过确认。高风险动作可以采用“计划—预览—确认—执行”流程。Agent先输出结构化计划，系统展示影响对象和关键参数，经规则或人员确认后再执行。确认内容必须与最终调用参数绑定，避免确认后被Agent悄然改写。
第四，连续行为是否越界。配额和限额要覆盖单次、会话、用户、Agent和时间窗口多个层级。一次导出一百条记录可能合理，一小时连续导出五十次就应触发调查。累计风险指标需要进入实时决策，而不能只留在事后报表里。
第五，事故后能否恢复。日志要能还原模型版本、系统提示、检索材料、政策版本、工具参数、返回结果和后续动作。可逆工具应提供补偿操作，例如撤销工单变更、取消未发送任务、回滚权限。无法自动撤销的动作要配置明确的人工处置责任人。
企业落地时最容易踩的四个坑
第一个坑是把自然语言政策当作合规制度的自动翻译器。公司制度常含模糊词，如“必要时”“合理范围”“重要客户”。人类依赖组织常识解释，机器执行则需要明确主体、对象、条件、阈值和例外。上线前应把政策拆成可测试场景，建立允许、拒绝、升级审批三类样本，并让业务、法务和安全共同验收。
第二个坑是只采集模型日志，不采集工具侧事实。模型可能声称退款成功，接口实际失败；也可能在重试中执行两次。审计必须以业务系统返回和状态变化为准，将调用ID、幂等键、执行结果与Agent轨迹关联起来。否则事故复盘会停留在聊天记录，无法确认真实影响。
第三个坑是异常检测没有业务基线。通用安全模型可以发现突发流量，却不懂月末财务批处理、促销期间客服高峰或数据迁移窗口。企业需要按角色、工具、时段和业务流程建立基线，并允许经过审批的临时变更。告警过多会让运营团队迅速失去响应能力。
第四个坑是动态策略缺少变更治理。Google展示了发现异常后快速新增策略并阻断后续调用，这种速度很有吸引力。策略改错也会大面积中断业务。因此，动态更新要有版本、测试、灰度、回滚和紧急放行机制。安全响应快，不等于跳过软件工程纪律。
一套可执行的企业建设顺序
企业无需一开始就搭建庞大的智能治理平台。第一步是做资产盘点：列出所有生产Agent、模型、工具、数据源、服务身份和负责人，标记哪些动作会影响资金、客户权益、数据、权限和外部沟通。盘点结果应进入持续更新的登记系统，新工具未登记便不能接入生产。
第二步是建立工具契约。每个工具声明输入输出、权限范围、数据分类、幂等方式、风险等级、审计字段、超时和补偿动作。Agent只能调用注册过的工具，禁止通过通用脚本或任意HTTP请求绕开契约。对于现有API，可以先用适配层封装，逐步补齐元数据。
第三步是集中执行入口。高风险调用统一经过网关，工具端拒绝无签名请求。先部署确定性规则，包括身份验证、对象权限、金额与频率限制，再为需要语境判断的场景增加语义政策。语义判断故障时采取何种降级策略，要按业务风险预先决定：只读场景可有限放行，资金和权限操作通常应默认拒绝或转人工。
第四步是建设跨轮次遥测。统一会话ID、任务ID、用户ID、Agent版本、策略版本和工具调用ID，把多步轨迹串起来。监测指标除了延迟和成功率，还要包括拒绝率、人工升级率、重复调用率、异常序列、补偿次数和策略误报。企业自建检测模型产生的效果数据，应明确标注为企业自测，避免把内部样本结果包装成普遍结论。
第五步是开展红队演练。测试人员不只尝试直接越狱，还应模拟恶意文档注入、权限混淆、拆分操作、长会话诱导、多个Agent协同绕过、重试导致重复执行等情形。演练的目标是验证发现、阻断、恢复和追责整条链路，而非得到一个好看的攻击拦截百分比。
直接的产业判断
Google这次发布释放了三个信号。其一，Agent运行时治理会形成独立于模型平台和业务应用的基础设施层。云厂商、安全厂商、API管理厂商与Agent框架都会争夺这个入口。企业采购时应优先考虑策略可移植性、日志可导出性和工具端强制能力，避免全部治理证据被锁在单一模型平台。
其二，自然语言政策会成为安全工程的新接口，但不会取代确定性控制。市场会经历一轮“用模型管理模型”的过度宣传，随后回到混合架构：硬规则负责底线，语义模型理解上下文，异常检测发现序列风险，人类处理高影响例外。能够把四者编排清楚的产品，比单一检测模型更有长期价值。
其三，企业Agent的竞争指标将加入受控完成率。只比较任务完成率会激励系统冒险调用工具；只追求拦截率又会让Agent失去实用性。企业需要同时衡量任务完成、策略违规、人工介入、误拒绝、恢复时间和事故损失。未来成熟的Agent平台，会把这些指标放在同一运营面板上。
对正在推进Agent项目的企业，行动建议很直接：暂停给通用Agent发放长期高权限密钥；先把资金、数据导出、删除、权限和外部发送五类动作纳入网关；为每项高风险工具增加幂等、预览、确认与补偿；把跨轮次轨迹纳入安全运营；要求供应商提供策略版本和审计证据导出能力。
Agent进入生产之后，安全边界已经从模型输入输出延伸到整个行动链。谁能在工具执行前理解意图，在连续行为中识别异常，在事故发生后快速阻断和恢复，谁才有条件把Agent从演示项目变成可长期运营的企业系统。
参考资料
- Google Developers Blog，《Build zero-trust AI agents that judge intent, not just syntax》，2026-09-15。
https://developers.googleblog.com/build-zero-trust-ai-agents-that-judge-intent-not-just-syntax/