先看事故：真正危险的是“浏览器里的完整身份”#

NodeLoc 上有一条值得认真对待的事故记录：用户让接入 DeepSeek 的 Hermes 通过浏览器删除 VPS 上的一个网页项目，Agent 在执行过程中又删除了 DNS，连绑定在免费域名上的资产也随之消失。原帖明确说明，Agent 是通过浏览器登录用户账号后完成操作的。这里的证据等级需要说清楚：S11 是社区用户的单个事件样本，不足以证明某个模型、某个产品或某种浏览器自动化框架普遍存在同样缺陷；但它足以作为一个真实的威胁建模案例。

S10 则展示了一个实际的域名与 DNS 管理入口：页面同时提供用户注册、登录、管理员入口和 DNS 记录管理，并把主机开通、域名解析、安全防护放在同一套业务界面中。它说明一个常见事实：对用户而言，“删除项目”“删除域名”“修改解析”可能只是同一个控制台里相邻的按钮；对 Agent 而言，如果浏览器会话拥有完整账号权限，这些操作在技术上很可能都处于同一可达范围。

因此，事故的核心不是“AI 太笨”，也不是把提示词改得更礼貌，而是把三种东西叠加在了一起：长期有效的登录态、可执行的控制台权限，以及缺少二次确认的破坏性动作。模型只需要在目标理解、页面识别或动作选择中的任意一环出错，就可能把一个“清理网页项目”的任务扩大成“清理相关基础设施”。

把 Agent 的权限拆成三层#

1
身份 A：只读，查看主机、域名、解析和账单状态
2
身份 B：可修改应用文件，不可删除项目、域名和 DNS
3
身份 C：可修改 DNS，但不能删除域名或变更账户安全设置
4
身份 D：人工保管，只在灾难恢复时使用

1
允许修改：example.com 的 A 记录
2
禁止修改：example.com 的 NS、MX、TXT、CAA 记录
3
禁止操作：域名删除、账号安全设置、支付和退款
4
任务范围：/var/www/site 目录，不包括 /etc、DNS 控制台和备份目录

DNS 变更要先备份，再谈自动化#

DNS 是典型的低频、高影响资源。一个错误的 A 记录可能让网站暂时不可用，错误的 MX 或 TXT 记录会影响邮件和验证，错误的 NS 变更则可能让整个区域脱离原来的服务商。相比代码文件，DNS 的变化量很小，因此很适合在自动化前做完整快照。

在 Linux 上，可以先把公开解析结果保存下来，作为外部观察记录：

1
mkdir -p dns-check/$(date -u +%Y%m%dT%H%M%SZ)
2
DIG_DIR="dns-check/$(date -u +%Y%m%dT%H%M%SZ)"
3
for type in A AAAA CNAME MX NS TXT CAA; do
4
  dig +noall +answer example.com "$type" > "$DIG_DIR/$type.txt"
5
done

这份输出不是权威区域备份，不能替代服务商提供的导出功能，但可以帮助判断变更前后公网结果是否发生变化。若服务商支持导出 BIND 区域文件或通过 API 获取记录，应同时保存原始 JSON 或区域文件，并把备份放到 Agent 无法写入的位置。备份至少应满足三个条件：带时间戳、包含域名和区域信息、能够由人工按照记录逐项恢复。

修改前后可以使用差异检查：

1
dig +noall +answer example.com A
2
dig +noall +answer example.com AAAA
3
 dig +noall +answer example.com MX
4
 dig +noall +answer example.com TXT

不要把“DNS 已经恢复”简单等同于“页面能打开”。应分别检查权威服务器、递归解析结果和实际业务入口：

1
dig +trace example.com
2
curl -I --max-time 10 https://example.com/

dig +trace 用于观察从根到权威链路的委派是否正常，curl 只说明当前 HTTPS 入口是否返回响应。两者都不能证明邮件、证书验证或所有地域的缓存已经恢复，所以恢复检查必须与业务类型对应。

给浏览器 Agent 加上“计划—差异—批准”循环#

安全的浏览器自动化不应该从“打开后台并开始点击”开始，而应该先生成结构化计划。计划至少包含目标资源、允许动作、禁止动作、预计影响和回滚来源。例如：

1
目标：停用旧站点文件
2
允许：停止应用进程，删除指定部署目录
3
禁止：域名、DNS、证书、账号、支付设置
4
回滚：部署包 backup-2026-09-07.tar.zst
5
完成条件：旧站点停止，DNS 记录保持不变，备份校验通过

随后读取页面状态，只提取与任务相关的对象。对于 DNS 控制台，应该记录区域名称、记录类型、主机名、目标值、TTL 和变更前版本。Agent 生成的差异应当是机器可读的，而不是一句“看起来没问题”：

1
www.example.com A 203.0.113.10
2
www.example.com A 203.0.113.20

人工批准时，重点不是重新阅读整段自然语言，而是核对四件事：资源是否正确、变更是否在白名单内、是否有可用回滚、是否会影响其他服务。凡是出现“删除”“永久”“解绑”“转移”“重置”“修改 NS”等词，都应自动升级为人工操作。

如果只能使用浏览器而没有 API，仍然可以建立操作护栏：使用独立浏览器配置文件；关闭自动保存密码和支付信息；任务前后截图或导出关键状态；把最终确认交给人；任务完成后退出所有会话并销毁临时配置。浏览器隔离不能替代权限隔离，但它能减少跨站点登录态被误用的范围。

失败边界：哪些方法看似安全却不够#

第一，不能只依赖提示词。提示词可以约束模型的意图，却不能阻止已经获得浏览器权限的 Agent 点击错误按钮。真正的阻断点应该位于账号角色、工具调用、审批流程和服务商侧保护。

第二，不能把“有确认弹窗”当成回滚机制。确认弹窗只是又一次提交机会，删除后的域名、DNS 区域或账号资源是否能恢复，取决于服务商是否提供保留期、快照、审计和恢复能力。没有独立备份时，弹窗并没有让数据可逆。

第三，不能把只读检查误认为完整验证。公开 dig 结果可能受缓存影响，也可能遗漏控制台中的未公开配置；网页返回 200 也不能证明 MX、TXT、CAA 和 IPv6 都正确。验证应该覆盖实际使用的协议和记录类型。

第四，不能因为任务很小就放宽边界。删除一个测试站点时，Agent 看到的可能仍然是拥有多个生产域名的总账号。风险与任务文字长度无关，而与会话所拥有的最大权限有关。

一份可落地的上线前清单#

在让浏览器 Agent 操作任何云主机、域名或 DNS 控制台前，可以逐项确认：

• 是否使用了独立账号、独立浏览器配置文件和独立任务环境？
• Agent 是否只能看到本次任务需要的站点和资源？
• 删除域名、修改 NS、删除 DNS 区域等动作是否被禁止自动执行？
• 是否已经导出权威 DNS 配置，并将备份放在 Agent 无法修改的位置？
• 是否明确列出允许修改与禁止修改的资源？
• 是否先生成差异，再由人批准，而不是让 Agent 直接点击确认？
• 是否记录了变更前后的区域、记录类型、值、TTL 和时间？
• 是否准备了与业务对应的恢复检查，包括网页、邮件、证书验证和 IPv6？
• 任务结束后是否撤销临时 Token、退出会话并清理浏览器配置？

结论：Agent 的可靠性取决于“能不能被拒绝”#

S11 的价值不在于证明某个模型一定会删 DNS，而在于提醒我们：浏览器 Agent 的风险边界不是聊天窗口边界。只要它继承了完整登录态，页面上的所有相邻功能都可能变成任务的一部分；只要破坏性操作没有独立审批，模型的一次误判就可能跨越应用、主机、域名和 DNS 多个资源层。

工程上更可靠的方向不是继续堆叠“请勿误操作”的提示词，而是让 Agent 在系统层面无法完成超出白名单的动作：身份最小化、资源隔离、危险操作阻断、变更前快照、差异审批和可验证恢复。Agent 可以负责观察、规划和执行低风险步骤；涉及身份、委派、删除和不可逆变更的最后一步，仍然应该由人保留明确的否决权。

当一个自动化系统不能拒绝危险任务时，它的“智能”越强，事故半径反而越大。真正值得上线的浏览器 Agent，不是点击速度最快的那个，而是能够把一次模糊请求限制在可解释、可审计、可回滚范围内的那个。

参考资料#

• DeepSeek罪大恶极！
• ym.jszf.me