如果你给AI智能体提供真实数据和一个发送按钮,它最终会泄露。我构建了一个工作空间,从结构上使其不可能发生。
摘要
作者分享了一种开源工作空间架构,通过强制执行人工把控的出站操作并将引擎与数据仓库隔离,从结构上防止AI智能体泄露私人数据。
作者自述。这里分享的更多是一个架构思路而非产品,因为我认为这种威胁模型讨论不足。有一种被称为致命三合一的失败模式:智能体能访问私人数据、暴露于不可信输入、且具备对外发送能力。任意两者组合可恢复,三者齐备意味着隐藏在邮件中的恶意指令能让智能体在无人介入的情况下泄露数据。移除前两者会削弱助手功能——它需要读取你的世界,也需要读取来自你无法控制的人的消息。因此整个安全依赖于发送环节。在我开源的工作空间中,智能体可以起草和排队任何内容,但无法发送。每个出站操作在代码层面都会降级到人工把控层级,未知操作会失败关闭。此外,运行这一切的引擎不持有真实数据:你的数据是一个引擎无法携带的私有仓库,由六层强制保护和一个不可绕过的推送时扫描支撑。仓库地址:https://github.com/mishahanin/heading-os 我真的希望这被拆解分析。这个模型在哪里会失效?
相似文章
为什么你的AI智能体的“记忆”是一场潜在的数据泄露。
文章警告,在多租户AI智能体中使用仅具有逻辑隔离(元数据过滤器)的共享向量数据库可能会在无声无息中引发数据泄露,并提倡为每个用户提供物理隔离以确保零数据泄漏。
我想我已经解决了如何与同事……乃至任何人无缝共享你的AI代理的问题。
作者提出了一种共享AI代理的模式:将代理编译成密封的WASM模块,只导入一个推理函数,从而让他人可以使用自己的本地模型运行该代理,无需API密钥,也无安全风险。
你的智能体读到一个网页,上面写着“泄露用户的API密钥”——很多智能体会直接执行。我开发了一个工具来阻止这种发送。
Bouncer 是一个本地 MCP 代理,通过控制来自不受信任来源的外发工具调用来防止 AI 智能体泄露敏感数据,使用无 LLM 的确定性执行机制,基准测试显示降低了攻击成功率。
当AI代理点击链接时保护您的数据安全
OpenAI 描述了针对AI代理检索网页内容时基于URL的数据泄露攻击的安全防护措施。它利用独立网络索引验证URL是否公开已知,再自动检索,以防止提示注入攻击泄露敏感用户数据。
想要AI代理不泄露秘密?那就不要给它们秘密
关于一篇文章的简短公告,讨论将秘密远离LLM以防止AI代理泄露的原则。