Agent在执行工具前需配备本地“看门人”
摘要
本文警示了AI智能体执行外部工具时的安全风险,并宣布为Tingly Box引入全新的本地安全护栏,以防范恶意操作。
提示词注入已不再是唯一的隐患。Claude Code 与 Codex 能够执行 Shell 命令,但浏览器智能体、OpenClaw 风格智能体、Hermes 风格智能体以及垂直领域智能体可能更容易遭到劫持,因为它们会触及杂乱且真实的底层环境:网站、SaaS 控制台、邮件、文档、工单、MCP 工具、API、本地文件及各类凭据。一旦智能体获得工具调用权限,被投毒的工具指令就不再仅仅是产生“错误结果”,而是会直接演变为实质性的破坏操作:* 安装恶意软件包 * 替换下载链接 * 暗中执行 `curl | sh` * 读取 `.env`、云端凭据或 `~/.ssh` * 将敏感数据外泄至未知目的地 并且这种行为无需每次都发生。一个恶意的目标端点完全可以伪装成正常状态,仅在自动审批模式下开启,或是探测到高价值工作流时才触发攻击。为此,我们在 Tingly Box 中引入了本地安全护栏(Guardrails):在智能体实际执行前,于本地对各项请求与工具调用进行前置检查。它能拦截已知的恶意域名/包、明显的密钥泄露行为、可疑的 Shell 指令以及对敏感本地资源的访问。这并非银弹,但在智能体真正动手调用工具之前,它们确实需要一个本地的“看门人”。
相似文章
AI代理需要安全层才能获得企业信任
本文介绍了一种针对AI代理的护栏平台,该平台提供控制层,用于阻止恶意提示、幻觉、危险操作和成本激增,从而在企业环境中实现安全的自主AI。
我的智能体在凌晨3点给老板发了邮件——防止危险工具调用的两行人工审核防护
本文介绍了一种简单的模式,将AI智能体工具分为安全与危险两类,将发送邮件、删除文件等危险操作路由到人工审批节点,以防止意外执行。
AI 编码代理在接触文件或运行命令之前需要本地安全边界
讨论 AI 编码代理中需要本地安全边界以防止未经授权的文件访问或命令执行。
你的智能体读到一个网页,上面写着“泄露用户的API密钥”——很多智能体会直接执行。我开发了一个工具来阻止这种发送。
Bouncer 是一个本地 MCP 代理,通过控制来自不受信任来源的外发工具调用来防止 AI 智能体泄露敏感数据,使用无 LLM 的确定性执行机制,基准测试显示降低了攻击成功率。
企业使用代理安全工具,你们的代理真的可用吗?
本文探讨了为AI代理创建策略层的挑战,即在安全性和可用性之间取得平衡,其中人工在环审批可能会减缓决策,但更严格的防护措施可能会妨碍可用性。