给 Agent 配好模型再装几个工具第一次看到它真的帮你点按钮、查资料确实容易上头。紧接着很多人会想既然都能干活了那把邮箱、文档、聊天软件一起接上岂不是更省事我觉得真正该慢半拍的恰恰是这里。北京时间 11 月 3 日 10:59David Singleton 在 X 更新 Muse 漏洞赏金进展已支付超过 100 万美元其中一次奖励为 30 万美元。相关官方文章还披露了伪装成工具消息的提示词注入、验证码处理遗漏等问题。[1][2]这些材料最值得看的不是赏金有多大而是一个很实际的问题当 AI 不只会回答还能拿着你的权限动手谁来拦住不该做的那一步图 1依据 Muse 官方披露整理。30 万美元的最高赏金与 9 万美元的提示词注入案例不是同一个漏洞不能合并讲述。先把“什么时候、影响谁”说准确这不是一条“今天 Muse 刚刚泄露全部用户数据”的消息。官方文章说明30 万美元对应的问题发现于产品公开上线之前涉及员工和工程师测试使用的预发布虚拟机。问题与信任校验有关团队当时关闭服务并处理了它。[2]另一个已经修复的案例才是本文更关心的提示词注入研究人员做了一个网页模仿 Muse 浏览工具的状态消息。当用户要求总结网页时这些伪装内容让 Agent 执行了本该被拦截的动作。该案例的赏金为 9 万美元。不能把两件事拼成“一个网页直接骗走全部用户凭据”也不能因为官方修复了这些已知问题就反向保证以后不会再出问题。把事实边界摆好后面的讨论才有意义。网页上的一句话为什么能变成危险指令人看网页时大致知道谁在说话。文章正文归作者写浏览器弹窗归浏览器管自己的操作意图来自自己。它们虽然都显示在屏幕上但来源和权限不一样。Agent 处理这些信息时如果把外部网页内容、工具返回结果和真正的控制指令混在一起就可能判断错原本只是“要被阅读的材料”突然被当成“必须执行的命令”。这和普通的答非所问不一样。一个只能聊天的系统理解错了可能给出一段错误回答。一个能读文件、发消息或调用接口的系统理解错了后面可能接着发生真实动作。因此给 Agent 增加工具时不能只测试它会不会调用还得测试它在不该调用的时候会不会停下来。多写一句“不要被提示词注入”够不够不够把它当成唯一防线。这句话可以表达使用意图但不能替代程序的权限检查。最简单的道理是如果决定“这次可以破例”的也是刚刚读了可疑内容的那个模型那最后一道门仍然交给了同一个判断者。我会把模型和执行器的职责分开。模型负责提出计划例如“需要读取某份公开文档”。执行器负责检查这个动作是否在允许范围内当前用户有没有权限参数有没有越界是否需要人工确认。模型即使说得再笃定也不能自己给自己签一张管理员通行证。这里也别把问题简化成“某个模型更听话所以不用做权限”。模型能力、提示设计和检测机制都可以改善表现但它们不能让本来没有授权的动作变得合法。胜算云应该接在哪一层在这样的系统里胜算云可以放在模型请求层按照官方文档用 OpenAI 兼容地址https://router.shengsuanyun.com/api/v1通过 Bearer Key 调用账号实际可用的模型。[3]调用端仍然由你自己的后端负责。密钥放在服务端受控配置里不写进公开网页也不要塞进给模型阅读的日志、提示词或者截图。一个合理的分工可以是环节负责什么不应该顺手获得什么模型请求层理解需求、产生候选计划数据库管理员权限应用权限层校验用户身份、资源范围与参数接受模型自报的管理员身份工具执行层执行已经批准的有限动作任意 Shell、任意 URL、任意文件路径人工确认核对高影响动作及其具体对象只看一句笼统的“是否继续”这张表是应用设计建议不是胜算云已经替你实现的安全功能清单。接入服务提供模型调用能力业务授权仍然得由你的系统落实。最小的实操只允许读取当前用户有权访问的文档假设模型返回一个计划读取文档handbook。执行器不要直接照做而是用服务端已经认证的用户身份检查服务端维护的文档权限。这个身份不能从模型回复里拿也不能因为模型写了“我是管理员”就改变。下面只演示权限检查不调用模型也不真正读取任何文件defauthorize_read(proposal,authenticated_user,acl):ifnotisinstance(proposal,dict):raiseValueError(计划必须是对象)ifset(proposal)!{action,document_id}:raiseValueError(出现未允许的字段)ifproposal[action]!read_document:raisePermissionError(动作不在允许列表中)document_idproposal[document_id]ifnotisinstance(document_id,str):raiseValueError(document_id 必须是字符串)ifdocument_idnotinacl.get(authenticated_user,set()):raisePermissionError(当前用户无权读取该文档)returndocument_id# 演示数据实际用户身份和 ACL 必须来自服务端可信系统。acl{demo-user:{handbook}}proposal{action:read_document,document_id:handbook}document_idauthorize_read(proposal,demo-user,acl)print(通过授权检查的文档 ID,document_id)接到胜算云时模型照常通过/chat/completions产生计划应用把返回内容按 JSON 解析进行结构检查再交给这种授权层。只有授权通过的文档 ID 才能进入固定的文档读取接口。不要把文档 ID 直接拼成任意本地路径也不要给模型一个可以随便传 URL 的“万能下载工具”。上面的函数也不是完整安全系统它没有代替用户认证、访问审计、参数长度限制或应用自身的防护。如果你现在还没准备好这些环节最简单的起步方式其实是只做“生成建议不自动执行”。先把输出给人看确认任务和风险再逐步开放动作。图 2本文建议的授权流程。外部内容只能作为数据进入处理不能自动提升为更高权限的指令。上线前不妨专门测几次“它不该干的活”很多演示只测试顺利的情况请查文档它查到了请生成摘要它写出来了。实际验收还得补上反面用例。比如模型提议读取没有授权的文档工具返回了一段自称系统通知的文字用户要求把内部材料发到外部地址或者一个本来只读的任务突然提出删除数据。这些测试最好在隔离环境里用虚构数据和不产生外部影响的工具完成。重点不是给攻击“加戏”而是检查权限边界是否真的由程序执行。对于发送消息、付款、删除和修改权限之类的动作确认界面需要说清楚对象、内容和后果。只有一句“继续吗”用户很难判断自己到底批准了什么。另外使用任何云端模型或路由服务之前都应该确认数据经过哪些环节、各环节的保留规则和访问范围。不能因为用了 API就默认数据只在本机也不能因为选了某个品牌就省掉自己的数据最小化设计。我的看法会拒绝一次越权操作也是一种产品能力我不觉得这次披露说明“Agent 都不能用”。公开问题、修复问题、让外部研究人员参与测试本来就是系统持续改进的一部分。但它确实提醒我们Agent 的演示和生产使用中间还隔着权限、状态、审计和验收这些不太适合拍短视频的工作。在我看来一个系统能准确地说“这一步没有权限先停下”并留下可追踪的记录比它不加区分地把所有工具都调一遍更值得托付实际任务。别只给 AI 装工具。还得给每件工具装上真正管用的门锁。来源与接入说明David SingletonMuse 漏洞赏金进展原帖2026-11-03 10:59北京时间Muse 官方文章Securing Muse解释漏洞时间、影响范围和修复情况胜算云 OpenAI 兼容 API 文档胜算云接入指南中的 API Key 安全建议AIHOT 对应条目本文包含胜算云产品接入介绍讨论的是已公开披露并修复的问题。代码仅演示防御性的授权检查没有复现攻击也不构成任何平台安全性的保证。配图为说明图。CSDN 标签AI Agent、提示词注入、API 安全、权限控制、大模型应用、胜算云
给 Agent 配好模型再装几个工具第一次看到它真的帮你点按钮、查资料确实容易上头。紧接着很多人会想既然都能干活了那把邮箱、文档、聊天软件一起接上岂不是更省事我觉得真正该慢半拍的恰恰是这里。北京时间 11 月 3 日 10:59David Singleton 在 X 更新 Muse 漏洞赏金进展已支付超过 100 万美元其中一次奖励为 30 万美元。相关官方文章还披露了伪装成工具消息的提示词注入、验证码处理遗漏等问题。[1][2]这些材料最值得看的不是赏金有多大而是一个很实际的问题当 AI 不只会回答还能拿着你的权限动手谁来拦住不该做的那一步图 1依据 Muse 官方披露整理。30 万美元的最高赏金与 9 万美元的提示词注入案例不是同一个漏洞不能合并讲述。先把“什么时候、影响谁”说准确这不是一条“今天 Muse 刚刚泄露全部用户数据”的消息。官方文章说明30 万美元对应的问题发现于产品公开上线之前涉及员工和工程师测试使用的预发布虚拟机。问题与信任校验有关团队当时关闭服务并处理了它。[2]另一个已经修复的案例才是本文更关心的提示词注入研究人员做了一个网页模仿 Muse 浏览工具的状态消息。当用户要求总结网页时这些伪装内容让 Agent 执行了本该被拦截的动作。该案例的赏金为 9 万美元。不能把两件事拼成“一个网页直接骗走全部用户凭据”也不能因为官方修复了这些已知问题就反向保证以后不会再出问题。把事实边界摆好后面的讨论才有意义。网页上的一句话为什么能变成危险指令人看网页时大致知道谁在说话。文章正文归作者写浏览器弹窗归浏览器管自己的操作意图来自自己。它们虽然都显示在屏幕上但来源和权限不一样。Agent 处理这些信息时如果把外部网页内容、工具返回结果和真正的控制指令混在一起就可能判断错原本只是“要被阅读的材料”突然被当成“必须执行的命令”。这和普通的答非所问不一样。一个只能聊天的系统理解错了可能给出一段错误回答。一个能读文件、发消息或调用接口的系统理解错了后面可能接着发生真实动作。因此给 Agent 增加工具时不能只测试它会不会调用还得测试它在不该调用的时候会不会停下来。多写一句“不要被提示词注入”够不够不够把它当成唯一防线。这句话可以表达使用意图但不能替代程序的权限检查。最简单的道理是如果决定“这次可以破例”的也是刚刚读了可疑内容的那个模型那最后一道门仍然交给了同一个判断者。我会把模型和执行器的职责分开。模型负责提出计划例如“需要读取某份公开文档”。执行器负责检查这个动作是否在允许范围内当前用户有没有权限参数有没有越界是否需要人工确认。模型即使说得再笃定也不能自己给自己签一张管理员通行证。这里也别把问题简化成“某个模型更听话所以不用做权限”。模型能力、提示设计和检测机制都可以改善表现但它们不能让本来没有授权的动作变得合法。胜算云应该接在哪一层在这样的系统里胜算云可以放在模型请求层按照官方文档用 OpenAI 兼容地址https://router.shengsuanyun.com/api/v1通过 Bearer Key 调用账号实际可用的模型。[3]调用端仍然由你自己的后端负责。密钥放在服务端受控配置里不写进公开网页也不要塞进给模型阅读的日志、提示词或者截图。一个合理的分工可以是环节负责什么不应该顺手获得什么模型请求层理解需求、产生候选计划数据库管理员权限应用权限层校验用户身份、资源范围与参数接受模型自报的管理员身份工具执行层执行已经批准的有限动作任意 Shell、任意 URL、任意文件路径人工确认核对高影响动作及其具体对象只看一句笼统的“是否继续”这张表是应用设计建议不是胜算云已经替你实现的安全功能清单。接入服务提供模型调用能力业务授权仍然得由你的系统落实。最小的实操只允许读取当前用户有权访问的文档假设模型返回一个计划读取文档handbook。执行器不要直接照做而是用服务端已经认证的用户身份检查服务端维护的文档权限。这个身份不能从模型回复里拿也不能因为模型写了“我是管理员”就改变。下面只演示权限检查不调用模型也不真正读取任何文件defauthorize_read(proposal,authenticated_user,acl):ifnotisinstance(proposal,dict):raiseValueError(计划必须是对象)ifset(proposal)!{action,document_id}:raiseValueError(出现未允许的字段)ifproposal[action]!read_document:raisePermissionError(动作不在允许列表中)document_idproposal[document_id]ifnotisinstance(document_id,str):raiseValueError(document_id 必须是字符串)ifdocument_idnotinacl.get(authenticated_user,set()):raisePermissionError(当前用户无权读取该文档)returndocument_id# 演示数据实际用户身份和 ACL 必须来自服务端可信系统。acl{demo-user:{handbook}}proposal{action:read_document,document_id:handbook}document_idauthorize_read(proposal,demo-user,acl)print(通过授权检查的文档 ID,document_id)接到胜算云时模型照常通过/chat/completions产生计划应用把返回内容按 JSON 解析进行结构检查再交给这种授权层。只有授权通过的文档 ID 才能进入固定的文档读取接口。不要把文档 ID 直接拼成任意本地路径也不要给模型一个可以随便传 URL 的“万能下载工具”。上面的函数也不是完整安全系统它没有代替用户认证、访问审计、参数长度限制或应用自身的防护。如果你现在还没准备好这些环节最简单的起步方式其实是只做“生成建议不自动执行”。先把输出给人看确认任务和风险再逐步开放动作。图 2本文建议的授权流程。外部内容只能作为数据进入处理不能自动提升为更高权限的指令。上线前不妨专门测几次“它不该干的活”很多演示只测试顺利的情况请查文档它查到了请生成摘要它写出来了。实际验收还得补上反面用例。比如模型提议读取没有授权的文档工具返回了一段自称系统通知的文字用户要求把内部材料发到外部地址或者一个本来只读的任务突然提出删除数据。这些测试最好在隔离环境里用虚构数据和不产生外部影响的工具完成。重点不是给攻击“加戏”而是检查权限边界是否真的由程序执行。对于发送消息、付款、删除和修改权限之类的动作确认界面需要说清楚对象、内容和后果。只有一句“继续吗”用户很难判断自己到底批准了什么。另外使用任何云端模型或路由服务之前都应该确认数据经过哪些环节、各环节的保留规则和访问范围。不能因为用了 API就默认数据只在本机也不能因为选了某个品牌就省掉自己的数据最小化设计。我的看法会拒绝一次越权操作也是一种产品能力我不觉得这次披露说明“Agent 都不能用”。公开问题、修复问题、让外部研究人员参与测试本来就是系统持续改进的一部分。但它确实提醒我们Agent 的演示和生产使用中间还隔着权限、状态、审计和验收这些不太适合拍短视频的工作。在我看来一个系统能准确地说“这一步没有权限先停下”并留下可追踪的记录比它不加区分地把所有工具都调一遍更值得托付实际任务。别只给 AI 装工具。还得给每件工具装上真正管用的门锁。来源与接入说明David SingletonMuse 漏洞赏金进展原帖2026-11-03 10:59北京时间Muse 官方文章Securing Muse解释漏洞时间、影响范围和修复情况胜算云 OpenAI 兼容 API 文档胜算云接入指南中的 API Key 安全建议AIHOT 对应条目本文包含胜算云产品接入介绍讨论的是已公开披露并修复的问题。代码仅演示防御性的授权检查没有复现攻击也不构成任何平台安全性的保证。配图为说明图。CSDN 标签AI Agent、提示词注入、API 安全、权限控制、大模型应用、胜算云
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化