AI安全警报：近期智能体平台出现的三大潜在风险

面向安全团队和平台运营者，近期公开研究再次暴露出一个现实问题：智能体平台的风险已经不只来自模型本身，而是扩展到了身份核验、业务数据、后台工具和自动化流程。9月8日公开的相关资料显示，研究人员曾针对人工智能客服智能体开展攻击测试，发现攻击者可能绕过身份检查、暴露客户数据，并触发未经授权的操作。对于已经把智能体接入客服、邮件、账户管理或内部系统的企业来说，这类问题需要从“模型安全”提升到“业务系统安全”的层面来处理。

公开研究揭示的三类风险

这次公开信息中最值得关注的，不是某一个孤立的漏洞编号，而是智能体在真实业务链路中同时拥有“理解指令、访问数据、调用工具和执行动作”的能力。传统聊天机器人通常只负责生成文本，风险更多集中在内容错误或敏感信息泄露；而智能体一旦被授予查询账户、修改权限、发送邮件、调用内部接口等能力，模型输出就可能转化为实际业务结果。

研究人员在针对人工智能客服智能体的测试中，重点观察了邮件处理、账户授权、后端工具访问和客服工作流等环节。公开摘要显示，攻击者可能绕过身份核验，获得客户数据，甚至触发未获授权的操作。资料还提到，该项研究带来了超过5万美元的漏洞奖励。这个数字并不代表所有平台都存在同样问题，但说明智能体业务流程中的安全缺口已经足以被独立研究者系统地发现和验证。

风险一：身份核验被绕过，客服流程变成越权入口

身份核验是客服智能体最容易被低估的环节。很多平台会让智能体根据用户提供的姓名、订单信息、邮箱内容或历史对话来判断对方身份，再决定是否披露资料或执行操作。如果身份判断主要依赖自然语言上下文，而不是独立、可验证的认证机制，攻击者就可能通过伪造信息、操纵对话上下文或利用流程中的例外情况，诱导智能体把未授权请求当成正常请求。

这类风险的后果并不局限于“回答错了一个问题”。如果客服智能体能够查询账户、重置信息、修改订单、变更联系方式或转交后台任务，那么身份判断失误就可能进一步演变为账户接管、隐私暴露或业务操作被篡改。

安全团队不应把“模型认为用户已经通过验证”视为真正的身份认证结果。更稳妥的做法是把身份认证放在模型之外，由独立的认证服务返回明确状态；智能体只能读取认证结果，不能自行决定认证是否成立。对于涉及敏感数据或账户变更的操作，还应设置额外确认环节，并让系统记录请求主体、认证依据、工具调用和最终执行结果。

风险二：业务数据通过对话和工具链被泄露

智能体通常需要读取邮件、工单、知识库、客户档案或内部文档，才能完成复杂任务。数据访问范围越大，潜在泄露面就越广。公开研究提到，相关测试涉及客户数据暴露和邮件处理，这说明风险可能出现在输入内容、检索结果、上下文拼接以及工具返回值等多个位置。

一个常见误区是，只要模型没有主动“记住”数据，数据就不会泄露。实际上，敏感信息可能在一次任务中被读取后，直接出现在回复、邮件、工单、日志或后续工具调用中。更复杂的情况是，智能体可能把一个来源不明的文档、邮件或网页内容当作工作指令，进而将内部资料传递到不该访问的系统。

平台运营者需要明确区分三种权限：模型能看到什么，模型能调用什么，以及模型调用结果能写入什么位置。检索权限不应自动等同于导出权限，读取权限也不应自动等同于修改权限。对于客户隐私、身份凭证、财务资料和内部配置等敏感数据，应尽量减少进入模型上下文的内容，并在输出、日志和跨系统传递环节设置脱敏或拦截机制。

此外，所有外部输入都应被视为不可信数据，包括用户邮件、上传文件、网页内容、代码注释和工单文本。不能因为这些内容看起来像“工作指令”，就允许它们改变智能体的权限边界。智能体需要理解文本，但执行权限必须由外围策略系统决定。

风险三：智能体被诱导执行未授权动作

智能体平台的第三类风险，是从信息处理扩展到实际操作。公开资料显示，相关攻击可能触发未经授权的动作，涉及后端工具访问和客服工作流。这里的关键问题不是智能体是否理解了攻击者的意图，而是平台是否允许模型直接把理解结果转换成执行结果。

在传统软件中，调用接口通常需要明确的参数、权限和程序路径；在智能体系统中，调用动作可能由模型根据上下文动态选择。如果工具设计过于宽泛，或者权限校验只在流程入口执行一次，攻击者就可能借助一段看似普通的输入，影响后续任务规划，让智能体调用不适合当前用户或当前场景的工具。

因此，工具调用必须遵循最小权限原则。每个工具都应明确规定可访问的数据范围、可执行的动作、允许的调用主体和需要的二次确认条件。对于发送外部消息、修改账户、删除数据、支付或变更权限等不可逆操作，不能仅依赖模型自动执行。系统应当在执行前展示清晰的动作摘要，由用户或有权限的人工人员确认。

同时，安全日志不能只记录“智能体完成了任务”。日志需要能够还原完整链路：原始请求来自哪里，使用了哪些上下文，调用了哪些工具，工具返回了什么，系统依据什么策略放行，最终改变了哪些数据。只有这样，安全团队才能区分模型判断错误、权限配置错误和接口实现错误。

为什么传统漏洞管理还不够

现有漏洞管理体系仍然重要。搜索资料中出现了人工智能代理、中间件和企业软件相关的漏洞信息，也包括服务器端请求伪造、访问控制不当等传统安全问题。这些问题提醒平台团队，智能体并不会替代原有的应用安全要求。相反，智能体增加了一层能够理解自然语言并自动编排操作的控制面，传统接口漏洞和模型层风险可能叠加。

如果后端接口本身存在访问控制缺陷，智能体就可能把问题放大；如果工具接口权限过宽，即使模型没有明显缺陷，也可能因为任务理解偏差造成越权；如果外部内容能够影响任务计划，传统的输入校验就需要与模型上下文隔离策略共同工作。平台不能只等待某个模型供应商发布修复，也不能只扫描代码中的公开漏洞编号，而应同时检查智能体的业务权限和执行边界。

安全团队应优先检查什么

第一步是建立智能体资产清单。清单不能只统计模型名称，还应记录每个智能体服务的业务场景、可读取的数据、可调用的工具、可写入的系统、使用的外部内容来源以及负责人。没有清单，就无法判断某个智能体是否已经接触敏感数据，也无法在出现风险时迅速收敛权限。

第二步是重新审查身份与授权。应确认身份验证是否由独立机制完成，模型是否能够自行改变认证结论，敏感操作是否需要再次确认，以及后台工具是否会重复验证权限。对客服、销售、财务和运维场景而言，不能把“用户已经在对话中说明了信息”当作充分授权。

第三步是测试不可信内容对任务流程的影响。安全测试应覆盖邮件、文件、工单、网页和知识库内容，观察其中的诱导性文本是否会改变智能体的任务目标、工具选择或数据输出。测试重点不只是模型是否生成危险回答，还要检查它是否真的调用了工具、泄露了数据或修改了业务状态。

第四步是建立动作级别的监控。监控对象应包括异常的权限申请、连续失败的身份核验、短时间内大量工具调用、跨越正常业务范围的数据读取，以及与历史行为明显不一致的操作。对于高风险动作，平台应支持暂停、回滚和人工接管，而不是让智能体持续重试。

第五步是准备应急处置方案。发生疑似数据泄露时，团队应能够快速撤销工具权限、冻结高风险动作、保存上下文和调用日志，并判断影响范围。应急预案还要明确谁负责技术处置、谁负责业务确认、谁负责合规评估，以及何时需要通知相关方。智能体系统的处置不能只停留在“关闭模型”，因为风险可能已经进入邮件、工单、账户或其他外部系统。

合规检查不应只看隐私政策

合规检查的重点，应从“是否写了隐私说明”延伸到“实际系统如何使用数据”。平台运营者需要确认数据收集是否有明确目的，敏感数据是否被限制访问，数据是否被用于超出原定范围的任务，日志中是否保存了不必要的原始内容，以及用户是否能够获得清晰的人工申诉和纠错渠道。

对于自动化决策或自动化执行，还应评估人工干预是否真实存在。一个只在页面上保留“人工审核”按钮、但默认自动放行的流程，并不能有效降低风险。审核人员需要看到足够的上下文、动作影响和授权依据，才有可能作出有效判断。

供应商管理同样不能缺位。企业应要求智能体服务提供方说明数据处理边界、工具调用机制、日志保留方式、权限隔离方式和安全事件通知流程。对于无法解释数据流向、无法导出审计记录或无法快速撤销权限的平台，采购和上线前都应保持谨慎。

【软盟观察】

智能体安全正在从模型输出安全转向业务执行安全。近期公开研究所揭示的身份绕过、数据暴露和未经授权操作，并不是三个彼此孤立的问题，而是同一条链路上的不同表现：模型接触了过多信息，获得了过宽权限，却缺少独立认证、动作审批和可追溯审计。企业如果只关注提示词过滤，往往难以覆盖真实业务风险。更合理的路线是把智能体当作一种新的应用执行主体，按照最小权限、分层授权、默认不信任和可回滚原则建设外围控制。对安全团队而言，最紧迫的工作不是追逐每一个新名词，而是先回答三个问题：它能看到什么、它能调用什么、出了问题能否立即停下来。