你们在哪里停止投毒——在代理、边界,还是?
摘要
一个假设性的安全讨论,探讨来自被入侵 API 的投毒数据如何流入 AI 代理和分析系统,并质疑防御措施应部署在哪里。
以下是假设性的思考过程。假设这样一个场景:NOrks(Waaaaaghh)入侵了一个天气 API,并在少量响应中放入投毒响应。我们出于某种目的调用该天气 API,管它是什么目的呢。我们将响应存储在数据库中。我们将响应提供给 Agent(代理),让它们做自己的事情。收到投毒会导致某些坏事发生。这个数据库也用于 BI、分析……更多代理类的东西,而且很多用户也会连接到它数据最终流向的地方,比如 Excel、Word 和 Copilot……正如主题行所说:试毒者在哪里?你会在哪里或应该把“它”放在哪里?
相似文章
对于使用工具的智能体,安全边界应划在哪里?
讨论AI智能体使用工具的安全风险,重点关注提示注入这一实际威胁——不受信任的文本可能改变智能体行为,以及在授予权限前需要进行可重复测试。
数据投毒与RAG操纵
讨论数据投毒和RAG操纵如何对AI系统构成无声而危险的威胁,认为安全防护必须超越输入过滤,延伸到记忆、数据管道和多智能体逻辑。
你们如何处理读取外部内容的代理中的提示注入问题?
关于在读取外部内容(如电子邮件和网页)的AI代理中处理提示注入攻击的讨论,探讨了生产级别的防御措施以及超越明显模式的微妙威胁。
AI代理是否正在创造一个新的运行时供应链攻击面?
讨论AI代理安全作为一个超越提示注入的运行时供应链问题,强调来自不可信数据、工具和反馈循环的风险,并质疑开发者如何执行边界。
开发人员发布AI代理时,你们的安全测试是怎样的?
一位正在为AI代理构建安全测试工具的开发者向社区询问:在发布前,他们针对提示注入、数据泄露等恶意输入进行测试的做法是怎样的?