当我们聚焦于提示词注入时，一种更隐秘的风险正在 AI 智能体层面悄然蔓延：数据层安全。在自主化的工作流中，智能体可以跨越邮件、CRM、协作工具等多重系统，自由读取、整合并执行操作，而我们对其中敏感数据的流动路径与最终去向却往往一无所知。近日，Bonfy.AI 的首席执行官 Gidi Cohen 在接受访谈时，指出了当前业界在这一关键领域的巨大盲区，并分享了其团队从威胁建模到实战防护的解决思路。
超越提示词注入：被忽视的数据层自主性风险
提问：当我们谈论“AI 智能体安全”时，大多数人首先想到的是提示词注入或越狱。有什么威胁向量让您夜不能寐，而业界却几乎毫无准备？
真正令人担忧的，并非层出不穷的模型越狱技巧，而是 AI 智能体 在企业尚未完全厘清、理解或管控的各个系统间自主运行时，可能引发的数据滥用问题。
当前，大多数安全讨论仍囿于“大语言模型中心论”，即提示词注入、越狱和模型行为调控。然而，在大型组织中，真正的风险正在向日益自主的工作流的数据层转移：这些智能体能够从多个源头读取信息，调用各类工具和 MCP 服务器，并在无人实时干预的情况下自主采取行动（例如发送邮件、更新记录或发布内容）。一旦形成这种模式，任何在数据访问、整合或共享环节的疏漏，都可能迅速升级为系统性的数据暴露事件，其后果远不止于聊天界面上的一个错误回复。
业界几乎毫无准备的现实是，这些智能体并不存在于单一终端或清晰的安全边界内。它们可能运行在微软、谷歌、Salesforce、自定义应用框架、基于 MCP 的工具链中，甚至以“系统智能体”的形态存在，不与特定用户会话绑定。传统的 DLP（数据防泄漏）、DSPM（数据安全态势管理）以及以浏览器为中心的控制手段，从未被设计用于监控数据在多跳链路中的流动——这包括了 LLM 调用、向量存储、MCP 服务器交互以及下游自动化流程。结果是，企业基本处于“盲飞”状态：他们不清楚哪些敏感内容被喂给了智能体，哪些工具接收了这些内容，以及那些可能包含受监管数据或客户信息的 AI 生成内容最终流向了何处。
这正是 Bonfy.AI 的关注核心：在 AI 和智能体的整个生命周期中保护企业数据，而不仅仅是防止模型被恶意提示攻击。其平台旨在将基于上下文和实体感知的控制能力，统一应用于人员、系统及 AI 智能体，覆盖电子邮件、SaaS 应用、协作工具、Copilot、连接 MCP 的智能体以及自定义的生成式 AI 工作流。它管控可用于“接地”（Grounding）的数据，检查进入提示词和工具的内容，监控流向邮件、文件和知识库的输出，甚至允许智能体在其自身的推理循环中调用其 MCP 服务器，在行动前先发起询问：“分享这个信息安全吗？”
为动态对象建模：重塑威胁评估框架
提问：传统应用一旦被攻破，其影响范围相对可预测。而一个能浏览网页、写入文件、调用 API、发送邮件的 AI 智能体则完全不同。面对如此动态的对象，威胁建模该如何着手？
你不能沿用为单个 Web 应用建模威胁的方法来对待 AI 智能体，必须围绕其数据流和交互角色，进行端到端的威胁建模。
起点是抛弃“一个应用，一个影响范围”的静态思维，转而描绘由四个部分构成的动态链路：
- 智能体可以基于哪些数据进行“接地”；
- 它可以调用哪些工具和 MCP 服务器；
- 它实际上在“模拟”哪些人员或系统身份；
- 其输出的所有可能落地渠道。
一旦能够看清这条完整的多跳路径，你就能针对具体的智能体实例、所用工具、关联用户和所涉数据集来评估风险，而非仅仅针对抽象的模型。
在实践中，Bonfy.AI 从三个具体维度切入。首先，通过细粒度的、基于上下文的标记和访问控制来管理“接地”环节，从而定义在特定业务场景下，哪些内容可以被引入智能体工作流。其次，跨渠道监控上游和下游的流量——包括提示词、检索到的文档、邮件、文件和 SaaS 更新——这样当智能体的行为在现实中触及机密性、完整性或隐私红线时，能够第一时间察觉。第三，通过其自身的 MCP 服务器接入智能体的推理循环，让智能体在行动前能实时询问：“把这段内容发送给这个工具、用户或目的地，安全吗？”
这催生了一种截然不同的威胁模型：不再试图穷举一个动态智能体所有可能的行为，而是为流经它的数据、它可能影响的实体，以及必须被检查或阻断的数据流动节点，定义并强制执行动态防护栏。长远来看，由于该平台将人员、系统和 AI 智能体 均视为头等风险实体进行追踪，便能识别出哪些智能体持续在危险的信任边界附近活动，并对此收紧控制，而非将“AI”视为一个单一的、不可控的巨大风险源。
审计“中间状态”：填补安全监控空白
提问：当一个智能体串联起多个工具时，每一次工具调用都可能将数据暴露给链中的下一步。有人在审计这些中间状态吗？这种审计具体是怎样的？
坦率地说，目前几乎没有人真正在审计这些中间状态，而许多真实风险恰恰就隐藏在这些环节。
当智能体串联工具时，每一次调用实质上就是一次微小的数据共享事件：智能体获取一部分上下文，将其传递给日历 API，再传给 CRM 的 MCP 服务器，然后可能又发给邮件发送服务。正如 Cohen 所言，“每次工具调用都可能将数据暴露给链中的下一步”，但现今大多数“智能体安全”方案聚焦于配置层面（允许调用哪些工具），而非关注在这些工具之间实际流转的内容。
必须将这些中间状态视为需要头等审计的节点。这也是为什么 Bonfy.AI 选择将其作为一个 MCP 服务器暴露出来，供智能体在推理过程中调用：智能体不再盲目地将上下文从工具 A 传递给工具 B，而是可以在中间调用该服务，询问“根据数据归属方和目的地，将这段内容共享给这个特定工具或目的地是否安全？”每一次这样的检查都会被详细记录，包括检查了哪些内容、触发了哪些策略、涉及哪些实体（客户、员工、消费者）以及最终决策，从而在整个链条上形成可审计的轨迹——而不仅仅是记录最初的提示词和最终的输出。
在实践中，这种审计日志更像一份智能体工作流的“数据平面日志”：逐条记录智能体读取了哪些内容、尝试向每个工具发送了什么、系统给出的风险评级和标签，以及最终是允许、修改还是阻止了该操作。由于它采用了用于电子邮件和 SaaS 的同一套实体感知引擎，安全团队 就可以用确凿的证据回答诸如“上周哪些智能体将欧盟客户数据暴露给了外部 MCP 服务器？”这类问题，而无需依赖于智能体框架的配置页面提供的有限信息。
异常检测进化：从“身份”到“上下文”
提问：传统的 SIEM 和日志分析是围绕具有稳定行为基线的人类角色构建的。当你的“角色”可以在 30 秒内启动、完成目标、然后消失时，异常检测需要做出哪些改变？
当你的“角色”是一个生命周期仅 30 秒的 AI 智能体时，你显然无法基于智能体的长期行为历史来进行异常检测，必须将检测锚定在内容、上下文以及该智能体实例背后的人类或系统身份之上。
传统 SIEM 假设的是数天、数周乃至数月内稳定的身份和行为模式：你为一个人类用户建立行为基线，然后寻找偏离。而智能体的模式恰恰相反：智能体身份是短暂易逝的，但它触及的数据、它可能代表其行事的用户、以及它跨越的信任边界，却是真实且通常持久的。因此，异常检测必须从“爱丽丝今天行为异常吗？”转向“在当前业务上下文中，这种内容、目的地和角色（无论是人、系统还是智能体实例）的组合是可接受的吗？”
这正是 Bonfy.AI 的着力点。它分析非结构化内容本身，并结合实体感知进行丰富——涉及哪个客户、消费者、产品线或监管体系——然后将其与行为主体（员工、服务账户、Copilot 场景、短命的 AI 智能体）以及它们之间的关系进行关联。即使一个智能体在不到一分钟内启动和消亡，它在邮件、SaaS 应用、协作工具和 AI 系统中留下的数据痕迹，也能通过一个统一的、基于上下文的透镜被清晰地观测到。
随后，平台将人类和智能体——以及他们之间的联系——作为知识图谱中的头等实体进行建模。这样一来，你就可以将风险模式归因于一个具体的用户（如果适用）、特定的智能体或智能体类别，以及它们在更广泛业务场景中的角色，而不仅仅是归因于一个临时生成的智能体 ID。长此以往，你面对的不再是成千上万不可见的、令人茫然的“机器人”，而是在管理一个由人类和非人类角色及其复杂关系构成的动态组合，所有实体都通过同一个以数据为中心的风险模型进行评估。
防御多智能体“毒化”：在委托链中嵌入检查点
提问：在多智能体系统中，一个主控智能体协调多个子智能体，这就引入了委托链。如何防止一个被攻陷的子智能体“毒化”它与主控智能体之间的信任关系？
一个令人不安的事实是，在当今大多数多智能体系统中，没人真正在保护这条委托链。默认的假设是，只要主控智能体是“好的”，下游的一切都会规规矩矩。从安全视角看，必须扭转这种思维：你应该将每一次子智能体调用，从数据层面视为不可信的，并赋予主控智能体相应的能力，使其在接受或转发任何信息之前，能够检查子智能体的输入和输出。
具体而言，主控智能体绝不应该盲目接受子智能体的输出。从 数据安全 角度，可以为主控智能体提供一个能够内联调用的 MCP 工具，用以检查子智能体的输入和输出，验证其是否违反了任何策略，包括机密性、隐私和数据完整性检查，例如“这份摘要中是否突然包含了另一个客户的数据或意料之外的受保护健康信息（PHI）？”主控智能体的提示词应硬性编码这种行为：“委派给子智能体，但在基于其结果采取行动或将其传递之前，务必通过安全检查工具验证，确保内容对于此目的地和业务上下文是安全的。”
由于该工具基于实体感知分析内容本身，它就能在某个被攻陷或行为异常的子智能体试图向链条中注入敏感或不一致的数据时发出警报，即使所有智能体都是短命的，并在框架中共享一个通用身份。所有这些检查都会被记录在统一的平台上，形成一份清晰的审计追踪，记录哪个主控智能体调用了哪个子智能体、流经了什么数据、触发了哪些策略，以及最终的管控决策。简而言之，其理念并非试图盲目“信任”委托链，而是对其进行“检测化”，使得任何子智能体的输出在“毒化”工作流其余部分之前，都必须通过一个以数据为中心的策略关卡。
这场访谈揭示了 AI 智能体 规模化应用背后严峻的数据层安全挑战，也为企业安全团队提供了从被动响应转向主动管控的可行思路。随着自主智能体日益渗透到核心业务，构建贯穿其生命周期的 数据安全 可见性与控制力，已不再是可选项，而是必选项。对于更深入的技术探讨与实践案例，开发者们也可以在 云栈社区 这样的技术论坛中找到更多相关讨论与资源。
发表于 1 小时前
|
查看: 1|
回复: 0
