2026 年 8 月 9 日，Hacker News 首页出现了一条很刺眼的标题：“AI assistant hacks gym website in first known Australian autonomous cyber attack”。无论个案细节如何，这类新闻都说明一个趋势：AI 安全讨论正在从“模型会不会说坏话”转向“Agent 能不能真的做事，以及做错事以后谁负责”。
过去我们习惯把安全边界放在模型输出上。模型不该生成恶意代码，不该指导攻击步骤，不该绕过授权。但 Agent 系统不只是输出文本。它可以打开浏览器、调用 API、扫描端口、改配置、提交表单、执行 shell、写文件、推送代码。只要它有工具和凭据，文本就会变成动作。
这意味着安全边界不能只靠拒答。拒答只是模型层的一道门，真正决定风险的是运行时：Agent 拿到了什么权限，网络能访问哪里，工具能做哪些副作用动作，日志是否完整，任务是否有预算和停止条件，人类是否在关键点确认。
自主性改变了责任链
传统安全事故里，人类操作者通常明确发起动作。即使脚本自动化执行，责任链也能追到脚本作者、执行账号和变更记录。Agent 加进来后，责任链变得更长：用户提出目标，模型拆解步骤，工具执行动作，外部系统响应，Agent 再根据反馈继续探索。
如果只记录最终输出，事后几乎无法复盘。你需要知道每一轮观测、计划、工具调用、参数、返回值、权限身份和外部副作用。否则事故发生时，只能得到一句“Agent 做了它认为合理的事情”，这在工程和法务上都没有意义。
因此，生产 Agent 的日志格式必须从聊天记录升级为审计轨迹。
{
"task_id": "agent-task-2026-08-10-001",
"actor": "platform-reviewer",
"agent": "browser-agent",
"tool": "http_request",
"target": "https://staging-api.internal.company.test",
"method": "POST",
"side_effect": true,
"approval": "human-approved",
"timestamp": "2026-08-10T09:12:20+08:00",
"result_status": 200
}这不是为了增加文档负担，而是为了让事故响应有材料可查。
权限要按动作拆，不按工具拆
很多团队的权限设计太粗：允许浏览器、允许 shell、允许 GitHub、允许云账号。问题是同一个工具可以做完全不同的事。浏览器可以读文档，也可以提交表单；shell 可以跑测试，也可以删除目录；GitHub token 可以读 issue，也可以合并 PR；云账号可以看日志，也可以改 IAM。
更合理的权限模型是按动作拆：
browser:
read_page: allow
submit_form: require_approval
download_file: allow
upload_file: deny
shell:
run_tests: allow
install_packages: require_approval
modify_system_config: deny
github:
read_issues: allow
create_branch: allow
push_branch: require_approval
merge_pull_request: deny
network:
default: deny
allow_domains:
- docs.python.org
- api.github.com这个矩阵看起来啰嗦，但它能表达真实风险。Agent 不是“能用浏览器”或“不能用浏览器”，而是在具体动作上被授权。
外部副作用必须有门禁
Agent 做本地推理、读文档、生成 patch，风险相对可控。一旦它对外部系统产生副作用，风险就上升：发送请求、提交表单、创建账号、发邮件、改云资源、触发 CI、写数据库、调用支付接口。
建议把副作用分成三档。
第一档是可自动执行的低风险动作，例如访问公开文档、读取只读 API、在临时目录写文件。
第二档是需要人类确认的动作，例如发起网络扫描、提交表单、推送远程分支、安装依赖、调用 staging API。
第三档是禁止动作，例如访问生产用户数据、修改 IAM、删除资源、触发付款、向外部收件人发邮件、对未授权目标做探测。
如果产品需要高自动化，也不要一开始就放开第三档。先把任务限定在 staging、synthetic data 和 disposable account，等日志和回滚机制成熟后再扩权。
模型拒答仍然有价值，但不能单独承担责任
有些开发者看到 Agent 事故后，会说“模型应该拒绝”。这当然没错，但不够。拒答策略可能被误提示、上下文污染、工具反馈和目标重述绕开。即使模型没有恶意，它也可能在“完成任务”的目标下误判授权边界。
运行时必须假设模型会犯错。安全设计不能依赖模型永远理解组织政策，而要把政策变成可执行控制：域名 allowlist、命令 denylist、token scope、审批流程、沙箱文件系统、网络隔离、速率限制和审计日志。
这和传统后端安全一样。我们不会因为业务代码“应该不调用删除接口”就不给数据库做权限拆分；也不应该因为模型“应该知道不能攻击别人网站”就给它无限网络和工具权限。
开发者上线清单
如果你正在把 Agent 接入开发或运维流程，上线前至少回答这些问题：
- Agent 使用哪个系统身份？这个身份能否和人类账号区分？
- 默认网络策略是什么？是否有域名 allowlist？
- 哪些工具调用会产生外部副作用？是否需要审批？
- 日志是否记录输入、工具名、参数、返回和操作者？
- Agent 任务是否有预算、超时和停止条件？
- 失败后如何暂停、吊销 token、回滚分支和导出日志？
- 是否有固定红队样本测试越权、误提交、数据泄露和提示注入？
这些问题并不复杂，但许多 Demo 没有做。Demo 环境里省略安全边界，到了产品环境就会变成事故入口。
事故响应要提前设计
Agent 事故响应不能临时拼。至少要有四个动作按钮。
第一，暂停 Agent。能立刻停止当前 task、后台 worker 和 pending tool calls。
第二，吊销凭据。Agent 用的 API key、OAuth token、SSH key 和 session cookie 必须能独立撤销。
第三，冻结日志。把完整轨迹、工具参数、外部响应和环境版本保存下来，避免后续覆盖。
第四，回滚副作用。本地代码可以 git revert，远程资源需要 Terraform state、数据库备份、API compensating action 或人工工单。
如果系统做不到这些，就不应该允许 Agent 执行高风险动作。
结论
自主 Agent 让“意图”变成“行动”的距离变短了。它能提高开发和运维效率，也把模型输出带进真实权限空间。HN 上的 AI assistant hacking 讨论之所以重要，不在于单个新闻多罕见，而在于它提醒开发者：Agent 安全的主战场已经是运行时。
模型拒答、内容过滤和提示词政策仍然需要，但它们只是第一层。真正可靠的边界来自最小权限、动作级授权、外部副作用审批、完整审计、可撤销凭据、任务预算和事故响应。Agent 越能干，工程系统越要把它当成一个真实操作者来管理。