浏览器自动化是 Agent 能力里最容易"演示很酷、上线出事"的一个。它让 AI 第一次真正伸手碰到了业务系统：登录、填表、提交、下载、外发。

做得好，它能把人从重复点击里解放出来；做不好，一次提示词注入就可能变成一次真实的数据外发。

这篇讲工程落地：五层安全控制、执行链路、白名单与凭据的写法、审批与审计怎么设计，以及六种失败模式怎么兜底。

结论先行：

• 有 API 就先用 API，浏览器是兜底手段，不是首选；
• 安全不靠提示词，靠沙箱、白名单、凭据隔离、审批、审计五层；
• 域名校验要在打开页面之前做，不能等页面加载完再判断；
• 先做只读任务，再做写入任务。

一、浏览器自动化解决什么问题

企业内部大量系统没有开放 API：老 OA、行业软件、供应商后台、政务办事网站。这些系统只能用浏览器操作。

典型任务包括：定时登录后台导出报表、在多个供应商网站比价、把数据录入没有接口的老系统、按固定路径巡检并截图留证。

它们的共同点是：规则明确、页面相对稳定、结果可由人复核。三条不满足，就不适合用浏览器自动化。

二、和 API 集成、传统 RPA 的区别

方式	适用场景	优点	限制
API 集成	系统开放接口	稳定、可审计、性能好	很多内部系统没有
传统 RPA	固定流程、固定页面	成熟、可控	页面一变就失效
Agent 浏览器自动化	半结构化任务、需要判断	能处理变化、可用自然语言描述	需要更强的权限与审计

优先级应该是：API > RPA > Agent 浏览器。只有在需要"看页面做判断"时，Agent 浏览器才不可替代。

三、五层安全控制

浏览器自动化最大的风险不是"做错事"，而是"用错权限做对的事"。

这五层里，域名白名单和操作审批最容易被跳过，也最容易出事。

四、一次任务的执行链路

把链路拆开，才知道每一层该在哪里拦截。

注意两个细节：

1. 域名校验在打开页面前完成，不做"先打开再判断"；
2. 审批只拦写入类动作，只读任务不应打断用户。

五、域名白名单怎么写

不要用正则去匹配整条 URL，也不要用"包含"判断——evil.com/?x=bank.com 这种就能绕过。

正确做法是解析出 host，再做精确匹配或后缀匹配。

from urllib.parse import urlparse

ALLOWED_HOSTS = {"oa.example.com", "supplier.example.com"}

def assert_allowed(url: str) -> None:
    host = (urlparse(url).hostname or "").lower()
    if host not in ALLOWED_HOSTS:
        raise PermissionError(f"domain not allowed: {host}")

如果是整域放行，用后缀匹配时要加一个点，避免 notexample.com 命中 example.com：

def host_allowed(host: str, suffixes: tuple[str, ...]) -> bool:
    host = host.lower()
    return any(host == s or host.endswith("." + s) for s in suffixes)

另外三个必须一起做的限制：

• 禁止自动下载，或下载目录单独隔离并扫描；
• 禁止页面跳转到白名单外域名，跳转即中断；
• 禁止在页面里执行任意脚本，只允许预定义动作。

六、凭据隔离：不要把密码交给模型

最常见的错误写法，是把账号密码写进提示词或配置文件，然后让模型"记住"。

正确做法是：凭据由平台托管，Agent 只拿到一个"已登录的浏览器上下文"。

# 错误示范：密码进入提示词，必然进入日志和模型上下文
# prompt = f"用账号 {user} 密码 {pwd} 登录后台"

# 正确做法：凭据在平台侧注入，Agent 只操作已登录的上下文
context = await browser.new_context(storage_state=load_vault_state("oa"))
page = await context.new_page()

配套三条规则：

• 用专用账号，不用管理员账号；
• 密码不进日志、不进对话、不进模型上下文；
• 账号权限按任务最小化，任务结束即回收。

七、写入类操作的审批怎么设计

只读任务可以自动跑，写入任务必须有人确认。审批的关键是让人看到"将要发生什么"，而不是只看到"是否允许"。

action = {
    "type": "form_submit",
    "url": "https://oa.example.com/expense/new",
    "summary": "提交报销单：金额 1,280 元，审批人 张三",
    "reversible": True,
    "rollback": "撤销提交并恢复草稿",
}
if action["type"] in WRITE_ACTIONS:
    await request_human_approval(action)

审批卡片至少包含：目标地址、动作摘要、影响范围、是否可回滚、回滚方式。缺一项，审批就是走过场。

八、审计日志要记什么

字段	说明
任务 ID	一次任务一个 ID，串起所有步骤
操作者	发起人 + 审批人
时间	开始、每步、结束
访问地址	完整 URL（含参数，敏感参数脱敏）
动作	点击、输入、提交、下载
证据	截图或页面快照的存储地址
结果	成功 / 失败原因

审计日志要能导出，并且保留周期按企业制度确定。只在界面里能看、不能导出的日志，过不了安全评审。

九、六种失败模式与兜底

其中"验证码"要特别说明：不要试图自动绕过。正确做法是转人工，并记录这次转人工的原因和耗时。

十、落地步骤

1. 选一个只读任务试点：先做采集，不做写入。
2. 列域名白名单：把任务涉及的域名全部列出来，多一个都不加。
3. 准备专用账号：最小权限，任务结束回收。
4. 配置审批点：写入类操作必须人工确认。
5. 跑一周再评估：记录成功率、失败原因、人工介入次数。

十一、五个常见坑

1. 用员工个人账号跑自动化：权限过大，且离职即失效。
2. 用"包含"判断域名：一行精心构造的 URL 就能绕过。
3. 把密码写进提示词：会进入日志和模型上下文。
4. 页面改版没有告警：任务静默失败，数据断更没人知道。
5. 只测成功路径：超时、验证码、弹窗、登录失效全没覆盖。

写在最后

浏览器自动化的价值，在于把"只能人做的事"变成"人能审核的事"。它的前提不是模型多强，而是权限边界清晰、审计完整、失败可回滚。

如果只能先做一件事，建议先做域名白名单和审计日志。这两件事做完，系统才具备被信任的基础。

参考资料

1. OWASP GenAI Security Project. OWASP Top 10 for LLM Applications.
2. Microsoft. Playwright Documentation — Browser Contexts and Storage State.
3. NIST. Zero Trust Architecture (SP 800-207).

关于作者

VitAgent 企业智能，关注企业 AI 工作台、私有化部署、RAG 知识库与多 Agent 协作，分享企业 AI 落地实战、本地大模型安全与权限审计。

如果你正在做 Agent 工具调用或浏览器自动化，欢迎在评论区聊聊：你们最先卡住的是权限、审批，还是页面稳定性？