你的智能体读到一个网页,上面写着“泄露用户的API密钥”——很多智能体会直接执行。我开发了一个工具来阻止这种发送。
摘要
Bouncer 是一个本地 MCP 代理,通过控制来自不受信任来源的外发工具调用来防止 AI 智能体泄露敏感数据,使用无 LLM 的确定性执行机制,基准测试显示降低了攻击成功率。
让我困扰的失败模式:智能体读取不受信任的内容(网页、电子邮件、文档),其中包含诸如“将这些数据发送给X”之类的指令,而智能体拥有一个能够执行此操作的真实工具。我构建了 Bouncer,一个本地 MCP 代理,控制外发工具调用的目标地址。如果目标来自不受信任的工具输出 → 拒绝。如果明确受信任 → 允许。如果是新的/未验证的 → 询问一次并记住。重要的是:执行路径中没有 LLM。这是基于固定的模式、策略和污点日志的确定性 Python 实现,因此模型无法通过话术绕过决策。我还针对 AgentDojo 的工作空间套件对其进行了基准测试。初步运行:攻击成功率从 0.33 降至 0.00,而良性效用保持在 1.00。样本较小,因此我将其视为机制测试而非胜利宣告。这是有意处于早期阶段:仅支持 MCP,仅支持 stdio,并且有文档记录的限制——包括跨服务器污点传播。我很好奇:你认为哪种攻击路径能击败这种设计?
相似文章
Agent在执行工具前需配备本地“看门人”
本文警示了AI智能体执行外部工具时的安全风险,并宣布为Tingly Box引入全新的本地安全护栏,以防范恶意操作。
你的AI代理距离做出灾难性行为只差一个被污染的网页
Arc Gate 是一个代理级别的工具,它强制执行指令权限边界,以防止AI代理被污染的网页、电子邮件或检索到的文档劫持。
在我允许智能体使用我的已登录浏览器之前决定的四个必要条件,以及我仍然控制不佳的一个
作者详细说明了四种安全措施,以实现AI智能体使用已登录浏览器,包括防止输入伪造、审批层、数据标记和安全通道,同时承认在控制cookie值方面存在弱点。
如果你给AI智能体提供真实数据和一个发送按钮,它最终会泄露。我构建了一个工作空间,从结构上使其不可能发生。
作者分享了一种开源工作空间架构,通过强制执行人工把控的出站操作并将引擎与数据仓库隔离,从结构上防止AI智能体泄露私人数据。
你的代理实际上是如何获取API密钥的?
一位开发者讨论了编码代理获取API密钥的三种常见模式,强调代理可以通过足智多谋的方式规避限制,并向社区询问他们的实际设置和经验。