Thales Google Cloud AI 安全新增控制措施，但自主性提高了风险

Thales 于 9 月 28 日扩大了与 Google Cloud 的合作，为 AI 代理增加安全控制措施，但关于护栏能否可靠约束自主系统的问题仍未解决。Thales Google Cloud AI 安全集成将 Thales AI Security Fabric 与 Gemini Enterprise 连接起来，面向用户、代理、模型、企业数据和外部工具之间的交互。

这一公告反映了企业 AI 的更大变化。过去，助手主要生成答案供人们审核；如今，代理能够选择工具、检索敏感记录、调用 API，并变更业务系统。因此，恶意指令或过度授权可能引发运营事故，而不只是产生糟糕的回答。

Google Cloud 已将 Agent Gateway 定位为代理与工具之间连接的控制点。Thales 则在这些连接周围增加检查、策略执行和威胁检测。这使双方的合作进入与 Microsoft、Zscaler、Palo Alto Networks 及其他试图定义企业代理安全层的供应商相同的战略竞争领域。

核心问题已不再是 AI 代理是否需要额外保护。政府指南和独立安全研究已经对此达成定论。真正的问题在于：集成的运行时层能否持续约束代理，同时又不至于让它们变得过慢、过于昂贵或限制过多，以致不值得部署。

Thales Google Cloud AI 安全集成带来的变化

此次合作让代理安全更贴近 AI 系统读取数据、选择工具或尝试执行操作的时刻。

根据这份安全公告，Thales AI Security Fabric 将与 Google Cloud Gemini Enterprise 集成。Thales 表示，组合后的系统可针对涉及用户、代理、模型、工具和企业信息的通信应用可见性、治理和安全策略。

预期覆盖范围包括代理式工作流的多个阶段。该系统可以检查进入代理的流量，观察代理与其模型之间的交互，并监控对外部工具的调用。它还旨在限制代理可访问的信息及其可执行的操作。

这些区别很重要，因为代理并不是一次孤立的模型会话，而是一连串决策、凭据、数据源和软件接口。每一次交接都可能成为攻击者、配置错误或不可靠模型决策改变结果的切入点。

Thales 将提示注入、数据泄露、不安全输出、未授权操作和代理间通信列为关键风险。提示注入是指嵌入内容中的敌对指令操纵模型行为。电子邮件、文档、网站或工具响应都可能携带这些指令，而用户未必会察觉。

该合作提出的应对方案是统一执行层。Thales 表示，其安全平台能够检测 AI 特有威胁、持续掌握代理行为，并阻止违反组织策略的操作。该公司还将集中式记录定位为合规审查和事件调查的支持工具。

以 Thales 提供的保险案例为例：获授权协助理赔结算的代理，可能从未经批准的来源获取个人信息。即便赔付计算看似合理，这一工作流仍可能带来隐私、公平性和合规问题。

运行时控制措施可在允许工作流继续前，检查所请求的数据源、代理被分配的角色以及拟议操作。它可以拒绝请求、记录尝试访问，或要求人工批准。这与仅过滤用户提交提示词的安全模型不同。

该集成也建立在 Google Cloud 更广泛的代理架构之上。其 Agent Gateway 生态系统为用户到代理、代理到代理以及代理到工具的流量提供受治理的连接能力。Google 将该网关描述为一个开放控制点，可与多家安全供应商协同工作。

因此，Thales 并非取代 Google Cloud 的原生控制措施，而是在更广泛的架构中提供专门的检查和执行层。其价值取决于它能够分析多少额外上下文，以及能否在高风险活动抵达业务系统前可靠介入。

为什么 AI 代理需要模型护栏之外的控制措施

当系统能够持有凭据并在没有即时人工审核的情况下采取行动时，模型给出安全响应并不意味着工作流就是安全的。

传统生成式 AI 安全通常聚焦于内容。组织试图防止有害回答、机密数据暴露或不当提示词。这些问题仍然重要，但代理引入了另一类风险：会产生实际后果的软件操作。

代理可以接收指令、制定计划、选择工具并执行交易。它可能发送消息、编辑客户记录、批准退款、修改源代码，或发起基础设施变更。错误可能在人员看到中间推理过程之前就已扩散。

这一区别解释了为何运行时授权正变得至关重要。策略不仅应评估代理说了什么，还应判断它使用了何种身份、请求了什么资源，以及该操作是否符合其被分配的任务。每当工作流改变方向时，可能都需要重新作出这一决策。

当代理协作时，问题会变得更加困难。一个代理可能收集信息，另一个提出建议，第三个执行操作。遭入侵的组件可能向链条其余部分传递被操纵的上下文或请求。

Thales 表示，其控制措施将覆盖这类代理间交互。这一承诺填补了重要空白，但实施细节将决定其价值。安全团队需要了解身份如何验证、委托权限如何表示，以及策略如何跟随跨多个代理的任务。

NIST 也指出了同样的问题。其 2026 年 5 月发布的代理安全分析发现，各方普遍认同代理带来了新型威胁。受访者还表示，熟悉的网络安全实践依然有用，但需要针对代理系统进行调整。

身份管理正体现了这种调整。传统应用通常通过具有可预测功能的稳定服务账户运行；而代理可以动态制定计划，并根据不断变化的上下文在多个工具之间进行选择。

赋予该代理广泛凭据会提升其效用，但也会加大遭操纵后的损害。预先严格限制每项权限能够降低风险，却可能阻碍代理完成正当工作。安全团队必须在有用的自主性与严格受限的影响范围之间取得平衡。

审计记录也带来另一项挑战。如果调查人员无法确定哪位用户发起了任务、哪些信息影响了代理，或某项操作为何获得授权，仅记录一次工具调用是不够的。有用的记录必须将人类意图、代理身份、数据访问和最终系统变更关联起来。

Thales Google Cloud AI 安全方案通过覆盖整个工作流的可见性来应对这一问题。原则上，共享层能够关联原本分散在模型、身份、API 和应用日志中的活动。

这种可见性能够帮助安全运营团队识别异常行为。如果一个通常只读取区域销售数据的代理突然请求员工记录或不熟悉的外部端点，就应引起审查。当静态规则无法预见所有有效操作序列时，行为上下文尤为宝贵。

然而，可见性并不等于遏制。仪表板可以在损害发生后解释事件。更有力的主张是，策略能够实时阻止不安全操作，同时不会阻碍使代理保持实用性的正当变化。

运行时执行成为主要竞争战场

战略竞争在于：安全能力是嵌入云平台，还是通过独立控制措施实现跨模型、代理和工具的一致策略。

Google Cloud 正围绕 Agent Gateway 构建合作伙伴生态系统，而非依赖单一安全供应商。其公布的参与者包括 Thales、Zscaler、Exabeam、Silverfort、Cisco、CrowdStrike、Palo Alto Networks 等。每家供应商负责代理工作流的不同部分。

Thales 将 Imperva 应用和 API 安全能力引入这一架构。其宣称的覆盖范围包括客户端到代理的流量、代理到模型的交互，以及通过 Model Context Protocol 等接口与工具进行的交互。MCP 是一种让 AI 应用连接外部数据和软件能力的协议。

这种方式为企业买家提供了灵活性。公司可以使用 Google 的基础设施，并选择符合其现有安全运营需求的额外控制措施。它还可以减轻完全依赖模型供应商所提供保障措施的压力。

代价是复杂性。多个产品可能从不同视角检查同一工作流。安全团队必须决定哪个组件负责身份、数据保护、行为分析、授权和事件响应。

重叠控制措施同样可能产生漏洞，而非增加防护深度。一个产品可能基于代理身份批准请求，另一个却缺乏识别滥用所需的任务上下文。第三个产品可能记录了工具调用，却无法理解返回的敏感数据。

Microsoft 正采取更垂直整合的路线。其代理安全战略连接了身份、访问策略、数据治理和生产力应用。Microsoft Entra 可以为代理分配身份，而 Purview 策略则在 Microsoft 环境内治理敏感信息。

对于已经以 Microsoft 服务为中心的组织而言，这种模式提供了更清晰的管理路径。但它也引发了熟悉的平台依赖担忧：针对单一供应商应用优化的控制措施，在工作流跨越云、模型和第三方工具时，可能无法提供同样一致的覆盖。

Google 基于合作伙伴的架构将开放性作为卖点的一部分。然而，开放性也将集成工作转移给平台及其客户。只有当策略能够经受住每次交接，并足够迅速地为生产流量作出决策时，它才真正有用。

独立供应商面临相关挑战：它们必须证明，额外增加的一层并不只是另一个监控控制台。买家将期待可执行的策略、可用的调查能力，以及控制措施能够在不扰乱日常工作的前提下降低风险的证据。

Thales 具备可信优势，因为 Imperva 已在 Web 应用和 API 周边开展运营。代理工作流使用了许多相同接口。现有的流量检查、机器人管理和 API 防护能力，可以为识别客户端和控制请求提供基础。

Agent 的行为仍不同于传统应用流量。一个有效的 agent 可能出于不可接受的目的发起技术上有效的 API 请求。识别这种区别，需要了解用户意图、委托权限、数据敏感性以及此前操作的顺序等上下文。

竞争压力正是在这里超越了既有的 Web 安全领域。供应商必须在不依赖 agent 自身解释的情况下，解读其运行上下文。被操纵的模型可以为不安全调用给出看似令人信服的理由。

云服务提供商也具备信息优势。它们运营模型服务、身份平面、网络和 agent 平台。合作伙伴必须获得足够的遥测数据，才能作出准确决策，同时还要尊重客户隐私和系统性能。

因此，最强的架构可能是分层的。原生云端控制可以实施基础身份验证和隔离，而专业产品则检查应用行为和敏感数据流动。对于不可逆或高影响的决策，人工审批仍然合适。

这场竞争不会由最长的功能清单决定。企业将评估每种架构处理混合环境、委托身份和不完整上下文的能力。它们还会考察，事件响应人员能否在不拼接多个互不兼容日志的情况下重建工作流。

安全承诺仍需生产环境证据

Thales 和 Google Cloud 描述了正确的控制点，但该公告并未证明这些控制措施在对抗压力下的准确性或一致性。

两家公司尚未在公告中公布部署数量、延迟测量结果、独立评估或详细的误报率。它们也未列举客户案例，说明集成后的安全架构如何在生产环境中阻止攻击。

这并不否定产品方向的价值，但限制了人们能从此次发布中得出的结论。这项集成应被视为扩展后的安全架构，而非 agent 工作流如今已安全的证据。

提示注入仍是一项严苛考验。NIST 在 2026 年 3 月发布的红队测试结果将间接提示注入描述为对 agent 的劫持。攻击者将恶意指令植入 agent 之后会处理的外部内容中。

这类攻击利用了一种基本模糊性。模型以相似的文本形式接收合法指令和不可信信息。即使恶意内容经过专门设计以模糊边界，模型仍必须区分应分析的数据与应遵循的命令。

运行时策略可以减轻损害。被注入的指令可能说服 agent 请求机密记录，但独立的授权层仍可拒绝该请求。该控制机制无需精确判断模型为何作出了错误决定。

这种分离是该合作伙伴关系最有力的理念之一。对数据访问和工具使用施加确定性限制，可以遏制模型级防护措施遗漏的故障。最小权限凭证和人工审批可进一步降低影响。

不过，策略引擎需要准确的上下文。它必须知道是哪位用户授权了任务、agent 服务于何种目的，以及哪些资源是必需的。过于宽泛或维护不善的策略，可能将技术先进的控制层变成宽松的网关。

误报则会造成相反的故障。如果 agent 反复因审批而暂停，或失去对常规数据的访问权限，员工可能会避免使用它。管理员也可能放宽策略，直到执行机制不再提供有意义的保护。

延迟同样重要。每个检查步骤都会增加处理时间。对于一次交互而言，影响可能不大；但在包含数十次模型请求和工具调用的工作流中，影响可能很显著。组织需要来自真实多 agent 部署的测量数据。

加密和隐私又增加了另一层矛盾。安全工具需要足够的可见性，才能识别敏感信息和恶意指令。客户会希望清楚了解哪些内容会被检查、在哪里处理、保留多久，以及谁能够访问。

问题并不局限于单一产品。OWASP agent 风险包括目标劫持、工具滥用、身份滥用、记忆投毒、不安全的 agent 间通信以及级联故障。没有任何单一流量过滤器能够解决每一类问题。

记忆投毒是一个有用的例子。攻击者可能植入虚假或恶意信息，供 agent 存储并在之后使用。运行时控制或许能检查原始输入，但有害影响可能在数天后、另一个工作流中才显现。

级联故障同样棘手。一个 agent 可能生成看似可信的错误结果，并被另一个 agent 采信。每一次单独的工具调用都可能符合策略，而整体工作流却正走向有害结果。

因此，组织需要纵深防御。它们应结合受限权限、沙箱隔离、签名身份、受保护记忆、经过验证的工具、持续监控和人工审查。安全测试必须覆盖完整工作流，而非孤立的模型响应。

政府指南强化了这一立场。澳大利亚的agent 采用指南建议设置人工控制点、持续监控、最小权限和多重重叠防御。该指南还建议逐步提高自主程度。

Thales AI Security Fabric 可以成为这些防御措施之一。该公告不足以证明应将其视为整个安全计划。买方应询问它如何与现有身份系统、开发控制、事件响应和审批流程协同。

随着 Agent 安全进入工作流，谁将面临压力

安全供应商、云平台和企业买方如今都面临压力，需要将 agent 治理从书面政策转变为可执行的软件。

云服务提供商面临最直接的期待。它们希望客户将 agent 从实验阶段带入业务运营，但当法务和安全团队无法界定可接受的边界时，采用便会停滞。一个无法回答身份、访问和可审计性等基本问题的平台，将难以支持敏感部署。

Google Cloud 的应对方式是将 Agent Gateway 打造成共同的执行点，并围绕它引入专业合作伙伴。Thales 通过单一安全架构覆盖应用、API、模型和工具交互，从而强化了这一战略。

Thales 必须证明，这种更广泛的范围依然易于管理。其价值主张取决于能否让客户在多个技术层面获得一致视图。碎片化的策略或重复告警将削弱集成的价值。

竞争性安全供应商面临证明同等广泛覆盖能力的压力。仅保护提示词已不再足够。买方需要涵盖凭证、工具执行、数据流动、记忆、agent 间消息和外部操作的控制措施。

身份供应商也面临新的工作负担。Agent 需要独立身份、有限权限、可追溯的归属关系和可管理的生命周期。临时 agent 在任务结束后不应遗留永久凭证。

应用所有者承担着另一项责任。他们必须界定 agent 可以执行哪些操作，以及在什么条件下执行。如果不了解工作流的人员提供运行层面的输入，安全团队就无法制定有用的策略。

开发人员将需要暴露更多结构化上下文。当工具调用声明任务、用户、请求的资源和预期效果时，安全层可以作出更好的决定。仅依赖非结构化提示词，难以为授权提供坚实基础。

企业买方应避免将采购视为治理的终点。部署安全架构并不能决定可接受的自主程度。组织仍需对用例分类、指定责任人、定义升级处理点，并测试故障情景。

低风险用例是合理的起点。根据获准的内部文档起草报告的 agent，其影响范围小于发送消息或修改客户账户的 agent。只有在评估显示工作流仍处于受控状态后，权限才应扩大。

高影响操作应获得明确审批。资金转移、生产环境变更、法律通信、人事决策和敏感数据披露，不应仅依赖模型的置信度。人工审查可能放慢工作流，但这种摩擦反映了错误的后果。

知识型员工应对此保持关注，因为这些控制措施决定了工作场所 agent 能看见什么、能做什么。更完善的安全机制可能让 agent 访问有用的内部信息。设计不佳的控制则可能暴露过多数据，或阻断准确工作所需的上下文。

员工同样需要透明度。他们应知道 agent 何时以其身份行事、访问了哪些记录，以及其输出是否会触发外部变更。发生事件时，隐蔽的自动化会使问责变得困难。

更大的转变发生在组织层面。AI 安全正在从模型评估任务转变为日常身份和应用管理的一部分。这使 agent 被纳入与员工、服务、供应商和软件部署相同的运营规范之下。

Thales Google Cloud AI 安全合作关系之所以重要，是因为它明确体现了这一转变。其成功与否，较少取决于公告本身，更多取决于企业能否应用这些控制措施，同时避免再造一个彼此割裂的治理层。

三个信号将表明这些控制措施是否有效

下一项考验是可量化的部署证据，随后是可互操作的身份体系和可信的对抗性评估。

第一个信号是披露结果的生产环境采用。Thales 或 Google Cloud 应发布客户案例，说明工作流、权限、被阻止的行为和运营开销。有价值的证据应包括检测准确率、审批频率、延迟和事件响应结果。

模糊地宣称某客户部署了安全 agent，几乎无法说明问题。最有力的案例研究应展示某项控制如何阻止真实的提示注入或未授权工具调用，同时说明合法活动被中断的频率。

如果出现这类证据，将加强这样一种主张：运行时执行能够支持实用的 agent 部署。如果客户仍保持匿名、测量数据继续不公开，买方应将这项集成视为前景可期但尚未得到验证。

第二个信号是跨平台更强的身份与授权能力。NIST 已经强调了有关 agent 身份识别、委托、审计和不可否认性的问题。市场需要一致的方法，以证明哪个 agent 正在行动、代表谁行动，以及拥有哪些权限。

互操作性将十分重要，因为企业工作流很少局限于单一供应商环境。一个 agent 可能使用 Google 模型、查询第三方数据库、调用 Microsoft 应用，并调用内部开发的工具。

策略必须贯穿该工作流，而不能授予单一可复用凭证广泛访问权。与特定任务绑定的短期授权将降低风险。可验证记录应将每一项重要操作同时关联至 agent 和负责的人类或服务。

开放身份标准的推进将增强 Google Cloud 的合作伙伴战略。持续的碎片化则会有利于那些控制更多技术栈、深度一体化的平台。

第三个信号是独立的对抗性测试。Thales 和 Google Cloud 应针对间接提示注入、恶意工具输出、凭据滥用、记忆投毒以及受感染的智能体，对组合系统进行测试。评估应衡量遏制能力，而不只是攻击是否被检测到。

一个有用的测试应假设模型会失败。随后应检验外部控制措施能否防止数据泄露或未经授权的系统变更。这能将模型安全性声明与周边架构实际提供的安全价值区分开来。

独立研究人员还应审查多智能体工作流所带来的绕过途径。一项策略或许能阻止一次直接请求，却可能允许多项单独看来均可接受的操作，最终产生同样被禁止的结果。

此次发布时机恰当。企业希望智能体不仅能总结信息，而监管机构和安全团队则要求更清晰的问责机制。这些压力使运行时控制成为一项必需能力，而非可选功能。

不过，自主性越高，举证责任也越重。智能体获得的权限越大，买方就越需要证据证明身份、权限、策略和审计记录能够在遭受攻击时协同运作。

评估 Thales Google Cloud AI 安全集成方案的组织，应从一个边界明确的工作流和预先定义的失败预算开始。梳理每个工具、凭据、数据源和不可逆操作。随后测试这些控制措施能否在不以大量审批压垮用户的前提下阻止滥用。

决定性的问题很实际：每当工作流发生变化时，这项合作能否始终将智能体的广泛能力转化为严格授权的操作？生产环境中的测量数据、可互操作的身份体系和独立测试将给出答案。