文章总结： 本文探讨AI智能体安全中的数据层风险，指出当前行业过度关注提示词注入而忽视智能体在跨系统操作时的数据可见性问题。Bonfy.AI提出三层防护方案：控制智能体可访问的数据范围、监控工具调用与MCP服务器传输内容、允许智能体实时查询操作安全性。文章涵盖威胁建模、多智能体信任链、模型版本管理及供应链风险，建议企业建立以数据为中心的安防体系而非依赖配置层面的管控。 综合评分： 85 文章分类： AI安全,数据安全,解决方案,安全运营,威胁情报

你的 AI 智能体正在传输敏感数据。你知道流向何处吗？

原创

Helpnetsecurity Helpnetsecurity

安全行者老霍

2026年4月9日 09:00 日本

作者：Mirko Zorz

发布时间：2026 年 3 月 23 日分享

#

在本次 Help Net Security 专访中，Bonfy.AI 首席执行官吉迪・科恩谈到了他所认为的 AI 智能体安全领域最紧迫的缺口：数据层风险。尽管行业目前聚焦于提示词注入与模型行为，科恩却认为，更深层次的威胁在于自主运行的 AI 智能体跨系统运作，而企业对其访问、整合与泄露的数据完全缺乏可见性。

他阐释了 Bonfy.AI 从三个层面解决该问题：控制智能体可用于上下文参考的数据范围，在数据通过工具调用与 MCP 服务器传输过程中监控内容，以及允许智能体在执行操作前实时向 Bonfy 查询该行为是否安全。本次对话涵盖威胁建模、异常检测、多智能体任务委派、模型版本管理，以及为承受规模化部署 AI 压力的首席信息安全官提供的实操建议。

当我们谈及 “AI 智能体安全” 时，大多数人会立刻想到提示词注入或越狱攻击。有哪个威胁向量让你彻夜难安，而行业内几乎无人为此做准备？

真正让我们忧心的并非又一种精巧的越狱手段，而是 AI 智能体在企业尚未完全可见、理解或管控的系统间自主运行，进而造成的数据滥用。

当下的讨论大多仍以 “大语言模型为中心”：提示词注入、越狱、模型行为等。但在大型组织中，真正的风险正转向日益自主化工作流的数据层：智能体可从多个系统读取数据、调用工具与 MCP 服务器，继而在无需人类全程参与的情况下执行操作（如发送邮件、更新记录、发布内容）。一旦形成这种模式，任何数据访问、整合与共享方式上的失误都会迅速演变为系统性暴露问题，而不仅仅是聊天界面上的一次错误回复。

几乎无人准备好应对的是，这些智能体并不存在于单一终端或规整的安全边界内。它们运行在微软、谷歌、Salesforce、定制应用框架、基于 MCP 的工具链中，且通常以 “系统智能体” 身份运行，甚至不与特定用户会话绑定。传统的数据防泄漏（DLP）、数据安全态势管理（DSPM）与以浏览器为中心的控制措施，从未被设计用于监控数据在大语言模型调用、向量数据库、MCP 服务器与下游自动化任务组成的多跳链路中流转。因此企业最终形同盲人：不清楚哪些敏感内容被输入智能体，哪些工具接收了这些数据，也不知道包含受监管信息或客户专属数据的 AI 生成结果最终流向何处。

这正是 Bonfy 所专注的威胁向量：在 AI 与智能体的全生命周期内保护企业数据，而非仅仅保护模型免受恶意提示影响。我们的平台将相同的上下文感知、实体感知控制策略应用于人、系统与 AI 智能体，覆盖邮件、SaaS 应用、协作工具、Copilot、接入 MCP 的智能体与定制生成式 AI 工作流。我们管控可用于上下文参考的数据范围，检查输入提示词与工具的内容，监控输出至邮件、文件与知识库的结果，如今甚至允许智能体在自身推理过程中调用我们的 MCP 服务器，在执行操作前询问 “分享此内容是否安全？”。

如果假设智能体将无处不在，并最终触及你最敏感的客户、员工与知识产权数据，那么核心安全问题就不再是 “有人能否越狱模型？”，而是 “我们是否具备能匹配自主 AI 运行速度与规模的数据层安全护栏？”

传统应用被攻陷时，其影响范围相对可预测。而一个能够浏览网页、写入文件、调用 API 与发送邮件的 AI 智能体则完全不同。面对如此动态的对象，该如何开展威胁建模？

你无法用威胁建模单个 Web 应用的方式去威胁建模 AI 智能体；必须对其周边的数据流与参与实体进行端到端的威胁建模。

对我们而言，起点是摒弃 “一个应用、一个影响范围” 的思维，转而梳理四类对象的链路：

• 智能体可参考的数据源
• 其可调用的工具与 MCP 服务器
• 其实际模拟的人员与系统
• 其输出结果可抵达的所有外部渠道

一旦能够看清完整的多跳路径，你就可以将风险不仅关联到模型本身，还能关联到特定智能体、工具、用户与数据集。

在实操中，我们落实三项具体工作。首先，通过对底层数据源进行细粒度、上下文感知的标记与访问控制，管控上下文参考环节，使你能够定义在特定业务场景下，哪些内容可被引入智能体工作流。其次，跨渠道监控上下游流量、提示词、检索文档、邮件、文件、SaaS 更新，使你能够发现智能体行为何时在现实中引发机密性、完整性或隐私安全事件。第三，通过我们自研的 MCP 服务器接入智能体的推理循环，使智能体能够在执行操作前实时询问：“根据数据归属与目标去向，将此内容发送给该工具、用户或目标是否安全？”

这会形成一种截然不同的威胁模型：不再试图预测动态智能体的每一种可能行为，而是对可流经智能体的数据、其可影响的实体，以及必须对数据流进行检查或阻断的节点定义并执行护栏策略。随着时间推移，由于 Bonfy 将人、系统与 AI 智能体均作为一级风险实体进行追踪，你能够发现哪些智能体持续在危险信任边界附近运行，并针对性收紧控制，而非将 “AI” 视为一个统一、不可控的风险整体。

当智能体链式调用多个工具时，每一次工具调用都可能将数据暴露给链路中的下一环节。是否有人对这些中间状态进行审计？审计形式是怎样的？

目前，几乎没有机构真正对这些中间状态开展审计，而大量真实风险恰恰隐藏于此。

当智能体链式调用工具时，每一次调用实际上都是一次小型数据共享行为：智能体提取部分上下文，传递给日历 API，再传递给客户关系管理 MCP 服务器，之后可能发送至邮件发送服务。正如吉迪所言，这种情况下 “每一次工具调用都可能将数据暴露给链路中的下一环节”，但当下大多数 “智能体安全” 方案仅关注配置层面 — 允许使用哪些工具 — 而非工具间实际传输的内容。

我们的观点是，必须将这些中间状态作为一级审计点。这也是我们将 Bonfy 开放为智能体可在推理过程中调用的 MCP 服务器的原因：智能体不再盲目将上下文从工具 A 传递至工具 B，而是可在中间调用 Bonfy：“根据数据归属与目标去向，将此内容分享给该特定工具或目标是否安全？” 每一次校验都会记录审计日志，包含检查内容、触发策略、涉及实体（客户、员工、用户）与决策结果，从而形成覆盖完整链路的可审计轨迹 — 而非仅记录初始提示词与最终邮件。

在实操中，这种审计不同于传统 API 日志，更像是智能体工作流的数据平面日志：逐步骤记录智能体读取的内容、尝试向各工具发送的数据、Bonfy 应用的风险评级与标记，以及系统允许、修改或阻断了该操作。由于采用与邮件及 SaaS 应用相同的实体感知引擎，安全团队能够凭借真实证据回答诸如 “上周有哪些智能体将欧盟客户数据暴露给外部 MCP 服务器？” 之类的问题，而非寄希望于智能体框架的配置页面能完整反映情况。

传统安全信息与事件管理（SIEM）和日志分析基于行为基线稳定的人类参与者构建。当 “参与者” 可在 30 秒内启动、完成目标并消失时，异常检测需要做出哪些改变？

当 “参与者” 是仅存在 30 秒的 AI 智能体时，你无法仅依据长期的智能体行为建立异常检测基线；必须将基线锚定在内容、上下文以及该智能体实例背后的人员或系统上。

传统 SIEM 假设身份与行为模式在数天、数周、数月内保持稳定；为某一人员建立基线，再寻找偏离行为。而智能体场景下模式完全反转：智能体身份转瞬即逝，但其接触的数据、代其执行操作的用户，以及跨越的信任边界却是真实且持久的。因此，异常检测必须从 “爱丽丝今天行为是否异常？” 转变为 “当前业务场景下，这一内容、目标与参与者（人、系统或智能体实例）的组合是否可接受？”

这正是 Bonfy 的核心方向。我们分析非结构化内容本身，并结合实体感知信息 — 对应客户、用户、产品线、监管区域 — 并与执行主体关联：员工、服务账号、Copilot 场景或短期存在的 AI 智能体，以及它们之间的关系。即便智能体在一分钟内启停，其在邮件、SaaS 应用、协作工具与 AI 系统中产生的数据轨迹也能通过统一的上下文视角被观测。

随后，我们在知识图谱中将人与智能体及其关联关系均建模为一级实体，使你能够将风险模式不仅归因于临时的智能体 ID，还能关联到其背后的用户（如适用）、特定智能体或智能体类别，及其在更广泛业务场景中的角色。久而久之，你不再对成千上万不可见的机器人一无所知，而是能够管理人与非人为参与者的组合及其关联关系，所有对象均通过同一套以数据为中心的风险模型进行评估。

在多智能体系统中，一个主控智能体协调多个从属智能体，形成委派链路。如何防止被攻陷的从属智能体破坏与主控智能体之间的信任关系？

一个令人不安的事实是，如今大多数多智能体系统中，无人真正保护这一委派链路，大家仅信任主控智能体 “可靠” 则下游所有节点均会正常运行。从 Bonfy 的角度来看，必须转变思路：从数据层面将每一次从属智能体调用均视为不可信，并为主控智能体提供工具，使其在接收或转发任何内容前检查输入与输出。

具体而言，主控智能体绝不应盲目使用从属智能体的输出结果。至少从数据层面，我们为主控智能体提供可直接调用的 Bonfy MCP 工具，用于检查从属智能体的输入与输出，验证其未违反任何策略，包括机密性、隐私性与数据完整性检查，例如 “该摘要是否突然包含其他客户数据或未预期的受保护健康信息（PHI）？”。主控智能体的提示词会明确编码该行为：“可委派任务给从属智能体，但在依据其结果执行操作或转发前，需通过 Bonfy 验证该内容对当前目标与业务场景是否安全。”

由于 Bonfy 会分析内容本身并结合实体感知信息（对应客户、用户、产品线、管辖区域），即便所有智能体均为短期存在且在框架中使用通用身份，它也能在被攻陷或异常行为的从属智能体尝试向链路注入敏感或不一致数据时发出告警。所有校验均记录在与邮件及 SaaS 应用同一平台：你可获得审计轨迹，记录哪一主控智能体调用了哪一从属智能体、传输了哪些数据、触发了哪些策略，以及 Bonfy 是否允许、修改或阻断了主控智能体的下一步操作。换言之，我们并非试图 “信任” 委派链路正常运行，而是为其加装检测机制，使任何从属智能体的输出在污染工作流其余部分前，必须通过以数据为中心的策略关卡。

AI 智能体频繁依赖 MCP 服务器、插件与第三方工具集成。该生态发展速度远超审核能力。我们是否正在无意识地陷入供应链危机？

我们并非即将陷入 AI 供应链危机，在许多企业中，危机已然存在。我们只是选择信任智能体随意调用的任何工具。

MCP 服务器或插件实际上就是一个黑盒微型供应商，你的智能体可在工作流中途向其移交敏感数据。在典型环境中，可能存在数十乃至数百个此类工具（内部服务、第三方 API、 enrichment 数据源），均由大语言模型动态编排，无人工参与，且安全审核极少。从数据安全角度来看，每一个此类工具现已成为你的 AI 供应链一部分，但极少有企业如此对待。

早期 “AI 智能体安全” 市场大多聚焦配置状态：存在哪些智能体、可查看哪些工具、被授予哪些权限。这是必要的，但并不充分，因为与其他软件一样，这些工具的使用安全与否取决于流经其的数据。我们刻意聚焦数据层而非仅配置层：哪些内容被发送至哪一 MCP 服务器、涉及哪些实体、触及哪些管辖区域，以及该组合是否符合业务与监管要求。

具体而言，我们为企业提供三大控制手段。首先，通过细粒度、上下文感知标记在数据源端管控上下文参考，从源头阻止特定类型信息（如受保护健康信息、欧盟个人可识别信息或客户专属交易条款）被特定智能体或工具使用。其次，在输出环节监控并执行策略，分析通过智能体生成的邮件、文件、SaaS 更新与其他输出结果，无论其途中使用了哪些插件。第三，通过自研 MCP 服务器，允许智能体在数据移交第三方服务前实时询问：“将此内容发送给该工具或目标是否安全？”

因此，围绕 MCP 服务器与插件的确正在形成 AI 时代的供应链问题，但解决之道并非冻结创新或逐一审核生态中的所有工具，而是部署以数据为中心的护栏策略。如此一来，无论智能体生态发展多快，敏感内容都能在所有智能体、工具与工作流中得到一致管控。

模型提供商会更新模型参数，有时甚至静默更新。周一表现正常的智能体，周五可能行为迥异，而你自身代码未做任何改动。安全团队应如何将模型版本管理视为合规与风险问题？

安全团队必须假定模型是供应链中的动态组件，而非一次性认证后便可置之不理的固定部件。

你可能无法控制提供商何时调整参数、安全层或路由逻辑，但能够控制接入端点的任意模型周边的数据护栏。对我们而言，起点是将模型版本管理视为与合规相关的变更：你需要明确各应用可向 “大语言模型” 发送哪些类型的数据，并需要证明无论周一使用模型 X 还是周五更换为模型 Y，针对提示词、检索文档、工具调用与输出结果的策略均被一致执行。

我们的方案刻意做到与模型无关。我们不嵌入特定客户模型，而是作为与客户无关的 AI 数据安全层，通过自研实体感知引擎检查流入与流出智能体、Copilot 与大语言模型的内容。正如吉迪所强调，Bonfy 采用与客户无关的 AI 模型，意味着即便底层大语言模型使用情况随时间发生变化（无论是否知情），你仍可应用相同的防护措施 — 因为策略存在于我们的平台，而非特定模型版本中。

从风险与合规角度来看，这提供了两大关键能力。首先，稳定可审计的防护层：即便后台模型版本迭代，你仍可向监管机构与审计人员提供一致记录，证明哪些敏感、受监管或客户专属数据在数据平面被允许或阻断。其次，检测模型行为向风险方向转变的能力 — 例如摘要中突然包含更细化的客户信息 — 因为 Bonfy 会持续对内容本身进行分类、标记与策略执行，与生成内容的模型无关。

部分厂商将 “安全 AI 智能体” 包装成近乎勾选框式的功能卖点。严格意义上的智能体安全应具备哪些特征？安全采购方应如何甄别虚假宣传？

“安全 AI 智能体” 并非勾选框功能，而是一项端到端的安全实践，必须跟随智能体读取、推理、调用工具与写入操作全程覆盖数据。

在我们看来，严格的智能体安全包含三大支柱。第一，管控上下文参考：通过对 SharePoint、邮件、客户关系管理系统及其他 SaaS 应用设置细粒度、上下文感知标记与访问规则，限制智能体初始可访问的内容范围。第二，在智能体推理过程中保护使用中的数据：当其调用 MCP 服务器、插件或内部 API 时，需要在线检查能力，判断其是否即将向错误工具或第三方移交受保护健康信息、客户专属详情或受监管内容。第三，管控输出结果：智能体生成的邮件、文件、工单与其他内容在送达人员或外部系统前，必须检查是否存在数据泄露与策略违规。

采购方容易陷入的误区是，许多 “智能体安全” 产品仅停留在配置状态层面 — 罗列智能体、开关工具、管理权限 — 却从未真正看清自动化流程中传输的数据。这是必要的基础安全管理，但无法防范配置完全 “合规” 却仍通过许可的 MCP 插件泄露客户数据的智能体。Bonfy 刻意聚焦数据层而非仅控制平面：我们将应用于邮件与 SaaS 的同一套实体感知引擎，同样应用于智能体提示词、检索文档、MCP 调用与输出结果，用统一策略管控人、系统与 AI 智能体。

如果你是希望甄别宣传真伪的安全采购方，我们建议三项简单测试。询问厂商：能否跨所有主要渠道查看并分类流入流出我智能体的实际内容，而非仅记录其被许可调用的工具？能否为人与智能体一致执行策略，使 “该客户数据不得超出此边界” 的规则在所有场景生效？我的智能体能否通过 MCP 服务器等方式实时查询你的平台，在执行操作前确认某行为是否合规？若任一问题答案为否，你所面对的仅是勾选框式产品，而非严格意义上的智能体安全方案。

若能在引发重大公开安全事件、倒逼行业讨论之前，改变安全行业应对 AI 智能体风险的方式，你会改变哪一点？

我会改变一点：停止将 AI 智能体风险视为抽象的 “未来 AI 问题”，转而将其视为已在生产环境中存在的具体数据问题。

当前，AI 应用速度远超治理能力；智能体已在邮件、SaaS 应用、内部系统与 MCP 对接服务间读取、转换与生成敏感内容，而大多数企业对这些智能体接触的数据缺乏统一可见性。行业投入大量精力关注模型、提示词与配置状态，却极少关注一个基础问题：当这些自动化任务执行多步工作流时，我的机密、受监管或客户专属信息流向何处？

从 Bonfy 的角度来看，我们需要的转变是将数据置于智能体风险讨论的核心。这意味着构建能够在非结构化内容任意流转时查看并分类的系统，理解内容背后的人员、客户与管辖区域，并对人为参与者、SaaS 应用或临时 AI 智能体统一执行策略。同时，通过 MCP 服务器接口等机制，赋予智能体实时询问 “在此发送或存储是否安全？” 的能力，而非默认信任其工具链会正确执行操作。

若我们现在完成这一认知转变，就不必等到引发轩然大波的安全事件发生后，才发现自己在 AI 自动化传输最敏感信息的过程中形同盲人。

对于既要承受业务压力规模化部署 AI 智能体，又要对数据安全结果负责的首席信息安全官，你能给出的最坦诚建议是什么？

对于身处此境的首席信息安全官，我们最坦诚的建议是：绝不接受 “先部署，再解决数据风险” 的运营模式，即便你面临巨大压力。

你无法阻止 AI 智能体落地，但可以坚持分阶段上线，将可见性作为首要交付目标，而非自动化。首先在智能体读写的渠道（邮件、协作工具、SaaS 应用、内部系统、MCP 对接工具）部署监测能力，使你能够看清完全放开权限后，智能体会触及哪些敏感、受监管或客户专属内容。这些真实数据将为你提供与业务部门理性沟通的依据：“哪些场景我们当前可安全自动化，哪些需要加装护栏，哪些用例目前仍需人工参与。”

在此基础上，从可见性到策略制定再到风险预防稳步推进。采用实体感知控制，使同一套策略适用于人员、SaaS 工作流或 AI 智能体，并为智能体提供调用 Bonfy MCP 接口等服务的能力，在数据传输途中实时检查，而非仅依赖静态配置。这使你能够批准规模化 AI 应用，但掌握主动权 — 具备可衡量的控制措施、可审计的决策记录，以及在董事会或监管机构询问如何在智能体驱动环境中保障数据安全时，拥有站得住脚的解释。

若你作为首席信息安全官被要求 “立即部署 AI 智能体并保障所有数据安全”，不要争论部署与否，而要坚持实施顺序。首先开启深度可见性，监控敏感、受监管与客户专属内容在邮件、SaaS、协作工具与智能体间的流向；随后叠加策略；最后才允许大规模自动化部署，使智能体在执行操作前调用 Bonfy 等服务实时检查 “在此发送或存储是否安全？”。唯有如此，你才能批准规模化 AI 应用，而不必将企业命运押注于对他人配置的盲目信任。

Your AI agents are moving sensitive data. Do you know where?

（完）

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全行者老霍 Helpnetsecurity Helpnetsecurity《你的 AI 智能体正在传输敏感数据。你知道流向何处吗？》