加载失败
PromptArmor（做 AI 安全测试的团队）披露了 Ramp（企业支出管理公司）一款 Sheets AI 功能的问题：当表格或外部内容里混入恶意指令时，AI agent 可能把这些内容当成操作命令，从而读取或外泄财务数据。评论把这件事放进 prompt injection、权限控制和 agent 工具调用的老问题里讨论，因为一旦模型能访问邮件、网盘、1Password（密码管理器）或外部网络，错误输入就可能直接变成真实操作。大家也把它类比到 npm、pip、cargo 这类包管理生态里的 supply-chain 风险：高信任环境里只要引入不可信内容，后果就可能沿着权限链扩大。争论焦点不只是“有没有漏洞”，还包括这类 LLM 行为到底该不该像传统软件那样承担安全责任，以及 AI 产品营销是否在把风险说得过于轻松。
不少评论把问题归因于 LLM agent 的根本特性：它们会把输入内容当成可执行指令，而不是像传统程序那样稳定地区分数据和代码。有人直言，既然已经给了它删除邮件、读写外部服务之类的权限，就不该惊讶它偶尔真的会这么做。也有人把它类比成人类的“会犯错”，但反驳者强调当前模型既不会真正学习，也缺乏可追责性，因此不能靠“提示词调得更好”来根治。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
另一组评论把焦点放在权限和信任边界上，认为把 AI agent 放进高权限环境，本来就和 `sudo curl | bash`、盲装大量 npm 依赖一样危险。评论里反复提到 npm、pip、cargo 这类生态默认接收外部代码的习惯，指出 LLM 又因为缺少真正的“带外信号”而更容易把外部内容直接当命令。还有人举例读写型 1Password 插件、用相机+机械手指操作 Google Authenticator，说明一旦自动化越深，安全边界就越容易被便利性吞掉。
有人质疑这是否真的算漏洞，认为任何接收不可信输入的应用都可能输出错误，把它单独包装成“安全披露”更像营销话术。反方则强调，普通脏数据和能越权执行、甚至外泄敏感信息的攻击不是一回事，影响范围、成因和修复方式都完全不同。还有人拿 Melissa 这类文件格式病毒作类比，认为只要系统允许外来内容影响执行路径，就不该把它当成“只是报表错了”那样轻描淡写。
不少评论顺着话题讨论 Ramp 为什么要做 sheets 产品，答案是财务工作本来就高度依赖 spreadsheets，所以它想把工作流继续往自己这里收。有人甚至说 Ramp 可能是在“Excel 之前变成 Excel”，否则最后可能像 Slack 一样被更大的平台吞掉。另一条更尖锐的线索是，公司和员工都很爱把自己描述成“full AI、agents、automation”的前沿团队，但在旁观者看来，卖的只是“稍微好一点的 Concur”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
还有一批评论把这件事放到更大的社会语境里：大家早就习惯用便利换安全，于是供应商也越来越敢把高风险自动化包装成“安全可用”。有人提到企业总是在事故后把责任推给用户，让用户去调 prompt，而不是承认产品默认权限和边界设计有问题。也有人从市场和法律角度说，LLM 的非确定性可能需要最低安全标准；甚至有人表示今后会优先购买公开不在内部使用 AI 的公司，把“用 AI”视为一种不可靠信号。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
prompt injection: 通过恶意输入操纵 LLM/agent，让它忽略原本规则并执行不该做的动作。
in-band signaling: 只能通过同一数据通道传递信息；没有独立信道时，外来内容更容易被误当成指令。
supply-chain attack: 通过依赖包、插件、仓库或更新链路把攻击扩散到下游系统。
responsible disclosure: 在公开前先向厂商私下通报漏洞，给对方修复时间的协调披露方式。